London Web Meetup: Top 10 UX Gotchas

Review: London Web May: Top 10 UX Gotchas, Conference learnings & Traffic kickstarts at Hoxton Apprentice, 16 Hoxton Square, London. N1 6NT. 19:30 to 21:30

With UX London in full swing, this month's London Web had a usability focus. Google's George Zafirovski was in town and had agreed to give a talk on the top ten User Experience gotchas. By way of introduction George talked about the user experience design team at Google. Many people with long experience of Google's products may be surprised to hear they have any usability engineers, but there is increasing focus on usability throughout the company. There are UX teams in many of Google's offices available for to engineers and product managers for consultation, and (apparently) there are adverts for their services in the toilets. As well as being the 'fluid glue' which holds the engineers and product managers together, user experience research can also initiate products such as the recently launched mobile services in Africa.

In order to assemble this talk George asked his UX colleagues at Google to nominate their own gotchas, and then compiled the top ten from their feedback:

1. "I skipped the wireframes and produced hi-fi mocks instead." - By going straight to a hi-fi mockup you lock yourself in to a single solution. Better solutions can usually be found by comparing a number of approaches, and you can produce multiple lo-fi mockups in the time it takes you to produce a single hi-fi one.

2. "We don't have time to test it." - You never get a second chance to make a first impression, don't spoil it by having a glaring issue which would have been quickly picked up in testing.

3. "Just make it a setting." - This can lead to a cascade of UX issues, both in controlling the settings themselves and in the combinatorial explosion of possible interfaces engendered by the settings.

4. "We only want to test with savvy users." - If only savvy users can use it, then you don't have a usable application. "Passengers will one day become drivers" - if you just consider the needs of the main user (the 'driver'), then the less experienced users (the 'passengers') will not choose your product even when they've gained the experitise to use it.

5. "We'll let the translator worry about it." - Issues like sizes of buttons to accommodate labels and bidi need to be dealt with in the original design, the translator can't be expected to re-design your application just to make it usable in a different language.

6. "We'll launch this and then figure out how people use it." - If you don't know how to use it when you launch, how will your users figure it out?

7. "We'll fix this in version two." - Similar to 2, if you mess up the version one then many people will not even look at version two.

8. "The target user is a late-twenties technology professional." - There's no such thing as a late-twenties technology professional. Even within that seemingly homogeneous group there is huge variety, don't kid yourself that because one late-twenties technology professional finds your application usable that anyone else will.

9. "If you build it, they will come." - If it's not usable, they'll leave again.

10. "Who is this for?" - Don't ask this question, assume it will be for everyone.

After the talk there was a Q&A, I made some notes about the ones I found interesting. The first question referred to point 8 - do they use personas at Google? George said that they don't, they try to design for everyone rather than focus on individuals.

The next question referred to a comment George had made during the talk, that Google would never compromise the user experience in order to make more money. Several people advanced the opinion that advertising decreased usability, and, since advertising is Google's primary revenue stream, there was a built in conflict of interest there. George said that people do click on the ads, so the ads are useful, and advertising is subject to usability testing the same as everything else.

There was a question about what user testing tools are used at Google, George's answer was "everything." They do wireframing, paper prototyping, cognitive walkthroughs, usability studies every one to two months during development and also, because they practice dogfooding, they get period of free user testing from a pool of ~20000 users, all of whom have direct access to the bug database, before public launch.

An audience member asked that, since Google is famous for releasing lean products, is that strategy not in contravention of several of the gotchas on the list? I think this question struck a chord with many of the attendees - George himself had said Google have an agile, "release early, release often" approach which seems to contradict at least six and seven off his list if not more.

For the second talk, Mike Martin had been drafted in at the last minute to cover 'Growing a Social Network' in place of the originally planned 'Site Traffic kickstart'. I didn't take too many notes for this one, the basic advice is:

  • Pick a niche or an event to focus your site around initially, people don't want to join a site with no activity
  • Provide good (link worthy) content, and provide (and consume) APIs so that others can take advantage of it
  • Take part in the conversation, talk about your site, your network and your content on other social networking sites

Another good evening, interesting to see inside the UX mind of Google, a shame Mike hadn't had a bit more time to prepare his talk, but 4.5 out of 5.

Technorati tags for this review: