You now know who you’re writing for and how they’ll react to your website, and those are the top two priorities. It’s time to determine how you should prioritize the features of your interface in response to the user scenarios you’ve created.
Je Sauro, founder of Measuring Usability LLC, explains how to handle the multitude of tasks every designer has on their to-do pile. He encourages using a strategy of having prospective users themselves prioritize the tasks for you, originally proposed by Gerry McGovern in his book The Stranger’s Long Neck.

  1. List the tasks — Identify features, content, and functionality that need to be addressed, and list them in the users’ language, avoiding technical jargon. Present them in a randomized order to representative users you think might be interested in your site.
  2. Ask the users to pick five — If you’ve properly laid out all the tasks, then there should be a lot. The user will skim the list for keywords, and notate the ones important to them.
  3. Graph and analyze — Count up the votes and divide by the number of users.

Typically this forms the “long neck” shape, hence McGovern’s title.

Screen Shot 2016-07-28 at 3.27.27 PM

That’s the basic gist: not only do you now know what your top priorities should be, but you have them veri ed by your users. Sauro explains in another article how this long neck organization of problems coincides with the Pareto principle.

Proposed by Italian economist Vilfredo Pareto in 1906, the Pareto principle — or the 80-20 rule — brought to light that 80% of the country’s wealth and land was owned by 20% of the people. But this extends beyond economics. As it turns out, many things follow the Pareto principle, more-or-less:

  • 68% of U.S. taxes are paid by the top 20%.
  • 90% of wireless bandwidth is consumed by 10% of the cell phone users.
  • Microsoft noted that by xing the top 20% of the most reported bugs, 80% of the errors and crashes would be eliminated.
  • Did that last one catch your attention? If you’ve been paying attention, you’ll see that by addressing the top tasks in your long neck graph rst, you’ll end up taking care of most of the problems quickly. After all, it worked for Microsoft.

    As complementary methods, you can also use the Kano method, QFD method, and cause & e ect diagrams to prioritize user needs for your web interface.

    Plunging Ahead with a Plan

    You have your personas on hand for reference, you know how they’d theoretically react to the site, and you know what tasks must be accomplishable by the interface. You are a designer with a plan, and all that’s left is to put that plan into action.

    But there’s a lot to be said about how you put your plan into action, not just that it gets done. In the next section, we’ll talk about how to visually prioritize elements of the interface, plus effective patterns and how/when to use them.


You have your cast of characters, but the plot is still lacking. After you’ve nished your research and created a group of personas based on your target users, one of the best ways to connect mindset to action is by creating user scenarios. User scenarios are thought exercises where you map out the actions of each persona from the rst point of interaction with your website to when they complete a goal.

If your personas cannot achieve their goals or if the process is too convoluted, then you now have a visual representation of your problem and can go back and solve
it easily. User scenarios are one of the best way to test your site structure because they isolate problems before they become problems and also help you think of ways to improve your structure. Just as with personas, the more actual research and less guesswork, the better. We’ll explain how to turn personas into user scenarios and analyze a real user scenario.


Step one in creating a scenario is to create realistic goals for your personas. From there, it is just a logic puzzle. When it comes to user scenarios, there are three main categories: goal-based scenarios, elaborated scenarios, and full task scenarios. Goal-based are the most straightforward while elaborated scenarios read more like “persona stories”. We won’t describe all of them in detail here, but we will provide a process that is helpful regardless of scenario type.

Each user scenario starts with a user story, structured as “As a [role], [the persona] wants to [complete this action] so they can [ful ll this goal]”. A user scenario will then expand upon user stories by including details about how your system could be interpreted, experienced, and used. Ben Hunt, creator of Web Design From Scratch, believes that scenarios add elasticity to personas by lling in the “why” behind the “who”. When creating user scenarios, you should consider:

  • The persona’s environment — Where are they when they interact with your web site? Are they at work? At a co ee shop? Or at home?
  • Any factors that impact the context of use — How fast and stable is their Internet connection? How much time do they have? What distractions are there?
    • Triggering events & goals — What speci c goal motivates the persona to interact with the web site on this occasion? What event triggered this scenario?
    • Persona behavior — Visualize the scene. What considerations are most important in the persona’s mind? What clues are they looking for in particular?


To introduce teamwork into the process, you can also follow this collaborative 13-step guide to creating user scenarios.


Let’s look at a real-life example for the website of LUX, an international arts agency based in London. A non-pro t charity, LUX provides access to various types of video art through their website and gives developmental support for moving image artists.

The whole process starts with a persona, Harriet, and her problem — her motivation for using the site. The hypothetical user story could be that “As a local art event organizer, Harriet needs to nd a great lm for her December event so that the event sells out and her boss loves her”.

