Appticles

4 Steps to Prototyping an Application for Your Mobile Web Users

As a publisher, more often than not you are creating content; readable, viewable, consumable content. At the most fundamental level, users will most likely engage with your content when it provides value for them. In reality however, this is only the first building block on your way to getting users to engage with your content.

I will assume that you already have valuable content and the problems you are facing are of another nature. Once you have this in place, the next questions that are critical to address are:


These two questions are very important to address. As more and more publishers have a mobile presence, whether your users have access to your content when they need it and where they need it becomes critical. The same goes for their reading experience: they want to read, share and generally interact with your content as seamless as possible. Nothing should get in the way.

But before you jump in and start spending money for a shiny new app, you probably need to know if it will be worth it. Here’s why that’s critical: 85% of a user’s time on mobile phone is spent on apps, but the majority of that time is spent only on a few apps. That’s why you need to test your assumptions before actually investing in an app.

This is where prototyping can help. You create a dirt-cheap version of your application with pen and paper and then you test the hell out of it with your potential users. This will not only save you precious time and money but also reduce the risk of not knowing whether you’re application will resonate with your users.

Now let’s see what we need to get started:

Sounds silly? It’s actually not. Once you realise that you can approximate a $600 phone with a few sheets of sticky notes, you are well ahead of what most people do when they decide they need a mobile website or an app.

If you feel your drawing skills are bad, worry not. Remember you are looking to test your assumptions, not create an accurate representation of your final interface. Greg Nudelman, UX Consultant and author of the 1$ Prototype said it best – “the state of completion of the system must be reflected in the state of the prototype”.

Let’s now break down each step and dive deep into the process so that by the end of it, by following closely, you will be able to take the information in this post and prototype the first version of your mobile application.

Step 1 – Set Up the Context

The first step involves a lot of thinking about the use-cases for your mobile application. And while it may be tempting to skip this step, you risk failing to put the ideas you have about your users in a coherent narrative, and not aligning yourself with other members of your team.

You will need to think about a compelling use-case and user profile for your app. A few questions to get you started:

Then, armed with a pencil and 5-8 3×3 post-it notes create a storyboard illustrating a compelling use-case for your application. Here’s an example of how that might look:

Source: http://kathybateman.com/2013/09/06/hci-course-part-2/

Sounds hard? It doesn’t have to be. While it does indeed take time to master this process, remember your goal is not to become a master at storyboarding, but just good enough to serve the next two steps: prototyping and testing. There are however guidelines that you can follow to ensure interesting and effective storyboards:

Step 2 – The Actual Prototyping

After you’ve settled the vision in your head and on paper it’s time to move to the second and most important step – actually prototyping your application. First we need to see what is the overarching objective.

Let’s really make this stuff applicable and work our way through this step using an example. Imagine you are TechBunch, a technology focused publisher who is seeing encouraging growth in web traffic. On mobile however, things don’t look so rosy. You realize it’s important to attract more mobile users and you’ve made a lot of research into other publishers. So you decide you want to have a mobile application that will be available to your users regardless of their favorite mobile device. But, and here are the problems: you’ve never done this before, your budget is quite limited and so you can’t go around and shop for an agency to take on your project and hope for the best. You need a proven, repeatable process that just works.

So you need to start somewhere and after deciding the vision for the app and then setting the objective for the mobile application – the user should have a sense of freedom and empowerment when using the app; the most important information he/she needs shouldn’t be more than a few taps away.

With a clear idea of what the prototype should enable the user to do, a more practical question comes to mind – Where do I start with my design? The answer here is to start on your application’s home screen. We’ll use the list of links design pattern, which means creating a list of things that a user would want to see in the home screen of your application. For you this might be a list of categories:

Think of your homepage as a hub to all the different content areas you offer. You have a list of categories from which users can choose and read content from the one they’re most interested in. If you don’t like this pattern, you don’t have to stick to it. It serves a starting point for the things you want included in your app. Once you know what you want included, you are ready to move to the next step – organising this information in a way that makes sense for your users.

From a usability perspective, using this pattern, your users will immediately see the different subject areas you cover as a publisher, but they still need to select a category to see the actual content. This is where other core design patterns employed by some of the largest publishers come into play. Generally, if it’s a design problem you are facing you start by looking at what other larger publishers have done in the same situation. You want to stand on the shoulders of giants not reinvent the wheel.

