Category Archives: Web Design

HybridConf, 2014

I’m just back from attending HybridConf, a 2-day web design/development conference in Stockholm. It was my first time in the city, and I found it strangely underwhelming. I don’t know whether spending so much time in Amsterdam has spoiled me when it comes to stunning architecture, but Stockholm just felt like it could be any of a dozen anonymous British cities, albeit with a lot more umlauts and street corner beggars.

The conference itself, in its second year and transplanted from Bath by organisers Laura Sanders and Zach Inglis, was excellent. The relatively small attendee count gave it an intimate feel, and the venue – the historic Rigoletto cinema – made this probably the most comfortable conference I’ve ever attended. Perhaps half of the audience were Swedish, with the rest travelling from all around Europe. There were even a few Americans present, and they in particular must have felt at home, as almost three-quarters of the speakers were from the US.

I and co-worker Erin Weigel managed to catch just about every talk; I particularly enjoyed Dan Rubin‘s opening talk about team communication (and it closely matched how we run our teams at, and Scott Hanselman managed to be both funny and informative despite having to fit in a second unplanned appearance on stage to stand in for the missing Sara Chipps. But the highlights of the two days were both delivered by people building actual real things. Tom Soderstrom, CTA of NASA’s Jet Propulsion Laboratory, gave us an insight into the sort of work going on there, and how they apply startup culture and thinking within one of the world’s most expensive projects.

Then on Friday, GitHub’s Andrew Nesbitt tempted the live demo gods by wiring together an Arduino-powered, joystick-controlled ball live on stage. I was only slightly disappointed that he didn’t attempt to feed his rabbit live over the internet.

We were of course there as sponsors in our ongoing quest to hire the entire world, and it’s good to hear during the many conversations I had with other attendees that A/B testing and experimentation is becoming a lot more of a mainstream aspect of modern web design and development. We’ve become something of a fixture at web conferences now, and people are much more aware of what we’re doing and how we work. We had sponsored Experience Design Stockholm‘s event the previous evening, where Erin had delivered a great talk on experimentation that was also well-received; I think it’s strange that more large companies aren’t using this route to directly mingle with our industry’s top talent and promote themselves as maybe being that potential next job.

Jag Reehal: Responsive Workflow with Grunt, at Refresh Cambridge

Grunt logo

At last night’s Refresh Cambridge meetup, the first of 2014, we were lucky enough to have Jag Reehal come to speak about his experiences with using Grunt — the JavaScript Task Runner — to facilitate easier development of responsive websites.

After some introductory slides to define responsive design (fluid grids, flexible images, media queries) Jag jumped straight into some live coding demos. Here’s a summary of what he demonstrated, with links to the relevant Grunt plugins in the NPM archive where I could find them:

  • A basic Gruntfile is a series of tasks that you want to run, written in fairly basic JavaScript. You can output text, warnings, and cause a task to fail.
  • The time-grunt plugin lets you see how long tasks took to run.
  • The grunt-concurrent plugin allows you to run two or more tasks in parallel instead of in series.
  • It’s easy to create your own Grunt plugin; use the grunt-init-gruntplugin as a template. It includes tests, which is a important part of any plugin.
  • Since we want to build a responsive page, we’ll need to access it on a variety of devices while developing. The grunt-contrib-connect plugin starts a basic server on a local address, so you can load your work-in-progress on your phone or tablet as you work. It also includes a livereload feature, so you don’t have to refresh each device after making changes to the source files.
  • We’ll be using media queries for responsiveness; in order to avoid repetition of values or breakpoints in our CSS, we should use a preprocessor like LESS or SASS.
  • The autoprefixer plugin is especially clever; just tell it what browsers you want to support (or even how far back it should go to support) and it will automatically fill-in browser prefixes for any CSS properties that need it. And the best thing is that you don’t have to worry about going back to change support when new browsers come out!
  • By using CSS compilers, we can easily split out the various parts of our code into logical areas, and import them into one single stylesheet.
  • The grunt-browser-sync plugin is almost like magic; it synchronises form values (and presumably UI state as well) across browsers/devices — update something on your desktop and the same change will appear instantly on your mobile! It also cleverly doesn’t force a full page reload if you update a source file; it simply injects only the updated file into the page, preserving any changes you have made. And it even lets you scroll in sync across devices too!
  • Images are the biggest web performance killer. Responsive images is a confusing topic; you must consider compression, spriting, and retina images. Spriting images in particular has always been a lot of work.
  • The grunt-spritesmith plugin lets you simply maintain a source file full of images; when run, the plugin converts all the images into a single sprite, together with the accompanying CSS. Adding a new sprite is now just a case of dropping the new image into a folder; no more re-calculating background positions!
  • Alternatively, you might want to use base64 encoded images. The grunt-image-embed plugin handles this for you (although obviously you need to balance the multiple files vs CSS size performance issues).
  • The ultimate icon solution is provided by the grunt-grunticon plugin, which takes SVG icons as its default type, while also creating a sprited PNG fallback and individual images, and uses JavaScript to decide which is the best format to use.
  • When it comes to larger images, no standard solution has been decided upon yet, but in the meantime the grunt-responsive-images plugin does most of the work for you. Simply provide it the large image and it will automatically create resized versions that are interpreted by the <figure> markup to serve different images depending on screen size. Only the images needed are downloaded.
  • An alternative is the BBC’s Imager.js library, which allows you to specify the breakpoints in a simpler JSON format rather than writing out a full set of srcsets.
  • For creating production-ready resources — concatenated and minified — there are plenty of plugins such a cssmin (for CSS), uglify (for JavaScript), smushit (for images), etc.

Unfortunately I had to leave before the end of Jag’s talk, but I’ll add any additional notes I receive from other attendees. It was a great demonstration of the power of Grunt’s plugin architecture (and I’m sure that a lot of these plugins work exactly the same within new-kid-on-the-block, gulp.js too), and reminded me of the recent blog post complaining that too often programmers don’t bother to automate repetitive tasks. Armed with the power of the relatively easy-to-install Node and Grunt, designers finally have a way to automate away the most time-consuming parts of their job, and concentrate on building great user experiences.

If you’ve never given Grunt a try, I highly recommend it; it’s not as scary as it looks, and you’ll be amazed at how much easier it can make your life!

How I made a website behave more like a book

I’ve been idly sketching ideas vague ideas for a redesign of my blog this week, and found myself heading down a well-worn route. A blog (I said to myself) is really nothing more than a collection of titles and text — maybe a few images thrown in here and there, probably a datestamp, but that’s basically it. Focus on the content.

But when I started sketching how that sort of content-focused site might look, I found that it all started to look a little familiar. Any of a dozen Squarespace templates. There was obviously a limit to what one could do with nothing but a title and a handful of paragraphs.

Nature Paint screenshot

Then, in an interview with Cole Henley in .NET magazine, I spotted a screenshot of the Nature Paint website. Although Cole has actually used a variety of different templates to build that site, it was the two-column layout that caught my eye. Perhaps that could be the difference, the tweak I was looking for to turn a blatant rip-off into something a little bit special.

Multiple columns with CSS3

Turning plain paragraphs into multi-columnar layouts is pretty simple with CSS3 now. The column-count, column-width and column-gap properties let you create equally spaced, equal height columns within an element, and you can break up the flow through judicious use of the column-span or column-break-before properties. You can even add nice newspaper-style dividing lines with the column-rule property.

However, there is one enormous problem with trying to display multiple columns of text on the web: viewport size. In a magazine or newspaper, you can hold the entire page in front of you, and your eye can easily move from the bottom of one column to the top of the next. But on the web, it is entirely possible that your reader has scrolled so far down to read a longer piece of writing that the top of the next column is off the visible page. Breaking off mid-sentence to scroll back up to find the next column is not an optimal reading experience. Overflowing columns

I started to draw up a list of requirements for a solution.

Recipe for a pleasant multi-column read

When you read a book, you are effectively reading a double-spread page with two columns of text. You read the left-hand side, then you read the right-hand side, and then you turn to the next page. Magazines might have four or more columns; newspapers up to seven or eight. But the principle is always the same — your eye is guided from column to column across the page, until you need to move onto the next. So, if on the web you are reading a lengthy piece of writing consisting of many many paragraphs, what we need to do is break it up into chunks that fit nicely into the viewport window. The viewport becomes your double-spread book page, and readers can comfortably read each collection of blocks of text before scrolling down to the next ‘page’ of content. I experimented with a few different methods of achieving this, and eventually arrived at a relatively simple JavaScript solution: View Demo page

We declare a single class to handle the column settings:

This class is applied to the container element, so that even if the script doesn’t run we still get something approximating what we intended.

The script then loops through all of the child elements of the container, moving them in batches into new containers, which each get the same .columns class applied to them — these represent the ‘page’ we discussed above. The size of each ‘page’ is determined through a combination of the viewport size, the font size, and the line height of the site. By supplying a list of those elements that should ‘break out’ of the multi-column ordering, we can make sure that the intended flow of the article is preserved. It’s not perfect, but it prevents columns overflowing the viewport and (I think) makes for a more pleasant, book-like, reading experience.

In browsers that don’t support CSS3’s column properties, the script has no effect, since both ‘before’ and ‘after’ states use the same declarations. (If I was using Modernizr I would probably check for support of those properties first, and not run the script at all if they were not present.)

Improvements and feedback

The script makes a reasonable job of breaking up the content into roughly the right-sized blocks for the viewport, but I’m sure it could be made a lot more accurate than I managed with my rusty maths. It also need to be made a little more flexible in terms of coping with different types of the same content (e.g. inline images and larger full-width pictures), and I can imagine that adding some basic keyboard navigation would make for an even more relaxed read.

I appreciate that this isn’t an implementation that is going to be useful for very many other people, but it was fun to figure out, and if you do happen to use it or have any suggestions for improvements, let me know.

Getting ‘Getting Things Done’ things done

At the start of 2012, one of the things I stated I would do was get a handle on my personal time and project management through implementing a definitive GTD process. Twelve months later, I was still looking… or rather, I had decided the only solution was to roll my own. Back then it was running on Laravel. A few months later, reworked in CodeIgniter for greater development speed, I can honestly say it is up and running.

I’ve been using Ruck for the last couple of months to manage most of my work. I’m also re-reading David Allen’s book again, and the combination of discovering what works and what doesn’t in the alpha app, plus identifying the aspects of the GTD process that are missing or not quite implemented in the right way, is developing into quite a buglist.

Design-wise I was fairly happy with the layout I had worked up a couple of months ago, but as time has gone on I’m finding it more and more inflexible or just plain ugly to live with for much longer. I’ve sketched up some replacement ideas, but I hope this isn’t the first sign of the same endless redesign itch with which my blog was infected. It’s hard to avoid the standard Mac-style “menu on the left, large content area” layout, but I’m not convinced it’s the most efficient way to display different types of content together. Allen says that “hard edges” are important; keeping a clear delineation between your calendar items and other ‘next action’ tasks — to me, that suggests the UI should reflect that separation in a clearer way than just splitting a list with a header.

Once the UX is finalised I think I should be able to get through the various tasks I’ve set myself fairly quickly. The biggest annoyance right now is the delay-after-click that comes from using an online application. Pages have to load, database queries have to fire, and it’s enough to make you feel less than 100% efficient. I did briefly consider starting with a native application, and even got as far as spending an evening reading Objective-C documentation, but common sense prevailed — much better to have a working app that I can use and finesse, than spend six months struggling to make Xcode do what I want it to. When the HTML5 version is done and dusted I’ll move on to converting it for the desktop (and iPad, iPhone and whatever else looks like fun).

Quick Fix: Google Analytics event tracking not working? Check your types!

Google Analytics’s Event Tracking is a powerful way to gain a deeper understanding of what is happening on your website. With event tracking, you can record each click, keypress or mouse move; it becomes easy to find out which fields are being filled or skipped on a form, or which thumbnails are being hovered.

I came across one sneaky gotcha this morning, though. I wanted to track the number that was displayed in a field at the point the user clicked on an “Add” button:

  'Page Updates', 
  'Plus button clicked', 

On reviewing the data in GA, however, none of the clicks were being captured.

It turns out that Google will not record the event if the fourth parameter is of type Number. The simple fix was to make it a String type:

  'Page Updates', 
  'Plus button clicked', 

Normally this wouldn’t come up as JavaScript has a tendency to treat most variables as Strings unless you’re careful about how they are created. In this case, relying on parseInt() to find a number turned out to cause more problems than it solved.

Ready To Inspire: Tammie Lister – Design For Humans Not Robots

Tammie Lister is a designer with a passion for community and users. She runs and tweets as @karmatosed.

  • I am passionate about designing for communities; I love creating ways that people can interact with each other.
  • Sci-fi has taught us that robots don’t do emotion very well. The spark that makes us human is what makes us, us. We have all these modern techniques to help us as we design, but we forget about the passion that we want to inspire in our users.
  • We are 3 brained: Old brain (survival, animal primal), mid brain (emotions, feeling, impulse), new brain (speech, reading, thinking).
  • Multi-tasking is a lie(ish). Humans are only good at doing 2-3 things at once. More than that we feel confusion and frustration. We need simple instructions, to know where we’re going and what to expect.
  • Herding Instinct. We are social animals, we like to interact. We create small pockets within the human herd: Friends, families, conference attendees. Sharing — information, stories, news — we like knowing the latest thing. We are born dependent on each other — born social by our very nature, we don’t do all that well on our own. We mark our lives with weddings, social events, social interactions. We measure ourselves with friends, lovers — more social interactions. But there is a zombie inside us all. Sometimes people will visit your site, blindly wander through, end up in a hole and get frustrated. Don’t expect people to know where they’re going and what they’re looking for. How do you design with this in mind? Lead softly, treat them delicately (but don’t patronise). Make finding easy: What Would Google Do? Their search “simply works.” Allow people to find things easily in your design, don’t hide things. Encourage sharing: Integrate social into site, turning people into promoters. Create safe havens; we find it difficult to open up to large groups of people. Group therapy works because people let their guard down and speak more freely. If you have a forum or allow users to publish personal information, make sure people feel safe and trust you. Recognise that your users are special and not just one of the crowd.
  • The Carrot. The Pokemon effect: Gotta catch ‘em all! People like to collect things, it’s human nature; gamification plays upon that need, delivering positive and negative rewards. Don’t overdose by including every possible gamification trope, though. We learn from play, and that’s what gamification taps into. For example, achievements in World of Warcraft, or badges in Teen Summer Challenge (where users collect badges for completing reading). Gamification isn’t just about completing achievements and collecting badges; Tumblr’s homepage is a leaderboard comprised of the top stories on the site at that moment.
  • Emotional Beings. We like to feel things. If you can create a design that really touches someone, you go straight to connecting to that person. Imagery, colours, copy — there is a whole emotional palette you can draw upon. Sites can use “visual hugs” — little touches that give you an emotional response when you discover them. Use your emotional gauge. How often do you look at design and ask “How does it make you feel?” Try asking that question in user testing. Make it personal; reach out emotionally to the person, allow them to make it ‘a home.’ A personalised area, control over design/colours; greet the user by name, use their avatar, recognise their language. Example: Kickstarter’s Meet the team page. If you have a team page, put faces to names. Willy Wonka interfaces: Those sites where someone is playing, exploring ‘what ifs’, inspires a sense of awe. If you can tap into that emotion, that’s really powerful.
  • Naturally Happy. It’s in our chemical makeup to be happy; we do really well when we’re happy. When you create or design something, make it a positive experience. Freud talks about “The Pleasure Principle”: We like to feel good, on a biological and psychological level. If you have something negative, make it positive. Example: Twitter’s Fail Whale. You miss him if you haven’t seen him for a while! “Turn that frown upside down.” Don’t use “Submit” on a form; you wouldn’t say it in the real world, so why don’t we speak to people as humans? Evernote is a good example of human copywriting. Avoid user pain; simplify choices; keep calm and on track.
  • Great Explorers. We are born explorers. Remember the old Choose Your Own Adventure books? You can design experiences and moments of joy like this, where people can explore your design and site. If you can hide treasures on site that people can discover, it can enhance their enjoyment.
  • These are all aspects of human nature… but what about nurture? You have to be aware of the user’s background, culture, etc. Designers should learn about psychology; you have to know what you’re designing for; this doesn’t just apply to tools and the web medium; you must understand the people you are designing for as well.

Ready To Inspire: Breandan Knowlton – Bridging The Gap Between Designers and Clients

Breandán Knowlton is a UX Designer based in The Hague. His book on Managing Web Projects is available from Five Simple Steps; he blogs at and tweets as @bfk.

  • Will be talking about client culture, design culture, what goes into Great Work, and what to change on your new project. ‘Design’ in the broadest possible sense: Code, graphics, projects, IA, etc.
  • In web projects, you have a mass of creative people, designers of one kind or another… and then the Clients. Sometimes there are misunderstandings about each other. Are our goals the same, or can they be merged together?
  • We tend to think of clients in a specific way — suit, business, money, organisational goals. The culture of design involves looking at design constraints and finding design solutions, via creativity; be inspired, make beautiful things and good experiences. This is not how we think of clients, which is odd, because we are making products together — you need both sides. Good projects involve both kinds of thinking. We’re all people, we want the same kind of feelings out of projects: feelings of energised focus, commitment, and to enjoy the process.
  • In the best partnerships, both partners have space to do Good Work. Definition: “Enjoying doing your best while at the same time contributing to something beyond yourself.”
  • Great projects don’t depend on a single culture.; they depend on everyone working in rhythm, doing good work, being invested — in a state of Flow.
  • Creatives are really good at understanding Flow. More of our web projects could be closer to a state of encouraging flow — and you can control this. Flow just needs three things, and you can create all of them. 1. Immediate feedback. 2. A balance of capability and challenge. 3. Clear goals and progress.
  • For immediate feedback: Work in short cycles. You do something, you see it. This should be easy for designers; you code something and see the effect immediately, whether you’re a software developer, web developer, or visual designer. Social feedback cycles are also short (e.g. Dribbble) — a feedback loop is built into our design cycle. It is harder for clients because they don’t work in the same space. If you put them in charge of content and imagery, it gives them the chance to see their words appearing on screen and creates a feedback loop they are part of. User Testing, which is something we need as part of the design process, can also create a nice feedback loops for clients, helping to bring them into the project.
  • To balance capability and challenge: Both clients and designers spend too much time not being challenged due to their high skill level. To move into a state of Flow, designers tend to increase the level of challenge and set ourselves new goals. The best position to be in is High Challenge, High Skills. We create challenges for ourselves all the time – we started creating responsive, adaptive, elastic grids even before the client asked us to. We’ve pushed web standards in the same way (HTML5, CSS3). The question is how can you challenge the clients so they can experience that same exhilaration of being on the edge of something. Challenge them to know their customers/audience better; to write good copy; to do meaningful research. Even if you have brilliant copywriters, IAs, etc. on the project, you can still assign a lot of work to the client that requires them to ramp up their skill set and gets them engaged and in a state of Flow.
  • Clear Goals. We all like to see where we are. Design culture has a set of goals, client culture has set of goals, and they’re not always the same. For designers, getting paid, preparing for the next gig, portfolios, awards, and learning may be goals. For clients goals may be related to customers and their needs, financial impact, and changes in internal processes. Find goals to agree on: Reflecting the value of an organisation, creating measurable value, finishing the project on time/budget. But be aware that goals are pulling in different directions.
  • Time for action. Here’s what I challenge you to change on your next project: Bring the client into your Flow. Make the short feedback cycles stretch across both designer and client, build in the magnitude of challenge that requires building new skills, increases the amount of challenge, and pushes the client closer to something they are truly engaged in. Recognise that people on the project have different goals. The result: Designer and Client are both in a state of Flow. Both invested. Both learning. Both experiencing the spontaneous joy of creating. It drives what we do.
  • Result: You can do Good Work together; something that neither could create alone.
  • Projects make us super-human. When we start working together, we can build things that are meaningful and big. Create conditions so that everyone involved can have the same sense of excitement.
  • Go do some work that you’re proud of! Find good clients, teach them what they need, and bring them along. Create the conditions where we can find spontaneous and wonderful joy in what we do.

Ready To Inspire: Owen Gregory – A Spanner In The Works

Owen Gregory is a copy editor from the UK. He works on the advent site, and tweets as  @fullcreammilk.

  • Want to draw attention to how we use received ideas about craftsmanship as designers; how traditional physical crafts have influenced our approach to our work, and how we overlook our own materials. A true web aesthetic.
  • This is not a practical talk, there will be no list of tools or resources; it is a talk made out of other peoples words and ideas.
  • ‘Craftsmanship’ carries the glow of history. In an era of commodification and speed, ‘craftsmanship’ is a signifier of time; the master and the apprentice; we appreciate the craft of the people who created things. A well-made item speaks to us of the hand of its maker. ‘Craftsmanship’ is almost as tangible as the objects themselves.
  • Craftspeople make real objects. What do we as web designers and developers have in common with these physical techniques and experiences? Is hand-coded equivalent to hand-made?
  • Practices and disciplines from other areas such as print have informed web design; at the birth of the web, there was no better field available to describe what we were doing. Computer-based work has needed concrete metaphors to help everyone understand: Desktop, window, trash, cut, paste, etc. These metaphors anchor us in reality.
  • We are creative people, making things. There are techniques and best practices; room to learn from experts. We collaborate and compete, and strive to be better at what we do.
  • We have embraced traditional craft disciplines as sources of inspiration. We search for and profess our craft credentials; call ourselves architects and builders and engineers and makers. We clothe our work in the trappings of craft. “Code is poetry.”
  • There is some value and truth in this outlook, but there exists a rarely acknowledged tension between our perception of ourselves as craftspeople, and what craft in the web medium actually involves.
  • This tension does find oblique expression. James Bridle attempted to create the atmosphere of a workshop for code — the This is a working shop project. In a workshop you get the sense a skill is being performed, craft is being done. You understand work, time and skill went into making a thing. Our work, skill and craft are not valued and appreciated in the way traditional work is, which leads to misunderstanding. The invisibility, intangibility and obscurity that goes into our craft turns us into magicians, possessing a body of arcane knowledge. We must be proficient in many disciplines, and understand still more. Our audience doesn’t want to understand how the trick is done, they just want the magic to work.
  • I can’t agree with James that we work with our hands. Working with your hands lies at the heart of craftsmanship… but our hands don’t guide our tools. You can’t run your fingers through elegant JavaScript. We just type, and this is a profound disconnect; all interactions ‘feel’ the same.
  • There is an increasing fetishisation of “the one-off”, the authentic, the hand-made. Web designers have leaned heavily on traditional printing crafts, not just as inspiration but as craft, producing magazines, letterpress posters and books. For a number of web designers, the attraction seems to be the tangibility of the object itself, the process in making it, and the response of people to the object itself.
  • The Manual is a thrice yearly hardback book with a “textured handcrafted feel” that is “a collectible artifact” created because “web design is defining itself as a discipline.” At BuildConf, workshops were held in axe restoration and coffee-making. The Manual was created to inspire reverence in the reader, add weight and heft, texture and the crackle of age, to the intangibility of creating online. There can be a feeling of thinness about developing digitally.
  • Web workers have to be fascinated with process and craft, rather than with finished product… there is no finished product, because it changes immediately, and in time will probably disappear.  The presence and longevity of a physical thing have a value that we aspire to. Craftsmanship invites permanence.
  • Could it be we believe that craftsmanship belongs in the realm of the physical and traditional?
  • Wilson Miner in “When We Build” said he had an inferiority complex to architects and industrial designers that make things. Websites seem flimsy, fragile and fleeting; underserving of serious labour. Even the longest-lasting websites are “a blip on the timeline” compared to a house, car, etc. We are craftspeople shaping the world of screens.
  • Understanding our medium and our tools is essential. Older disciplines are useful foundations, but it is time for us to reassess our relationship to the web. Responsive design  is an example of how empathy with the medium can deliver new techniques.
  • In ALA, Paul Robert Lloyd wrote The Web Aesthetic, where he discussed how we look too much for standardised technical solutions, instead of creating new ones. We rely on things we have done years, rather than reset our assumptions. We should be inspired by the conventions of other media, rather than governed by them.
  • We need  craftsmanship that matches our medium. The web is flexible and mutable, so our craft must be too. Our products are never finished products (Agile acknowledges that). Simply keeping up is a challenge. What kind of crafts can acknowledge the breakneck pace of web development?
  • New tools are appearing — Bootstrap, Typekit, FontDeck, et al — the best tools, the ones that will last and be treasured, are the most appropriate tools, the ones designed for manipulating our unique medium.
  • It’s only through the application of tools in flexible processes by people that understand the medium that the new web craftsmanship can be born.

UX Cambridge: James Chudley, Photos – The Unsung Heroes of User Experience Design

James Chudley is UX Director at CX Partners in Bristol, the author of Smashing UX Design, and a keen amateur photographer. He blogs at and tweets as @chudders. His new eBook on the usability of web photos will be released through next year.

  • I want to change the way you think about web photos. There is an opportunity for designers, directors, users, etc. to think about photos in a new way. As a profession we ignore photos and this is a bad thing.
  • For example: a website for a free food delivery service for the elderly. Put yourself in the shoes of the target audience (the children of the elderly service users). There were key anxieties in users’ minds that hadn’t been considered. Using a snowy photo conveyed the feeling: “They’ll deliver whatever the weather.” How did the user know that? How could you even begin to convey that in text or wireframe?
  • As a photographer, I can take a totally contrived photo; why then as a UX designer do we just stick a box with a cross through the middle?
  • Let’s think about designing a photo. An example from IKEA: wide open to convey space, dynamism/movement, wet foor/white wall to reflect light, etc. There are business considerations, and user considerations when looking at a photo. Can any other type of web content work so hard for your business or your users?
  • We sweat over layout and labelling and think about how people behave. Then we make a square with a cross in as a photo placeholder. This is weird. UXers are very rarely involved with selecting the photos.
  • Where are all the web photo guidelines? There is no photo equivalent of the usability heuristic rules; no rules about ‘what makes a usable photo.’ So I came up with some.
  • So why are photos important? There are quite a few online: 60bn in 2010, 100bn in 2011. Facebook, Instagram, it’s never been a more popular time to share our photos.
  • We are programmed to notice faces and emotions. Using images of people has a huge impact on people viewing it; there’s a part of the brain whose job it is just to recognise faces. You can manipulate where people look on a website by considering gaze lines in photos.
  • We did research on university sites and business services. Users hated generic smiling headshots — photos that worked well with students were of real students doing real things.
  • Facebook have a huge role in creating design patterns around photos, e.g. large photo slideshows, zooming.
  • What message are your website photos giving your users? All the photographer is thinking is ‘what message will this convey’? Example: The AA site uses a photo showing a single woman in the middle of nowhere as it gets dark — manipulates user anxiety.
  • User testing can reveal great insight into how people interpret your photos.
  • Photos are generally either useful (“content photos” e.g. Amazon) or not. Stock photography is used a lot, because photos are hard to find and source, but loses all manner of trust from users (these aren’t real people, I don’t trust this website).
  • Photos can: Support the primary task (property rental sites, product sites); convey intangibles (Buffalo shows photos of UK-based textile workers and their craftsmanship — how would you convey that feeling with any other sort of content?); show the benefits (the gorillapod SLR site shows the product in use); credibility (Arkive used a photo of David Attenborough, which immediately associates them with the brand values of the BBC); show you how ( has large photos showing how to take the battery out of an iPod); humanise technology (; consistency (John Lewis product photos are all framed and lit exactly the same; compare this to eBay photos!); show in detail (zoomable product photos — user testing showed that a main photo with an overlay next to a second zoomed-in block performed best).
  • Strategic use of photos to help sales: Emotive/lifestyle imagery at the start of the section (emotional), then specific product imagery as we shift towards rational decisions, focus on the product, detail.
  • Don’t forget: All of these things are wrapped up in the photos, yet still all we do in mockups is a cross-in-a-box.
  • What qualities does a usable photo have? Aristotle has the answers: Ethos (credibility), Pathos (emotion), Logos (logical persuasion/practical).
  • Rational appeal – will it match, fit, where is it, what do i get, etc. Emotional appeal - does it look good, entertain me, do i want it, does it look fun. Reputation/brand appeal – does it fit the brand, what qualities do i assume it as. [Social - how will i be perceived if i have this thing.]
  • Framework for evaluating web photos: 1. Fundamentals (focus, composition size exposure, quality, crop) 2. Effectiveness (rational appeal, emotional appeal, reputation/brand appeal) 3. Message communicated: What is it saying to you? 4. Anticipated user response: Change behaviour, decision making, sharing, change opinion, create desire.
  • UX people should have input into evaluating photos.
  • Mirror real behaviour on a website, e.g. how do people look at/evaluate shoes in a real shoe shop? Can we mirror that experience online?
  • Photographers’ problems: Offline vs online, cost, digital (i.e. online) is a poor relation to offline (print), brief based on campaign idea not on user needs. Photos taken intended for use on the side of a bus don’t work when you just make it smaller and stick it on a website.
  • Art director/designer problems around photography: Lack of assets, no access to photographer, lack of landscape oriented shots, lack of guidelines, retouching time.
  • Let’s push things forward: Annotate your wireframes (description, key message, photo content, response desired); drop photos into your wireframes; Use photos to tell stories to get empathy; talk to your designers; talk about photos in your usability reports; use real people photos in your personas (if the point of personas is to make you care about your users, don’t use photos of people that don’t exist!); do photo audits in the same way as you do content audits; use task models to create a shot list; and sketch photo briefs.
  • To recap: photos will be having a massive impact upon the way that people are using your products.

The slides from James’s presentation are now up on SlideShare.