5 questions to ask during your design process

Holly Habstritt Gaal


This post focuses on process and accompanies Introducing the update experience for Australis. – Zhenshuo Fang and Holly Habstritt Gaal, Mozilla UX.

We’re really excited to release a new onboarding flow for users updating to the new Firefox (Australis). Throughout this project we’ve learned a lot about design process that helped us to make decisions and allow our assumptions to become something tangible and valuable for our users. We started with high level thinking about how to educate users and are now focused on updating current users to the new Firefox. Our process started with a few assumptions, but evolved to fit a project that didn’t exist when we started. This post explains a few questions that we asked along the way.

Onboarding project timeline

Onboarding project timeline

1. Are my assumptions right?

Assumptions need to be explored and tested before offering solutions. In the early stages of our work, “onboarding” was not yet a project on the roadmap and was not tied to the launch of Australis in Firefox 29. We felt strongly that improving the onboarding experience would help the adoption of the new browser. Sentiment reports also tell us that better onboarding is desired by our users. In order to demonstrate the value of onboarding, we first needed to learn more about the assumptions we had about browser usage and onboarding in general. Initially, there were only a few of us exploring our ideas, so early testing and learning allowed us to rule out assumptions early and work efficiently.

One assumption we had was that users in a First Run or Update experience are likely to ignore what appears to be a typical web page since they are focused on a task like checking email when opening their browser. This presents a challenge of not creating a barrier from completing the user’s task, but also creating an experience that is both valuable and memorable. We also had assumptions about language and tone, how feature education could lead to more usage hours, and many others.

Tools we have to help

  • Usertesting.com, surveys, and one-on-one observation: By gathering qualitative data (feedback directly from our users) we are able to quickly validate or rule out our early assumptions before diving into them too far.

  • Google Analytics: We ran very early web experiments to test copy, UI styles, and general engagement with our content, but will continue to use GA after release.

  • Telemetry and Firefox Health Report tell us about user behavior in the browser itself. See Blake Winton’s post about Measuring Australis to learn more.


2. What should I prototype?

We know that prototyping is useful, but knowing what to prototype and being efficient is important. Testing first with existing products, Keynote mockups, and static pages allowed us to decide what we should prototype further with engineers. The key to learning more about our assumptions and proposing possible solutions was working with engineers early in the process. For example, this allowed us to know the technical possibilities and limits when debating early UI and interaction ideas.

An early premise was that watching a video or looking at a screenshot is not as memorable or clear as showing the user what is happening directly in the browser. We knew that the best experience shouldn’t just tell the user about something new, but result in a behavioral change and a new way of thinking. Exploring this idea with a rough prototype is what lead to creating the foundation of the experience, technology that allows the web and chrome to interact with one another. This avoids having to rely on passive viewing of a web page to create a memorable experience. Check out this video from Michael Verdi to see what I mean.

* video demonstrates our progress and thinking as of November 2013

Working with engineers early with prototypes allowed us to do the following:

  • Confirm that the new interaction for showing, not just telling a user about the browser was technically possible.

  • Have access to try builds to test with users outside of the release channel. This was essential to knowing what UI and interaction and would be accepted and adopted by users.

  • Find bugs early and be able to plan for what challenges we may face in implementation. This was essential for moving forward in proposing solutions.


3. Am I confident enough to propose a solution?

As a direct result of everything we learned in preliminary exploration, prototyping, and testing we were able to propose solutions based on key findings that we felt confident would lead to valuable onboarding experience. For example:

  • an experience that doesn’t feel like a webpage, appears to be connected to the browser itself, and not isolated to the web

  • an experience that balances low interruption with clear visibility that a UI tour is present

  • a new interaction pattern where the web and chrome collaborate (as a result users are noticing and remembering the experience more than serving the same information in a typical web page)

Being able to share what we learned by referencing data and user test results made our design choices easier to understand by those not directly involved. It was also much easier to have a discussion and make sure everyone felt confident in design choices before moving forward.

For more about how we designed the experience see Introducing the update experience for Australis.

Onboarding Tour UI

Onboarding Tour UI


4. Is everyone on board?

Collaboration leads to a better solution and experience for our users, but also leads to smoother internal adoption of an idea. This project started as a few of us exploring assumptions, then became a weekly meeting that included those interested in improving onboarding and user education, and is now a cross-functional team working together towards the Australis launch in Firefox 29.