As you can see by the user scenario ow chart, Harriet makes her entry on the Homepage and conducts a search. After exploring some options, she nds a lm that interests her, but only after viewing a clip. She then reads some details about the lm, including reviews from both LUX and other searchers, plus bookmarks the artist for later screenings. Finally she puts the lm in her basket and hires the artist during checkout. She has successfully completed her goal of nding a lm.
Note that many details regarding motivations and thought processes are laid out on the chart, giving whoever reviews the fullest understanding possible. Because this can get confusing, color-coding based on the di erent pages can be helpful. Also note that the “Explore” and “Search” phase seemed to be cyclical — an important detail for the company to know.

Design for the platform, unless you want to stand out

There are at least two distinct paradigms which can be considered when designing for tablets; design for the platform and its users, or design for a consistent experience. The former, which considers established user familiarities around a particular system whilst more closely adhering to the manufacturers UI (user interface) guidelines, could be argued the more utilitarian, less creative approach to application and interface creation. The latter paradigm is more concerned with providing a seamless experience nascent to the delivery platform – this approach, although contradicting the manufacturers intentions does actually work well for users who access a brand or application via several different devices and platforms.

Responding to its environment

The development philosophy of responsive design is one which caters for any number of devices and their requirements. Adopting this approach means challenging the traditional way designers think about priority, function and layout amongst other factors, which is considered a good thing since the result will aim to produce the best possible end-user experience.

Delight through interaction

Designing for the tablet should not be a challenge, but should be viewed as a set of different challenges. Once understood, learned and pushed these factors can subsequently create a slew of device-centric innovations, both in terms of visual design and interaction design; ranging from  skeuomorphic aesthetics and augmented reality usage to understanding and adhering to Fitts law – the positive effect of user engagement is without doubt enhanced as a result.

How personas and prioritized requirements influence the UI

“Know your audience.” It’s advice as old as Homer (Athens, not Spring eld). While this is a practice ingrained in every great writer, it can be easy to overlook as you immerse yourself in the visual details, typographies, and layouts of web user interfaces.

Screen Shot 2016-07-28 at 1.47.39 PM

Now that you know how UI and UX are interwoven, we’ll get into the nitty-gritty of Step 0 to creating an e ective user interface. Before you start with the visual process, it helps to look at the why behind the how. Who are your users? What are their motivations, fears, and aspirations? What goals do they want to accomplish on your website?

User interfaces require visual hierarchies, and visual hierarchies must stem from user requirements. We’ll look at how to create user personas, how to incorporate personas into user scenarios, and how to prioritize requirements for your interface.

Personas: Your Imaginary Best Friends

In web design, personas are ctional representations of your target user base. Imagine the kinds of people who will visit your site, and then detail their personalities so you can predict and anticipate their behavior when the esh-and- blood versions actually visit your site. Below, we’ll explain how to create personas and use real data to explain why they’re helpful for user interfaces.


How detailed should you get? As detailed as possible. As discussed in the Guide to UX Design Process & Documentation, detailed personas serve dual purposes as documentation for your team and as another person in the room when making design decisions. For example, if a persona indicates that they use search to navigate websites, then your search box must be prominent in the UI. Likewise, if a persona says that they dislike banner ads, your website should use more contextual links instead.

Justin Smith, UX Architect for Cartoon Network, recommends adding enough details so that you can understand a the user’s mindset, desires, and the tasks they will perform. Your website will have two audiences: the core audience (the one
your website can’t do without) and the fringe audience (everyone else). If you’re strapped for time and resources, you should focus your personas on just the core audience — but the goal is to cover both if possible. When creating a persona, make sure you:

”Prioritizing user requirements is Step 0 of designing your interface.”

  • Give the persona a name — You can choose whatever name you like,
    but make it real so the person feels real. The name can also be labeled by behavioral segment, such as “Sam the Searcher”. Later on, you can even design specific calls to action for each segmented persona.
  • Identify the job, role, and company — Surveys can be very helpful for capturing this data. For example, Bu er conducted a survey which showed a large percentage of users are small business owners. They then used this information to create a specific “SMB” persona.
  • Include vivid information — While age, gender, and device usage are important, you also want to describe psychology. What are their fears and aspirations? You can use metrics tools for demographics and educated guesses for psychographics.


While it’s tempting to think of this as a strictly creative exercise, it’s important that your personas are based on actual research. “Don’t make up personas only from demographic and psychographic data,” advises Jared Spool, founder of User Interface Engineering and popular UI speaker. “Instead, focus primarily on your target audience’s behaviors. The more people you visit, the more likely your personas will reflect real audiences and produce the great design insights you seek.”

Screen Shot 2016-07-28 at 1.37.37 PM

