Design at the Mozilla Foundation follows the Design Thinking process for all our key projects. We create living documents and tools that respond to the needs of our users at the present time. We follow agile design thinking processes and work in two-weeks sprints. Key elements of our process are outlined below and are adapted from the Nielsen Norman Group’s Design Thinking process. While this is not a fixed, linear process, all projects should touch on the elements below. Iteration allows us to cycle through them.
Each stage of our process supports the following goals:
- Understand what our collaborators and their audience need
- Address the whole experience, from start to finish
- Make it simple and intuitive
- Design using iterative and open practices
- Add a dash of levity or even whimsy to provoke interest
Credit: The first four principles are lifted from the U.S. Digital Services Playbook.
Discovery: Explore the problem: Learn, evaluate, and prioritize (1-2 sprints)
- Project Kick-off & Stakeholder Interview
- Project Brief
- Landscape Analysis & Benchmarking
- Metrics & Analysis
- Content & Content Strategy
Exploration: Define solutions: Explore, design, test, and refine (2-4 sprints)
- Ideating, Concepting & Brainstorming
- Wireframes & Prototypes
- Design Comps/Mockups & Prototypes
- User Research & Testing
- Gathering Feedback
- Design Review
Implementation: Delivery: Build, measure, and learn (2-4 sprints)
- Assets Management
- Design Quality Assurance & Content Entry
- Share Outs & Retrospective
- Iterate & Impact Metrics
Goals: Define the problem, audience, key stakeholders, goals, metrics, timeline, scope, and deliverables.
- Review any existing and relevant docs or past work.
- Meet with key stakeholders to go over the stakeholder interview.
- For features relevant to the entire org, a TypeForm survey can be shared and followed by more in depth interviews with key stakeholders.
- When possible, interview real users.
- Write user stories.
Deliverable: Stakeholder interview
Goals: To ensure we are all aligned and to reference through the project to make sure we are still solving the desired problem.
Process: Once we have a sense of the problem, design writes the brief which must be signed off on by all stakeholders, design, and engineering.
Deliverable: Project design brief
Goals: To make our work efficient and effective and to not reinvent the wheel. We carve our own path, but do it informed by the state of the art.
Process: Research, gather and curate examples of benchmarks and precedents on how others have solved similar problems. Highlighting why the benchmark worked and assessing if it could help solve our problem. Share for feedback and input from design, engineers, and stakeholders.. Share for feedback and input from design, engineers, and stakeholders.
Deliverable: A slide deck, Miro board, Pintestest board, etc with screen caps and annotations
Goals: Use quantitative data to reveal whether or not something works and/or understand our visitors and their behavior, and to identify parts of their experience that are broken or successful. Use qualitative data to provide additional insights. As well as define which metrics we will use to determine the success of the project.
Process: When possible, review and summarize Google Analytics data. Gather quotes and insights from our audience and collaborators. Define which metrics and success markers we will track to define success of the project.
Deliverable: Report summary of findings and plan for future measurements.
Goals: To get a sense of priorities, calls to action, the amount and type of content.
Process: Gather examples of content from stakeholders, content and marketing team.
Deliverable: Summary list of links to content.
Goals: Be generative and expansive in exploring a variety of possible approaches/concepts to solve the defined problem.
Process: Create multiple low-fidelity sketches or wireframes that solve the problem in different ways. Check-in with stakeholders, users, and devs to make sure ideas are shared, expectations are met, and the best solutions to the problem are being explored. Begin to narrow down the solutions.
Deliverables: Multiple solutions that solve the problem in different ways. A collaborative, walk-through meeting with stakeholders and devs. An agreed upon direction.
Goals: Give a better sense of how the solution feels within a certain flow.
Process: Create multiple wireframes and prototypes that show different solutions. Advance the selected direction to hi-fidelity mock-ups. Share, gather feedback, and iterate based on feedback from design, engineering, and stakeholders. Content and design should work together to iterate and shape the content.
Deliverables: 1-3 prototypes with real content. A check-in meeting with stakeholders and devs. An agreed upon direction.
Goals: Give a better sense of what the finished product will look like.
Process: Refine the UI and add real content
Deliverable: High-fidelity mock-up/prototype with real content and images. An agreed upon direction.
Goals: Use qualitative tests to test assumptions and hypotheses with real users and reveal why something does or doesn't work.
Process: Define the goals of the test, write a script, run the test, and compile a summary report. Testing can be done before designing to understand the problem and pain points, in the middle of designing to validate multiple solutions, or after completion to gauge impact. We run these tests with a small pool of individuals, typically using usertesting.com. Other Tests: A/B test, click tests, surveys and many other methods can also help test a theory. Choose the right test for the job.
Deliverable: Report summary of the findings. When possible, include a few user interview video highlights.
Goals: To gain insight on our design, ensure we are on track and solving the defined problem, are aligned with stakeholders and designs are on brand and technically feasible.
Process: We gather feedback early and often. We enable the best feedback by clearly framing our prototypes: What problem are we trying to solve? What research have we considered? What's the scope of the project? What's the status of your iteration? We answer these questions to help avoid uninformed and inefficient feedback. Show your process to demonstrate things you have considered, but found to be ineffective.
Deliverable: Summary of feedback gathered, prioritize the feedback, and list action items
Goals: On our team, we look to each other to provide perspective on our work, to make sure we stay aligned with the principles. This is formal feedback. Is our work accessible? Does it support our brand?
Process: We review each other's work during weekly critiques, in Slack, in project meetings, in Redpen, and in Github issues. We request feedback early and often. In Github, @mention someone to formally request a review. Sometimes, we receive a deluge of feedback from people across the organization and beyond. We must accept and filter the feedback to maintain quality and coherence.
Deliverable: Refined designs. Final, high-fidelity mockup designs. Agreement on priorities.
Goal: Files should be findable and usable by another designer or developer.
Process: Some projects yield assets that will be useful in future projects. We collect these on Google Drive. These files should be prepared for reuse by others.
Deliverables: Clean and up-to-date files for design & devs
Goals: Ensure engineers are involved throughout the project to ensure the best possible product.
Process: Engineers are looped in via kick-off meetings, check-ins with stakeholders, progress shared in Slack and Githubs tickets so they have ample opportunities to give their input and feedback. As design wraps up and dev begins, a “design to dev” handoff meeting must occur. During this meeting, designers will walk through the details of the designs, devs will list the tasks, devs will open GitHub tickets for the tasks. Tasks will be assigned and estimated during their sprint planning rituals.
Deliverables: Design & Dev meeting notes. Dev implementation tickets in GitHub. Dev work begins.
Goals: Ensure work reflects the designs and is on brand.
Process: A designer must approve all Pull Requests in Github from engineers when the code affects the front-end. Real content is added on staging and production. A designer and the stakeholders will review updates on our staging site and then on the production site. The designer or engineer will open and triage Github tickets if any updates are needed.
Deliverables: Pre-launch checklist, content entered, QA in PRs, on staging, and on production.
Goals: Always be iterating and improving. Retros allow us to reflect on how the project went and what we should change or keep doing for the next project. Documentation and share outs help gain visibility for our work and share our learnings.
Process: We hold demos and retros with design, engineering, and key stakeholders at the end of every two-week sprint; however, larger projects warrant a project-specific retro. A share out from all parties involved, including but not limited to: product lead, design, engineering, content, marketing, social, email and email. Followed by the actual retro with a mix of silent reflection in a Google doc, Miro or MetroRetro followed by a discussion.
Deliverables: A slide deck and/or blog post. A retro doc or board with action items, if needed.
Examples of share outs: PNI 2021, Original YouTube
Examples of retros: YouTube retro, PNI retro
Goals: To make informed decisions and continuously improve.
Process: Continuously check-in on and track key metrics and actions accordingly by adding work to our backlog and roadmap. Our design process is iterative. We iterate as we move from idea to production. We continue to iterate afterward, as the things we make prove to work well (or not) with users.