The collaboration spans across teams such as release engineering, web development, marketing, visual design, UX, user advocacy & support team, metrics, and others. This is an example of how UX isn’t an isolated step in the process. It affects the life cycle of a project and requires balancing input and collaboration from all teams and roles.

5. Are we improving?

 With all of the hard work we have put into this, we want to be sure to continue to improve the experience for our users. To do so, it is important to know both what our definition of success is and how to monitor it. As we release the experience to more users in Firefox 29, we’ll learn more about how it can have an impact on behavior, usage hours, and overall enjoyment of using Firefox. What we learn will also help to improve other onboarding touchpoints we have with our users such as the First Run experience. The benefit of creating the controls and majority of the UI in the web means that we are not tied to our release cycle and can iterate quickly.

An interesting challenge we have is that interaction occurs both in the browser chrome and web page. We would like you to use the browser and not just interact with a web page, so high interaction in a web page doesn’t necessarily equal success. Success is when the user finds value in the message we are communicating and that results in using something new in the browser, using the browser more, or adopting new behavior. If we notice changes in user behavior and long-term use of the browser, knowing if they are direct result of an onboarding experience will guide our improvements and next steps.

What we’ve learned isn’t about an exact process that will work for every project, but about how answering these questions and collaborating early will lead to a better experience for our users.

We love to discuss all things onboarding. If you have any questions, please reach out to Holly Habstritt Gaal and Zhenshuo Fang.  

Designing Tools

Darrin Henein


I was hired at Mozilla 7 months ago. While my primary role is as a Senior Design Engineer on the Firefox Desktop team, I’ve since spent a considerable amount of time working with the amazing Developer Tools team. The hope was that with my experience in UX design and my passion for web development and programming, I would be able to provide some informed design direction for our tools.

Continue reading …

Are you a mobile Web app developer? Let us know how we can improve your experience!



The Mozilla User Experience Research team is looking for developers in the Bay Area who have experience writing mobile Web apps to participate in a paid research study that will have a significant impact on making our developer-focused efforts even better.

To qualify for the study, please take this 10-minute survey. If you’re eligible, a member of our team will contact you to tell you a little more about the research and schedule time with you. Developers who qualify for and fully participate will receive an honorarium of $250.

We’re looking for developers who are:

  • willing to participate in a 2-hour in-person interview at their workplace or home
  • available for the interview the week of March 10 to 14  (the weekend before / after may also be possible)

The interview will be recorded, but all materials will be used for internal research purposes only.

You DON’T have to use Mozilla products or be part of our community to participate (in fact, we’d like to hear your voice even more!).

Your feedback has the potential to improve the experience of other Web app developers and influence the direction of our products and services, so we would love to get a chance to talk with you! Please feel free to share this opportunity widely with your own network as well.

Interaction14 Recap

Zhenshuo Fang


Last week, three of us from the Mozilla design team attended Interaction14 (IxD14), an annual conference hosted by the Interaction Design Association (IxDA) where industry professionals come together to share new ideas related to the practice of interaction design. This year the conference was hosted in Amsterdam, Netherlands, and the theme is “Languages of Interaction Design“.

There were 90 speakers, and more than 800 attendees joined 4 days of workshops, presentations and conversations about design. The topics range from traditional design process like designing design projects to fun topics like important design lessons learned from cat. Here I want to share with you some interesting talks I attended and my sketchnotes, just to give you an idea of what IxD14 is about.

Talks about sharing experiences

Many of the presentations at IxD14 were about sharing experiences. I particularly enjoyed the talk Bad Design Advice by Paolo Malabuyo who turned three bad advices designers often receive into good ones. I also enjoyed Jan van Geel‘s talk about how to sell your Ideas by better communicate with others.

Skechtnote for "Bad Design Advice"

Skechtnote of “Bad Design Advice”

Sketchnote for "Pitching Ideas"

Sketchnote of “Pitching Ideas”

Talks about design theory

