Lessons From Google Mobile

Google’s NYC office hosted a sold out last month’s meeting of the New York City Usability Professionals Association (NYC UPA), featuring a presentation by Leland Rechis, a UX designer in their mobile team. Exactly the sort of hyper-intelligent bespectacled geek one hopes to meet there, Rechis surveyed the key insights the UX group learned while building Google’s “mobile search product”:http://www.google.com/mobile.

Taken aback by the scale of the development effort, I began to wonder how many of the lessons learned were even relevant if you aren’t Google, or at least Google-sized. The basic problems of translating existing services and brands over to the mobile space concern many smaller organizations, but Rechis demonstrated that becoming a global mobile presence presents extraordinary challenges.

Basic problem solving still completely swamps any other creative concern when working on mobile sites. A refreshing blast of Spartan usability problems, mobile site design is uncluttered with your typical mamby-pamby web problems. Can a user get the information, and fast? Answer this question and you’re far ahead of everyone else.

The design process described was quite effective at powering through a lot of basic usability problems, but struck me as potentially ill suited to a younger project that might still be finding itself.

Here are four key points I took home:

Designing a good mobile web user experience requires seemingly endless device, location, and use-specific hacks.

Of course, rendering inconsistency on mobile browsers is worse than it ever was on desktop browsers. Variation in device input (keys, buttons, stick) and output (screen size) create dramatic UI problems that don’t seem to be going away. Plenty more issues can be traced to local carrier hegemony. Regional patterns of use develop based upon the network capability, handset manufacturer, and content formats most popular in any area. If anything, these differences seem to continue diverging, turning much of the design process into a maddening branching problem. Further customizations to the experience based upon the type of search result proved to be another key ingredient. As browsing a large feature set on a mobile device is so cumbersome, it is critical to intuit the user’s next action and place it accordingly: get directions here, buy those movie tickets, call this person.

A shallow learning curve is essential.

Each successful interaction, no matter how minor, invests the user in the application experience. Rechis stressed the importance of always placing low hanging fruit on the first screen to build user confidence. Further personalization efforts highlight only the features users have used or requested. This is good general advice, but critical in mobile applications where the UI standards are few, and the failure modes extraordinarily frustrating. It’s worth remembering that the vast majority of Americans don’t even know their phone has a browser.

Localization for the mobile experience is more complex than ever.

It was plainly apparent that we (some small subset of geeky Americans) have simply no idea what the rest of the world expects from their phones. Even with most device, network, and language issues solved, we can still be far from creating an application with any kind of cultural relevance. Basic local conventions complicate something as simple as a web search. Europeans expect a compact page with a few precise links, while many Asian consumers on high-bandwidth networks expect results as screenfuls of colorful content. Driving directions have to be formulated with wayfaring devices that are locally relevant. Familiarity with the technology varies drastically and direct research in all of these different cultural contexts is the only way to tackle any of these problems.

The UX techniques you know and love are compatible with AGILE development.

The mobile team used an AGILE process (but not all of Google necessarily). If you aren’t already using one yourself, trends say you’re likely to come across it soon. I found the way UX and usability techniques were integrated perfectly sensible and a useful validation of many of the concepts well loved on B&A.

An upfront “ideation sprint” was focused on detailing a primary use case. Weekly development sprints were coupled with weekly usability tests, constantly testing the features delivered or modified in the previous sprint. And in the most astonishing detail, the UX team actually gets to sign off on engineers’ work before each release. Progress! These little process details were valuable nuggets for anyone on similar teams.

So to wrap up

  • Weekly usability cycles good
  • AGILE fits all parts of the design/development process.
  • Global mobile site bad, unless you’re Google
  • Volunteering at your local UPA chapter also good

Posted in Conferences and Events, Learning From Others, Reviews, Special topic: Mobile UX | 2 Comments »

2 Comments

  • Wayne Pan

    May 22, 2007 at 9:12 pm

    “Designing a good mobile web user experience requires seemingly endless device, location, and use-specific hacks.”
    To minimize the affects of the use-specific hacks everybody should check out WURFL – http://wurfl.sourceforge.net/

  • Terry Bleizeffer

    May 31, 2007 at 11:27 am

    Agile development and UX is an intriguing subject. On the one hand, for those of us working on products that have two-year release cycles, the ability to make incremental improvements over relatively short intervals is very appealing. On the other hand, I’ve heard from UXers working in Agile teams that they can ONLY make incremental improvements… that it’s extremely difficult to get any changes accepted that require more than a single iteration to complete.

    Regarding Google, it sounds like they were using a “brute force” style of UX on this project. As Max says, it’s hard to know whether that translates well to the rest of the world, where every UX decision from process to design is intimately tied to limited resources. I wonder how Google has justified their UX expense internally… or whether they haven’t needed to on the grounds that Google has more money than they can spend anyway. A nice problem to have. =)

Sorry, comments are closed.