Similar to Buyer’s survey, Spool recommends that the team conduct a round of eld research before attempting a persona project. He cites that, of all the teams he spoke with, all of the successful ones had conducted their own research as part of the project, while all the failed ones had not. Because personas are such a valuable tool for UI designers, Spool continues to suggest that all core team members (not just user researchers) be involved in collecting the research. The more familiarity these in uencers have with their target audience, the closer the nal website will get to the mark.

As you start building out your personas, you can keep them better rooted in reality by conducting segmented interviews. You’ll be able to inject tons of real-world data into your personas by interviewing existing customers, prospects, and referrals.

To keep it simple, you can use a persona template or a more integrated method like UXPin which allows you to attach personas to your website’s wireframes and prototypes.


In 2005, Ursula Dantin of the University of Auckland in New Zealand conducted a study to prove the effectiveness of creating and using personas in UI design.
She examined a sample of two small education-based software systems: Cecil, a custom-designed enterprise learning management system developed and used by her school; and Turnitin.com, a website that many consider the standard in online plagiarism detection due to its use by thousands of institutions in over 50 countries.

Her research showed, not surprisingly, that personas helped the design process, and in no small way, either.

“Identifying personas and performing their tasks helped introduce clarity and accountable reasoning into the UI evaluation process. Using personas in combination with Nielsen usability heuristics was not time consuming and required no additional software applications. This suggests that personas are an inexpensive yet e ective option for UI design. Even after implementation, personas can be a valuable tool to assess usability and pinpoint areas for improvement



Defining the requirements of the application via a workshop between the team and the client is the first and key stage. This covers what the application needs to achieve and what features should be encompassed. The outcome from this session is agile documentation such user stories, detailing the key application use cases, user journeys as well as key functions of the application, along with a user experience and creative concept. It is prudent that the documentation is reviewed by business, user experience and technical teams, ensuring feasibility.


There are a number of streams within the design phase – the user experience design aims to document the application flow and structure via wireframes (akin to architectural blueprints). The visual design applies brand-led creative design to each screen producing pixel-perfect designs, bringing the application to life. The technical design documents’ the application architecture, integration points and solves potentially challenging aspects of the application via spikes (proof of concepts).


Once the designs have been approved, the development of the application can commence. Typically, the development team work in short iterations, delivering regular builds of the application to the stakeholders, demonstrating progress. The process demands problem solving as challenges arise, sometimes requiring minor design tweaks as the application takes shape into a living entity. It is essential that development is a collaborative process by all those within the team. Towards the end of the development phase Quality Assurance is carried out involving thorough testing investigation to ensure that all business, user experience and technical requirements have been met.


Once the application is development-complete and has passed the QA process it can be submitted for User Acceptance Testing with the client. This is a final sign-off, ensuring all stakeholders are satisfied with the output. Once approved, the applications are packages and submitted to the App Stores. Apple, Blackberry and Windows all have a set approval process, which applications must pass in order to feature within their libraries. If the application fails the approval process it will need to be optimized, tweaked, redesigned or redeveloped and then resubmitted. If the application passes it will be available for consumers to download and use. Android do not have an up-front approval, but rather a retrospective process, so they will look to have their attention flagged to sub-standard applications.

Testing considerations

Ensuring an application performs correctly on a variety of devices is key to ensuring success within the application space. An application must be tested on a devices covering screen size, pixel density, processing power and operating system version. This challenge is less complex if developing on the Apple platform, due to the smaller number of available devices. However, the Android platform has high fragmentation of devices, requiring a significant QA effort to maximize compatibility with the platform. This function is often best outsourced to a partner with the necessary range of devices available, as the upfront costs of device procurement can be significant. Further considerations of mobile testing include catering for a variety of network conditions – this includes Wi-Fi, 3G, EDGE and no connectivity whatsoever. To complicate matters, Wi-Fi connectivity can vary in bandwidth significantly and the application must adjust accordingly.

Subsequent updates & road map

Once the application is in motion its purpose should be continuously challenged and optimized. We recommend the use of analytics packages, such as Flurry and Google Analytics, to analyse the usage of the applications. It is often prudent to perform an analysis of feature cost vs. usage – as often high-cost features are under-used and ancillary features can sometimes be the most popular. These metrics can help contribute to the application roadmap. A vision should be in place for the application, tied down by a roadmap with planned iterations indicative of progression. As tablet manufacturers are consistently innovating the platforms, a sustained effort in leveraging these new features should be considered where appropriate. The tablet device lends itself well to phased developments and continued improvements, allowing flexibility, establishing it as a progressive and innovative technology choice.

Understanding Your Users & Their Needs

Considerations for tablet design & UX