A few weeks ago, Matt introduced the User Experience team and gave a first bit of insight on what they do every day. This time, I’ve asked Marc to talk about prototyping and the early stages of creating a new site. - Vero

I’m Marc, a UE Designer working with Matt on the front-end of our mobile web site. A large portion of our role consists of realising ideas and creating prototypes before the production process will begin.

We’ve always been keen on prototyping for three reasons:

1. To design the end-to-end experience
2. To use as a believable product within a User Study
3. And to use as a discussion tool with Engineering.

The level of fidelity for a prototype varies greatly according to the purpose. I’ll talk a bit about each of the three prototyping methods we use in Taptu:

Paper Prototyping

At idea creation, the early concepts are so fluid and likely to change. Because of this we tend to stick with ol’ fashioned pen & paper. Paper prototyping can’t be beaten – even in this digital age, it remains the fastest way to flesh out early use-cases.

It also ensures we don’t get caught up in ‘pixel world’ and other visual design issues until the screen flows, interaction and navigation are all in place. Visual design is so subjective that it’s important to stay clear of it at this stage and stay focussed.
Because we’re talking about little more than just a sketch, it’s quick and easy to just rip a section up and redraw the next iteration.

By the time the scribbles are finalised and we’re happy with the feel of the design and its functions, it’s time to take it to the next stage…

Wireframes

This step seems best suited for concepts aimed at the Desktop-platform. Wireframing in the strangely-named OmniGraffle tool is the speediest method we’ve found. I’ve tried Visio and even Illustrator before settling on Omni. An 80-page spec can be put together with ease, covering all use-cases and page-states. The time we’ve saved documenting allows us to put the time back into designing.

Device Prototypes

This is where we start to focus on pixel detail too. Photoshop is used to compliment the wireframes. Rather than building out each and every page, only the key templates need to be created to avoid repetition.
When it comes to the Mobile-platform, our favoured method is knocking-up static cross-linking XHTML and CSS. This allows us to view the mock-up directly on the mobile, see how it feels on the target platform, and take browser limitations into consideration. Recently we’ve been using the iPhone, N95 and SE W880i as our initial testbed handsets. The Sony Ericssons seem to be pretty popular with our target users – surprisingly, 66% of users in our latest study stated they use a Sony Ericsson.

What happens next?

Well, the above process, although linear in appearance, should be thought of as more of a circle of reiterative design. Each prototype is tested monthly and the findings are then fed back into the next version. The amount of change that is required is usually what dictates which part of the process we’ll go back to refine.

I love tech. I truly do. In fact, I’ve got a severe condition called “gadgetitis”, which becomes particularly acute around tech expos and Christmas time where all sorts of new techy goodies are released. And I love beta versions, even though they’re flakier than Paris Hilton. I love sneak previews, even if the app turns out to only be worthy of the TechCrunch deadpool. It’s a terrible addiction and as far as I know, there are no cures.

By the same logic, I almost always say that the more technology, the better. Almost.

Today’s an exception. This is my plea to the RAC, once my most reliable source of up-to-date traffic news, to step away from the Flash animations and return to this old technology called text. The wonderful thing about text is that it’s clear, succint and doesn’t require any fancy plugins. It’s easy to use when on the road with only a phone at hand.

This new animation completely fails from a usability point of view:

1. It doesn’t respect the KISS rule: Keeping it simple means it’s more widely accessible. Not everyone has Flash enabled. My iPhone certainly doesn’t. :S
2. It’s utterly useless to someone who isn’t local. Very few cities, towns and villages are identified, no matter how close you zoom in. Why aren’t the primary non-motorway roads identified? It’s certainly not because the map is too cluttered!
3. The usefulness of the information displayed is questionable, especially in comparison to the detailed alternative that used to be available. Is the slowdown due to sheer traffic density or are we dealing with a 6 car pile-up where the motorway might get closed? That’s far more likely to affect my decision of what to do next than telling me vehicles are travelling at 10mph.
4. The colours, which represent severity of traffic, aren’t accompanied by a legend, so the user has to guess what the scale is!