Exhibit 1 – Engadget mobile application

Take for example Engadget.com, their approach consists of two lists on the home screen: a horizontal one which includes a preview of popular articles and a vertical showcasing a scrollable list of recent articles. For the category view they appealed to a sliding menu, where they store their different categories of content. It is an improvement on the list-of-links pattern, as the user is taken straight to articles from this publisher while still having easy access to the content hub on the side, which reveals itself with a swipe.

Exhibit 2 – Google Newsstand Application

Another great example is Google’s Newsstand – a content aggregator platform for different sources and domains. Google News employs a relatively new approach of offering both the content hub and the content in the same page so that your users see what categories interest them as well as having preview of the content from that category.

So what do you at TechBunch have after this exercise in inspiration?

You have a list with the content you want to include, how you want to separate the different types of content and several established patterns to start from and structure your application on. But for the sake of example let’s assume the worst case scenario here. Your team can’t decide between the two navigation patterns. One half wants to go with the approach employed by Engadget the other with the one used by Google.

Which one is better? What should you go for?

While these debates have torn down teams in the past, what you can do is prototype two different versions of the same app and see which one gets a better response in testing from users. For this you need to mock-up 3-5 screens using 3×5 post-it notes showcasing interaction with your application. Here’s a basic list of use-cases that the app should cover along with two different versions of the homescreen:

Since everything else is agreed upon by the team, I will only illustrate the two versions for the homescreen that you would need to test. You will probably notice that the drawings here are terrible, apparently I have the drawing skills of a 5 year old. But that is exactly the point, If I can do this then really anyone over the age of 5 can as well.

Here we have the navigation pattern inspired by Google’s Newsstand. The main view is split into two unequal halves: the top half with a horizontal list of scrollable categories, and the bottom half which displays articles from a selected category.

And here we have the one inspired from Engadget which includes a side-menu for choosing categories from which to display the content.

As you can see a normal 3×5 post-it is used to sketch out the main navigation elements. For the elements that are hidden and are revealed by a user’s action, a different color sheet is used to highlight that it is an additional layer. There’s no rule as to what to include in your paper prototypes, but I chose elements from moqups.com, which is a quick prototyping tool with a wide list of core navigation elements. Last but not least, while the precision of the drawing does not really matter; make sure you populate the post it with real content, the kind that you would expect your users to see in your app; no placeholders. This is even more so important in publishing where the core of your offering is the content itself – so make sure you’ve got this covered.

Step 3 – Testing

The third and final step in the process is essential and often times neglected. Remember, as much as you grow attached to your project, you should never ignore the voice of your users. They will be the one who will either use your app or ignore it.

In this section you will learn what it takes to test your paper prototype quickly and effectively, where to test it and how to make sure you get useful information from your testers.

So in our example, you decided your app is aimed at tech-enthusiasts, people that want to follow developments in the technology industry be there gadgets, startups or other technological developments. It’s great to think of a clear persona for your mobile application as it will be much easier after this exercise to think where you might find people that fit the description. In this example you found that coffee shops are the places where many people often times often work from their laptops and so they are technologically literate and there are high chances that they fit the persona you are looking for.

After finding and describing your users’ persona and brainstorming places you might find them in, there are a few things you need to keep in mind to get valid results from your testing:

After collecting and sorting all the answers you found that the pattern used by Google’s Newsstand performed much better in testing and decided you are going to stick to it. Because you’ve only used pen and paper to draw out the different versions of the application you avoided the pitfalls of creating a high-fidelity mockup from the start. Which becomes a problem both in terms of time and money, given that requirements at an early stage change quite often.

Now that they’ve got the vision, the requirements and a version of the design that tests well with users they can move on to a higher-fidelity mockups and finally building the application. Here’s a rundown of how your product evolved from concept, to prototype to high fidelity mockup.

Wrap up

Wohoa, that’s probably a lot to take in so let’s summarise some of the key learnings from the TechBunch example regarding the prototyping process:

After reading this post I hope you are in a better position to no longer postpone getting a mobile presence and acting on that feeling with a detailed and structured process that is hopefully easy to follow. If you want more information, then I really recommend reading the 1$ Prototype by Greg Nudelman. It covers so much more then it’s possible to cover in this article and it is a great resource for anyone who wants to do mobile and do it right. But really nothing can replace applying the process in the article for your own site. So get out there, start prototyping and share your findings!