In the very first keynote Languaging Reality, Dialog and Interaction, Klaus Krippendorf gave an overview of several theories of language and explained how language manifests reality in our daily lives. In the talk The De-Intellectuallizaiton of Design, Daniel Rosenberg differentiated enterprise UX vs. consumer UX, and identified the gap between design education and industry. In his talk Design for Dasein, Thomas Wendt examined philosophical origins of design principles and new models of practical implementation.

Sketchnote for "Languaging Reality"

Sketchnote of “Languaging Reality”

Sketchnote for "De-Intellectualization of Design "

Sketchnote of “De-Intellectualization of Design “

Talks about new design languages

There were many presentations about new design languages, new trends and challenges in the field of interaction design. Stephen Gay and Susan Hura gave a very informative talk on the opportunities and principles of designing Voice User Interface (VUI). Antonio De Pasquale talked about Designing Motion based on the famous 12 Principles of Animation by Disney. And Zak Brazen and Wyatt Starosta talked about what can we learn from the UI of Nature.

Sketchnote for "Adopting VUI in a GUI world"

Sketchnote of “Adopting VUI in a GUI world”

Sketchnote for "Design in Motion"

Sketchnote of “Design in Motion”

Talks about how we can work better together

On the topic of process and how designers can work better together, Chirs Noessel shared how Cooper uses Pair Design in their day to day work. Irene Au shared how Yoga and meditation help designers gain focus, empathy and creativity. There were also discussions of how Introvert and extrovert designers work together and how industrial designers and interaction designers can work better with each other.

Sketchnote of "Pair Design"

Sketchnote of “Pair Design”

Sketchnote for "Body Languages of Interaction Design"

Sketchnote of “Body Languages of Interaction Design”

There are definitely more interesting talks than I can include here, you can find the full list and a collection of videos of all the IxD14 presentations. Next year, Interaction15 will be hosted in San Francisco, I hope many more of us can make it and enjoy another 4 day of awesomeness.

Measuring Australis.

Blake Winton


The goal of the Australis project has been to make Firefox simpler and more engaging, and thereby help users be more effective. Naturally, with every user-interface change we make, we want to evaluate how the design is performing and course-correct where necessary and helpful.

Now that the new interface is being released to a wider audience in Aurora, we are taking the opportunity to further check our work, make final refinements, and gather ideas for the next version.

One of the ways we can understand the impact of new designs is through surveys and user interviews, which we use throughout the design process. With a larger user population like the one using Aurora, though, collecting feedback at scale requires us to go beyond those methods. For that we need to get more into the quantitative side: we need to instrument the browser, and link the data we collect back to the things we care about, such as user-performance and delight.

(As another proxy for the kind of data we get from the surveys, we’re also talking with our User Advocacy and Support team, to see what reactions they’re hearing, how they differ from previous releases, and more importantly how they differ from previous releases with a similar volume of UI changes.)

Our quantitative understanding of how Firefox is being used comes mostly from users who have opted in to sending us their Telemetry data. From this data, we can extract reasonable answers to questions such as “Are people customizing Firefox more?” or “How many tabs is typical?” This is interesting in its own right, but we can also use it to gauge both effectiveness and a sense of agency over one’s browser. Additionally, it will tell us how well we did in determining which menu items we should provide by default and which should be available through customization).

And so we landed a new UITelemetry.jsm module to make adding those probes easier for both desktop Firefox and Firefox for Android. Once it was easy to add new probes, we needed to get a baseline of the current activity so that we have something to compare against to tell how things are changing. To that end, we added around 40 Telemetry probes to the pre-Australis version of Firefox (Holly) To gather data that we can compare with this baseline, we also added similar probes into the Australis version of Firefox. (They will only be similar probes because some of the UI elements have been significantly changed in Australis.)

This will give us some data we can use; however, we know that the people who have opted in to sending Mozilla their Telemetry data don’t behave in exactly the same way as Firefox’s general user base, so to be able to normalize the telemetry data to better match our release population, we will also be checking the data from Telemetry against similar data we receive in the Firefox Health Report. The Firefox Health Report will also give us some more detailed and representative data for other questions we have.

Now that the probes have been on the pre-Australis version of Firefox for a cycle, we have a good baseline for the information we’re tracking. And now that Australis has ridden the train to Aurora, we should have a set of data in a week or two that we’ll be able to compare to the pre-Australis Aurora numbers and get a better idea of whether Australis is having the effect we want.