With the holidays coming and more people on motorways driving long distances to see family and friends, it can be a lifeline, helping us make a quick decision on whether a detour is needed. I’m afraid that the RAC designers didn’t do their homework here. Back to the drawing board, guys!

[tags]design, gadgets, iphone, mobile, rac, road congestion, traffic, usability, user experience, Taptu, Taptology[/tags]

We’re just going through our next major design revision for Taptu, and it reminds me of just how important to us the whole topic of ‘click-distance’ is.

What is ‘click distance’? It is the sum of the number of clicks and the number of scroll actions that a mobile user must make when navigating to a specific item of content. It’s the critical measure of usability for mobile search.

Back in 2002, Professor Barry Smyth of University College Dublin carried out an experiment on the O2 mobile portal. For a sample of 150,000 users accessing the portal via the mobile browser, he measured their navigation behaviour. Specifically he measured the number of clicks and the number of scrolls that they would make on their phone keypads as they navigated the menu structure of the portal in their search for content. From this experiment came a very simple but incredibly important insight: the motivation of most users to continue navigating for content falls off a cliff when the click-distance exceeds 12.

Back at the end of 2005 we carried out our own research study into click-distance performance of mobile search engines. We asked a panel of users which 100 typical searches they would most like to do on a mobile phone, and which search words they would start with. We then selected the most popular mobile search engine, ran the 100 searches and measured the average click-distance. Shockingly, the average result was 36 clicks. It’s not hard to see why mobile search has yet to go mass market when you see a ‘usability gap’ of this magnitude.

When we design a mobile user interface for a device, or for a device family, the desire to minimise click-distance is always at the front of our minds. It’s become the central proposition of Taptu: how to deliver relevant mobile search results in 10 clicks or less. Needless to say, setting the objective of 10 clicks or less is the easy part. For a universal mobile search service, it is a very tough target.

We’ve just set up an internal research project to update our 2005 findings. This time around we have a lot more data on what mobile users actually search for, so our test database can be much more realistic. In the last couple of years, we’ve seen some improvement in the performance of the existing mobile search engines. We’ve also seen new kinds of devices like the iPhone which can do full Web search on a mobile using the desktop versions of popular search engines.

What effect will this have on click-distance performance for mobile search? Keep you posted.

Big excitement here at Taptu yesterday evening. After 8 months of design and engineering we went live with the first of our private beta invites. We’re keeping it to a very small early group for the first couple of weeks. Then we’ll be opening it up to a larger private beta before we launch at the Mobile 2.0 conference in San Francisco in the middle of October. Very promising early feedback so far, and now we’re just itching to take it public. (By the way, you can join the beta mailing list here)

Very nice of Rudy de Waele to praise our “super-simple design interface”. You can’t imagine how much effort has gone into getting this right. Since January we’ve run 7 studies in our new user experience lab testing different aspects of the UI, that’s 70 users giving us their candid opinion from hands-on use and abuse of our prototypes.

Our engineering team have done a pretty amazing job since we started in January. We took the decision to use open source infrastructure components wherever we could, but this still left a lot of gaps to fill if we were going to deliver on our goal of a fully-clustered, triple-redundant, fault-tolerant architecture running on commodity 1U servers, scaleable to millions of users. An architecture which also has to serve results pages in an optimised and reliable way to hundreds of different handsets across a multiplicity of GSM and CDMA mobile networks. Now we’ve taken a very big step closer towards this goal.

Our novel social-assisted search (SAS) approach means that we also have to write custom crawlers and parsers for each content category (music, movies, sports, etc) which we point at our selected social Web source sites. Now we have the basic infrastructure for all this in place we can begin to add additional content categories at a much faster pace. So expect to see a rapid expansion of the scope of our system over the next 6 months.

Today, Taptu is a universal mobile search engine, but the SAS optimization approach is only applied to music. With SAS switched on, we can give you useful results almost all the time in 10 clicks or less. Without it, we fall back to the 25 or more clicks that you normally see in today’s mobile search engines. So for searches outside music, Taptu doesn’t perform any better today than the big 3 mobile search engines (for us, the big 3 means Google, Yahoo and Microsoft) . This will change as we switch on SAS for other big categories like movies, travel, sport, games, and mobile web. Then you’ll really see what SAS can do.