The Process Behind Improving the Firefox Application Menu
We sat down with Betsy Mikel, a senior content designer at Mozilla, to talk about her work on the redesign of the Firefox browser that launched in June 2021. We talk about the role content played in the redesign and walked through the process her and her team went through to redesign the application menu.
What’s your design process for designing a new product?
I start by trying to understand the lay of the land, both internally and externally.
Internally, I go on a detective mission to find what research and documentation already exists. I might conduct informal Subject Matter Expert interviews with colleagues who have specialized knowledge. I begin putting everything — resources, notes, documentation — in one consolidated place.
I also start figuring out who my collaborators will be, including other designers, engineers, and product managers. Knowing up front who needs to be involved and when will reduce confusion later.
I’ll audit competitive products. If possible, I’ll use those products so I can feel what the experience is like. What do they do well? What do they do not so well?
For example, I was part of the team that launched Firefox Monitor, a data breach monitoring service. I registered for several other data breach services and spent time analyzing their websites. Mozilla also has a VPN, and I was involved in its early stages. Everyone on the design team downloaded a different VPN, took notes about their experience, and shared our observations with the group.
After all that information gathering, my next step will depend on the size and scope of the project.
Is the process different if you’re creating a new product versus enhancing an existing one?
For improvements to an existing product, I’ll still gather past research and audit competitors. I work on the Firefox browser. I rotate using other browsers every few months. So I’m continually doing that auditing.
Additionally, to enhance an existing product, you can bring in institutional knowledge and data.
Leverage institutional knowledge
The project I’m walking through is an enhancement to the main application menu in Firefox. We were able to consult people at the organization who had deep knowledge about previous changes that had been made. For example, one portion of the menu focuses on your Firefox account. It’s much more complicated than it appears. It includes functions like logging in, logging out, syncing data, and sending tabs to different devices. We had numerous conversations with our Firefox accounts team to help us better understand the edge cases and various menu states.
Gather existing product data
Both quantitative and qualitative data can be useful for design decisions. For the application menu, our goal was to streamline and consolidate. We had to make decisions about what to deprecate, what to move, and which labels provided clarity or needed improvement.
We reviewed usage data to guide information architecture decisions. For example, Settings is one of the most frequently accessed items. It previously sat in the middle, sandwiched between other items. So we moved it to a more prominent place towards the bottom. Now when you scan the menu, Settings is easier to find.
Leverage prior user research
We also reference prior user research. We had long used a Library metaphor in the menu, which was the access point for your Bookmarks, History, and Downloads. Library had consistently tripped people up in research studies. They didn’t understand what it represented. So for this redesign, we scrapped it entirely and brought Bookmarks, History, and Downloads higher up. We wouldn’t have been able to make that decision without user research.
Can you walk us through the design process of a project at Firefox?
We just launched a design refresh of the Firefox browser. This project encompassed many areas, including our tabs design, address bar, toolbar, and components like panels, modals, and messaging surfaces. Today, I’m going to walk through one portion of that effort, the redesign of the information architecture of the Firefox application menu.
Overview of project
This is the main Firefox menu. It’s where you go to find your Bookmarks, access your Settings, or log in to your Firefox account.
I’m going to talk about how content design approached this project. This was a team effort, myself and Meridel Walkington, the other half of our content design team. Usually we have separate focus areas so we can spread our resourcing more widely, but this was such an important part of our product that we put 100 percent of our team on it.
Analyzing the current state
A few high-level changes we knew we wanted to make were backed by user research and usage data.
- Icons added cognitive load to the menu, leading to trapped white space.
- Items were grouped in un-intuitive ways.
- Some labels were confusing and left people lost.
- Many sub-menus were buried underneath this top-level menu.
Grouping like items together
Our content design process for any project usually involves creating a spreadsheet or table to help us organize information. Before proposing any major changes, we considered how items fit together semantically. This was as simple as grouping like items together and defining their information type.
Wireframing to align and finalize the IA
To start, we drew low-fidelity wireframes in Google Slides. This was an efficient way to begin placing content and to align with stakeholders about decisions. We lovingly call these Wire Slides. They don’t need to be pretty. They just need to communicate the right information, hierarchy, and content inside a semi-accurate shape of the product.
The barrier to entry for Wire Slides is low. It’s easy to open a document and draw boxes. You can then quickly loop in the appropriate parties to review. The sooner you can bring cross-functional peers in, the better. We might share Wire Slides with product management to get their input or engineering to understand technical feasibility. PMs from many areas of the organization would be impacted by changes made to this menu, so we wanted them to be aware early.
Ongoing feedback helps us move quickly. We can make changes in the document itself and go through multiple iterations before finalizing the information architecture. We maybe went through 10 or 15 iterations over 2 weeks.
Our team is getting up to speed in Figma, so we may move wireframing there. There is something approachable about a Google Slides document though because it’s not a fancy design tool.
Applying visual design
Once we finalized the information architecture in Google Slides, we moved it over to Figma for visual design application. Key changes included:
- Removed icons to improve scannability.
- Grouped like items together for findability.
- Elevated key access points that were previously buried in sub-menus.
- Reduced the number of sub-menus to streamline and consolidate.
Testing the IA with user research
Once we had a close-to-final design, Meridel led a user research study to gather input from users. Could they find what they were looking for? How did they respond? We always try to incorporate user testing whenever possible during our process. It helps us understand user pain points that we can then improve before the product gets built.
Defining our principles
On any digital product, the work is never done. Though we just launched the redesign in June 2021, Firefox will likely need to make changes to the menu in the future at some point. We can then come back to our principles.
This also helps future-proof our work and help with product consistency. Say at a future date a menu change is required, but one of us isn’t available because we’re staffed on another project. We can share these principles with whoever works on it so they can make the same considerations.
Unveiling the new design
The final menu is streamlined, simple, and clean. It’s exactly what we set out to do. To a non-designer's eye, it might not look designed at all. We’re perfectly OK with that. Good design can feel invisible. If it helps people who use Firefox move more efficiently, then we will have succeeded.
OK, so let’s do a quick recap
First you… gather data about the product — qualitative and quantitative. Do your research to understand the historical context around previous product decisions that were made.
then… select the appropriate tools that will move the work forward. For us, that was the semantic grouping of menu items in a table and multiple wireframe iterations of the information architecture. Use your wireframes to align with stakeholders like PM and engineering. Bring people in early so they can weigh in and provide feedback.
and… whenever possible, validate your work with user research. Observe how people get tripped up using a simple prototype and see what improvements you can make before handing off the design to be built.
finally… define the principles that informed your work so that you — or maybe even someone else — will be better prepared to carry it through for future changes.