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:
- How do I make my content more accessible ?
- How do I make the interaction between the user and the content as seamless as possible ?
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:
- 2 packs of post-it notes; one 3×3, another 3×5.
- and a pencil.
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:
- Where would your user most likely be when he interacts with your content?
- What is it that triggers getting to your application and interacting with your content?
- How would your users interact with your app?
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:
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:
- Think of a scenario; imagine you are the user, where would you be? what would you do?
- Transport your storyboard readers in the story by establishing a strong sense of place.
- Use thought balloons as much as possible to tell the story with the characters’ own voices.
- Treat the mobile device interface interface as a third person in the story.
- Keep the number of storyboard panels between 5 and 8. Obviously if you feel your story comes across as incomplete, just add a few panels that help explain the missing bits.
- The final panel should show the benefit of using your mobile app.
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:
- Recent News
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.
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.
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:
- Navigating through a list of articles in a category
- Selecting a different category of content
- Viewing an article and sharing it with other users
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:
- Keep in mind what you are testing for – TechBunch was looking to validate the idea of a mobile app for publishing tech-focused content and decide which of the two versions of the application is more suited for its users.
- Don’t tell the user what to do – Allow the user to navigate your app on his own as much as possible. Let him struggle, so that you know where you have navigation problems.
- Don’t ask leading questions – Whatever you do make sure you avoid asking leading questions. See the difference between: Why did you like this app vs How was your experience?
- Offer to pay for their coffee – This is not a must and generally people are willing to help you for free, but your testers will be more open when someone acknowledges that their time is important.
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.
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:
- First establish the vision for your application, find a compelling use-case and put it into a storyboard format.
- Second – For prototyping start with the list-of-links pattern on your app’s homescreen and sketch-out the different actions the users will undertake inside your application. Don’t be afraid to get inspired by other publishers and from established patterns. Remember, established patterns means a large majority of people already know how to navigate with that pattern.
- Remember debates are settled outside the office. Create several prototypes and run real-world tests to establish the version you choose for the final application.
- Create a detailed persona of your users, and brainstorm places you might find them in; then go out and talk to them – there is no better substitute.
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!