We often advocate using a parallel and iterative design process to explore design diversity, because it produces much better user experiences. A cheap way of implementing this type of design process is rapid paper prototyping. Paper prototyping is not only efficient for progressing designs quickly and allowing designers to find their best-of-breed with minimal investment, but it is also fast, fun, and easy to learn.

In this article we show how Mozilla used paper prototyping as well as user research and data mining to quickly advance the UX-focused redesign of a major part of its website. (A previous article documented how this redesign had high return on investment.)

If anybody says that design iterations will break your ship schedule or that user testing is too much bother, point them to this article, because some of the prototypes progressed through 7 versions during 2 weeks. Testing with users before even breaking out the HTML editor was cheap and it showed which alternative designs worked best.

The Iterations

One of the central goals of Mozilla’s redesign effort was to improve information discoverability and findability in order to enable users to find the information they need quickly. A key measure of that success was to reduce the number of questions in its support forums.

Product-help landing pages were the top entry points for the support website, because they were accessed via the Help menu in the products. As the most-viewed page on the support website, the Firefox Help landing page pointed to a lot of useful information, but, with this design, too many people ended up in the forum asking questions. More than 30 articles were linked from the homepage, but when someone wanted information on a problem not listed, searching was the only way to find it. Instead, users needed to be able to choose a path related to their issues and find the few articles applicable to them.

Firefox Help: Before redesign
The Firefox Help landing page before the redesign

Although there is no single answer to the question of flat vs. deep hierarchies, our many years of usability research indicate that with too many choices, people easily get overwhelmed. When people click the right thing first, they are almost 3 times as likely to succeed at their task.

With that knowledge in mind, in the first iteration of the design we focused on limiting the number of choices. The new design allowed people to start with either their task or their product or service, and it offered 5 most-wanted links in a box in the bottom left corner of the page. These distinct task categories (getting started, installing, protecting, customizing, and repairing) allowed people to find what they needed or to determine that the information didn’t exist, quickly.

Mozilla Support Home, first version
The first version of the paper prototype for the Mozilla Support homepage: Users could start with a task (1), a product or service (2), or choose a hot topic (3).

The designer made the prototypes using OmniGraffle, and we printed them onto tabloid paper and cut them to size. Because there was no code to change, this prototyping method allowed us to make design changes quickly during testing. Firefox users helped progress the designs rapidly toward better usability, by allowing us to watch them try to find answers to top questions. Where they got stuck or confused, we redesigned.

In this early design stage, the intent was not to focus on graphical or layout issues, but rather to find out which choices we needed to present on each page and to test comprehension of labels. Any of these elements might have been ultimately expressed using other interaction widgets, such as menus or accordions.

In a later iteration of the design, shown below, task groupings for the help material were eventually moved under the products on the next layer down in the IA, in part because all tasks were not available for all products and services, and that order of layering helped manage that necessary difference gracefully. To avoid overwhelming and distracting users, we also used progressive disclosure: the different Mozilla products were now hidden under a collapsed accordion.

Iteration with collapsed accordion
A later-iteration design for the Support homepage: People could choose a task (2) or expand the software row (1) to choose a product or service first. When someone clicked the question in the middle, we showed them another piece of paper like this, but with the middle section expanded (compare with the previous screenshot).

In this iteration, users loved the big icons (2), but they were confused by wording in some of the choices (3): “Participate: How you can help others” (too general) and “Feedback: Give us your suggestions via Firefox input” (too specific). We tested several other phrases until we found the wording that worked best.

Note about writing for the web: Throughout the research, we wanted discover how much (actually, how little) information needed to be shown in order for people to find the most-important things easily, because one of the fundamental principles of reading onscreen is that less is more. Reading onscreen is more difficult than reading on paper, and low-literacy is a challenge as well. Because people tend to scan at first rather than reading right away, they perceive fewer words as being more informative when they read online, and concise pages are more usable. Also, because Mozilla website visitors speak all the languages of the world, we wanted to make word translation and concept localization as straightforward as we could.

After the paper-prototype testing sessions ended, the designer made the next version in HTML. This design used strong grouping and background colors to differentiate among activity and information types. It was still a bit too complex to scale gracefully, however, so it was simplified before implementation as products, services, and tasks were added.

Hi-fidelity elements attracted too much attention in the prototypes
Early HTML design for the Mozilla Support homepage: Although this is clearly a much higher-fidelity representation, it’s important to note that the earlier low-fidelity versions (as shown above) were sufficient for usability testing of many design questions.

The final design started with the choice of products, then showed the task-based navigation after the first click, following good progressive-disclosure principles. In addition, a number of participation options were consolidated under one button, Volunteer for Mozilla Support, that allowed people to express their general interest in open-source contribution via this one entry point, then figure out exactly how to do that further downstream, where more choices and explanation could be displayed.

Mozilla Support homepage after the redesign
The Mozilla Support homepage as launched after the redesign project

Mozilla’s staff measure website interaction constantly, so the support website’s design and content continues to evolve over time, based on that data analysis.

Lessons Learned

  • Frequent changes are better when testing prototypes. Frequent iterations give each design change more time in front of more users, which allows more evolution to occur. In-house teams should test a few new design ideas each week.
  • Test alternative designs early to allow the best design components to be used on fewer pages as testing progresses.
  • Be consistent with fidelity, size, and colorspace. Showing a few high-fidelity screenshot cutouts of interface elements didn’t work well, because the colors attracted too much attention on predominantly grayscale pages.

We’d like to thank Mozilla for allowing us to share this experience with the UX community.

The UX Team

  • Susan Farrell, Senior User Experience Specialist, Nielsen Norman Group. Susan conducted the research, did data discovery, analyzed data, and made design-change recommendations.
  • Crystal Beasley, Product Designer, Mozilla. Crystal led the project, coordinated with Mozilla stakeholders, and played the computer during paper-prototype research sessions.
  • Bram Pitoyo, Web User Experience Designer, Mozilla. Bram designed the task flows and prototypes and supervised the interaction-design changes to the website. He also tested the old IA so we could compare results with the tests of the proposed new IA.

See also: full-day course with hands-on training in using paper prototyping in the UX design process.