On the developers’ mobile mountain

Attending the Over The Air conference 2009 in Imperial College London, I had the chance to assist to some very good sessions, including a cool workshop on designing mobile apps conducted by Thom Hume, MD of Future Platforms in Brighton. Entitled ‘Many ways up the mobile mountain’, the topic was about following an iterative process to build an application for a specific character – intended to act as a market segment – and a specific mobile device.

In teams of 4-5 people, we were all given the same requirements in terms of target market (or character), but almost all different devices.

The target character: Jeremy, keen mountaineer, 42, 2 kids and dyslexic, is not an uber-user of the web and prefers voice chats, but will not mind using emails.

The application was to be designed to help him enjoy his mountaineering experience, while enabling him to share it with friends and family.

Now, that’s where it becomes interesting: each team is given one device on the first iteration of the design, and that will change on the second one. This might seem to be a detail, but as we will see, it had a great impact on some teams later on!

For the first iteration, my team was given a nice wooden representation of a Nokia 6210 which did not have all the fancy gadgets you can find on a top of the range device, and with this in mind, the team went only for a limited, but still relevant set of features that would be do-able on the little handset. But in the process, Matyjas rightly pointed at the fact that for iteration two, we might have a way more rubbish device. And this was the real key of the session for many teams! At the end of this first iteration, we integrated a member from another team to simulate a quick 5-min user testing and got feedback on our “product to-be”. Interestingly, we had Tara, graphic and UX designer from ribot and she commented on the importance of making textual input easy and intuitive. Indeed we had neglected that in what we have been talking about, and this was going to go in the pool of improvements for iteration #2.

After I presented our team’s first app ideas and the “user testing” feedback, we have been handed our second device, which was like an old Sony Ericsson p900. Interestingly, this device was in almost all points identical to the newer nokia, including the screen resolution that was really close, so we decided not to change much of our application, except a slight re-factoring of the proposed UI, as we had a touchscreen with this new device.

My team did not have to apply many changes because the two devices were quite similar, but as already suggested, for others, it’s been a different story altogether. The most impressive change being for teams that initially went berserk on apps features, but were then handed a clam-shell phone without almost all media capabilities. What do you do in that case? Yeah, you’re stuck! One team even considered getting rid their first design altogether!

It was clear at that point, at least to me, that pure developers, like most of the people in the room and some in the team, do not think far enough in the life cycle of their future application. yes, we do have some fantastic high end devices available like the iPhone or the Gphones, but one must not forget that the majority of the users out there:

• don’t own one of these super high end devices
• are not interested into gadget features
• don’t even know what twitter, facebook and other hype social activities are

Hence, if your application is targeted at the average user, there is probably no real need to cram as much of these functions trendy amongst technology savvy users as you can. The UX will only be clearer to everyone, simpler to build and leave you with more time to refine it properly instead of integrating lots of APIs.

Conclusions drawn from this workshop were interesting from a developer point of view, but I think also from a general UX design point of view:

Lessons learned

• Don’t ignore the importance of the key features (The text in our case!)
• Constraints boost creativity and passion (that has to be remembered and repeated everywhere!!)
• More voices help (probably only up to a certain point)
• Basic ideas translate well across devices
• The second iteration helped in refining, or re-defining the application
• User testing helps a lot! (And must probably be always integrated in any project, which is sadly not the case!)

Difficulties encountered

• Starting out is tough, specially in defining the scope of work
• You’re on mobile, so think of the size of these buttons (whether hardware or touchscreen elements). That has been dubbed the gloved man problematic ;)

Changes required for #2

• Device constraints almost pushed some teams to completely throw away their #1

Surprising facts

• Basic devices can be better in some cases (especially when you try to design an app for the average user)
• It’s tempting to over-crowd the app with unnecessary features for the target market
• Paper prototyping helps concentrate more on the actual functionality rather than the polish
• Did I say constraints bring passion?

If this type of exercise might be common practice for designers, being still more of a developer, it was a great session to understand the basic principles of UX and common mistakes made in teams where designers are either neglected, not understood, or even worse, non existent!