Mobile app projects – so different to web projects

28 09 2010

My first mobile app project began about 6 weeks ago with user requirements definition, and immediately I was struck by the difference of working on a mobile app project rather than a standard web project. I mean sure, there are differences in the technology that are always going to make it slightly different – but I didn’t quite expect the project to work so differently for me as a project sponsor, usability champion and of course, OCD tester.

Smaller means sharper

First up, the definition process was different. From a design perspective, you have to be far more aware of the different ways that your tiny, quick words can be interpreted. You have to be more specific, and use layout to lend logic to your navigation rather than relying on words alone.

For example, a button called ‘Account Manager’ could mean ‘Manage my account details’ or ‘My Account Manager’s contact details’ or ‘Contact my Account Manager’. All of those options are simply too long for a mobile app where two extra words per button creates clutter. But by looking at your 6 options on your landing page (what’s the equivalent term for landing page on a mobile app anyone?) you can group them logically to reinforce that this option is actually the Account Manager’s contacts rather than an account details management function. Or, you can add another button that indicates functionality for the other possibility and so provide clarity by natural elimination logic.

With a web based project, you’ve got more options. Explanatory hovers, more space and flexibility to use more words, groupings and headings and navigation locations. There are some usability people that believe that you should design websites with the same kind of design principles as a mobile site, and think that the flexibility I talk about shouldn’t be there. But I’m not quite as strict as that – sure, I’m a Nazi about clarity, but an extra couple words in a title aren’t going to kill anyone.

Smaller means flatter

Instinctively, I feel that flatter, less hierarchical structures work better with Mobile apps. Bu I think the same is generally true with websites. The difference is that with a website, you have more than one place to enhance the flatness of your navigation, because you don’t just have your landing page – you’ve got places everywhere that you can put quicklinks in, and you can still have a clean, clutter-free site even if your landing page is a portal to almost all main places in your website.

The sky is not the limit

Websites need volumes of pages for SEO purposes. More pages, more specific URL’s, more links. But Mobile apps don’t, and volumes of pages means your users are going to get lost. So with our Mobile app, I found myself prioritising more strictly than ever before. I’m a massive fan of providing easy access to self-service options as a customer service efficiency, but the ease of navigating the app is more important than allowing someone to find the answer to the question ‘How to use the Mobile app’.  Other items also get culled, things that are firm business priorities under normal circumstances (driving newsletter sign-ups, RSS feeds and social media). As a project sponsor, you find yourself focusing on a very small insular goal, and that doesn’t come naturally to me as someone who constantly looks for opportunities to generate extra side-benefits from a project.

User testing needs better articulation

I’m not a technical person, but I seem to have a knack for talking to technical people in language they understand – often aided by using screenshots. But how do you do that with an iPhone app?

1. Think of something obvious

Take a photo of your phone with another camera? Too inefficient.

2. Turn away from your own brain and use other peoples

Search the internet for a solution. Advice from 2008 involves holding your ‘Home’ button down and then pressing the ‘Sleep’ button. New developments mean that this is now often set up for activating voice control, fail. Other options are to use code, the iPhone simulator, and X-Code – all of which are great for techies who’ve already got the simulator but not for your average user unless you’re investing a lot into your user testing rather than just using the cheap option which is to send the app to your friends and favourite customers and ask them to play.

I’ve lumped for simply using words, which means I have to be incredibly articulate about what I mean as opposed to taking a screenshot and circling something with the words ‘this is skew’. I’m okay with that but friends and customers might not have the same motivation…

I’m sure there are loads more differences. I’ve enjoyed working on this project quite simply because it’s different and challenges me to think about design more strictly, goals more specifically, and words or meanings more anally. It appeals to my OCD too, because it feels altogether more within my full control than a website that (if it’s of any size) is almost impossible to fully control at all times even if you invest in a ridiculous amount of people as OCD as I am…




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: