Save Time & Money through Prototyping
A case study on how Mozilla leveraged iterative prototyping to implement a product redesign
To begin with, for all those Product Designers or Managers who believe that iterative design or multiple passes of user testing are an impediment to shipping the results in time — this article is for them.
This case study highlights how Mozilla adopted rapid designing using paper prototypes even before touching the HTML editor. It is claimed that some of the design prototypes passed through 7 iterations within the 2 weeks of this exercise.
What is Mozilla?
Mozilla is a large, open-source, worldwide, software organization staffed by both employees and volunteers. It makes one of the most popular web browsers (Firefox), along with other useful products and services.
Mozilla had come across a unique set of problems being faced by their users — both internally and externally associated to seeing help about their products; the key impediments were as follows:
- At about 500 odd pages of help documentation it had become an overload of helpful information for a user to seek help from.
- The sheer quantum of information itself posed a great challenge to the Mozilla team to maintain and update from time to time.
- Because most users would not have the patience to go through the content themselves, they would shoot questions at the forums, which then again ended up becoming a clutter of questions.
- The Mozilla team could not — answer the questions asked, or spare time to make FAQs out of the repetitive questions asked.
To tackle this Mozilla decided to redesign their portal. One of the key goals of the entire redesign exercise was to improve the discoverability of information to the end users and a KPI for the same was to reduce the frequency of the end user visits and consequent questions in the help and support forums.
They set up a UX team to study and focus on 2 key areas:
- Focus on the users — see how the internal team/staff as well as end users used the platform
- Find out the most important pieces of information
Their team started putting down paper like sketches and low fidelity wireframes of the to-be website in prototypes and tested it with their target users.
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.
In the early design stage, the idea was not to focus on graphical or layout issues or UI, but rather to find out which choices were needed to present on each page. 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.
Based on their learnings from the previous exercise in the first odd week, the team then moved to the HTML coding panel to create a working prototype.
The final design started with the choice of products, then showed the task-based navigation after the first click, following good progressive-disclosure principles.
The result of the exercise was that the newly provisioned easy access to information caused the volume of new help questions in the forum to drop immediately by about 70% (from about 7000 to about 2000 questions per month).
As a result of the website redesign and content improvement effort, the Mozilla Support help documentation was expanded to sufficiently address the most general questions we discovered. Because the information was more easily findable, the users now restricted asking questions pertaining to very specific topics and were able to find most of their answers right away.
What can we learn from this?
- Always leverage data about the users and their traits and/or patterns if available
- Make and test changes while early in prototyping phase to validate their viability
- Through user understanding and constant feedback, any product can be improved
- Keep testing ideas to validate the alignment of thought and take into consideration what the users need and seek
To conclude, what we can take away with us as a learning from this case study is that, one must focus on the problem areas, define a problem statement, build a prototype around this problem to address the inherent need. Thereafter, test, learn, tweak/implement, and repeat.
Leverage failure and feedback positively to build a better product and harness the points to add value to the product/service.