2015 saw the design team at Mozilla Foundation grow and change in many ways. There are many wins to celebrate from the past year, but this post isn’t just about wins. It’s also about taking a good, honest look at where we have room to improve.


I love the design team and think the world of all my colleagues, and as I look ahead to my impending second child and second maternity leave I would like to leave my fellow designers in a good place to carry on the work we’ve begun this year and to maintain a healthy design ecosystem within Mozilla. That means recognizing how far we’ve come and admitting that there are still challenges ahead worth tackling.

Like any healthy crit sandwich, let’s start with the good.

What did we accomplish?

At the end of 2015 the design team put together a recap of nearly all the design work we had tackled over the year. The result was an inspiring visual synthesis – when else do you get to survey the work of an 80+ person organization in this way? We listed out each project by name, dropped in screenshots, and added high-level labels for each project. It was cool to see the variety of work we touched across the design team, with all its breadth and depth, but also how these design artifacts had become indicative that the entire Foundation recognizes design as a useful tool and way of thinking. This sounds simple, but in a traditionally engineering-led organization, this shift is huge!

Beyond the scope of our day-to-day shipping, here are many other points of celebration:

  • Approximately 50 weekly design critiques since Jan/2015
  • Created a ‘Desktop Dailies’ tumblr
  • Created a Mozilla dribbble account
  • Established Dbuds program
  • Designed and built build.webmaker.org/design
  • Reached agreement on shared tools and process
  • Extensively documented our process
  • Moved shared files to Drive
  • Created several reusable templates
  • Created an all-mozilla designers mailing list for cross Mofo/Moco collab
  • Created and maintained Design Github repo
  • Collaborated with the Foundation research team on two research trips to Kenya and Chicago, designing several research reports documents
  • Sent two surveys to help measure how design was doing

Among these successes, I noticed some overarching themes.

5 Ways We Got Better

1. We got organized

Shared google Drive
As a design team, we got our shit together. We opened a Design repo, many of us new to Github. We recognized that good design has a good design practice, and we started practicing. We agreed upon tools and methods. We started having weekly critiques (ending the year with 50 crits under our belts). We built templates for tasks we repeatedly performed, and we pulled these resources together in several shared places: we opened a Github design repo, agreed to use Google Drive for shared assets and threw up all our working files so they were now accessible at any time, and we documented many of our tools, resources and process on build.webmaker.org/design (now build.mozillafoundation.org/design). While getting organized is a work in progress, the act of agreeing on a system was a big hurdle we managed to overcome. And remember: at the beginning of this year, we had none of this.

2. We became a tighter team

First Dribbble shots

While we lost one experienced designer last year (who still carries the open source torch), we gained three amazing new talents, rounding out our in-house skills and bringing us to a total team of seven Mozilla Foundation designers. Through thoughtful hiring and the creative use of internship programs via Youth Internship Program in Vancouver and Outreachy, we strengthened an area we knew we were weak in (branding) and added other skills we aspired to have (video and animation). Together we designed for a number of Foundation initiatives: Mozfest, end of year fundraising campaign, teach.mozilla.org, Thimble, Webmaker, X-Ray Goggles, Research, and more, any one of which could have used its own team of seven! Rather than focusing on our lack of resources, we learned how to become more efficient and communicate better. We now have a team that regularly collaborates with each other across projects and seems to genuinely enjoy each other.

3. We embraced better design leadership

I technically became Design Director in September 2014, but it wasn’t until 2015 that I really gained momentum. It was a new position both for me and for the organization, and a somewhat rocky early year proved that I needed to figure out my own style as a leader, to understand my team of designers’ strengths and limitations, and to understand the interests of my broader set of colleagues and how we could work together. Perhaps what was most difficult for me was identifying where I could have the greatest impact on Mozilla’s mission in my role, which turned out to be doing a lot more project management and art direction. I’m not sure why this surprised me, but I remembered well how much I liked getting my hands dirty and I was able to shift my day-to-day so that I now work more closely with our staff designers and contractors.

Beyond this typical sense of design leadership, I’ve also noticed individual designers stepping up within their project bounds to do more user research, testing and validation, which means designers are shaping not just how we build something, but why. One of our early design surveys identified this theme of ‘designers as partners’ rather than ‘workhorses’ as a potential area for growth, so I’m thrilled to have seen us move the needle on this. We have more work to do, but I’m glad that our colleagues tend to approach us more as collaborators and that we have opened ourselves and our process up to be available for this kind of collaboration.

4. We experimented

We tried a lot of different things in terms of process, working with community and tackling known challenges like being a completely remote design team. Many did not succeed, but a handful did, and I have seen our confidence as individual designers grow deeper and our trust in each other become more expansive, resulting in a design process that is overall more collaborative, more open, and more inclusive. Part of that means building a design culture that allows individual and collective experiments to fail. I’m so proud of this, and though we have a ways to go yet, it’s important to point to some of my favorite experiments:

      • Dbuds (design buddies) program – For pairing new designers with veterans, which made for better onboarding and a more open design process across Mofo. My favorite instance was our resident researcher who was not a part of the design team actually began learning about and practicing visual design through her dbuds partnership.
      • Desktop Dailies tumblr – This was a tumblr the design team began to share daily screenshots of our desktop to achieve that “walking by someone’s desk” ambiant awareness of what we were working on. Although it didn’t persist, this temporarily solved a feeling of being disconnected from our fellow designers, and I’d recommend it to anyone as a tool for building culture and trust.
      • Vancouver design hub – Designing remotely is hard, and we intentionally looked for designers to hire who were based in Vancouver because of our growing team there. We now have four designers working together in person on a daily basis, a success we hope to replicate in Toronto by establishing another intentional design space.

5. We listened

This slideshow requires JavaScript.

Good design serves a purpose and isn’t done for the sake of itself. We tried hard to embrace that this year in integrating with other teams, opening up our process to the rest of the organization, and listening to what others needed from us. We also reinforced the value of listening to and prioritizing our users whenever possible. As a result of our surveys sent around internally earlier this year, we learned that our colleagues didn’t necessarily know how to engage with the design team or what skills we had in-house. So we embraced processes that helped us work side-by-side with our colleagues on project teams. We built design processes that aimed to be more transparent, accessible and reliable. And as is critical for any great design team, we listened to feedback about the actual designs we were shipping and tried to get as close as possible to solving for real problems.

7 Ways to Improve in 2016

We did a lot right this past year, but one thing I know having been a designer for a long time is that as much as culture matters to designers who are part of a team, it is ultimately the work that must speak for itself. So I’ve taken a look at the work we shipped (and didn’t ship) over the year and noticed where there’s room for improvement.

1. Own the brief

design brief process

This year we created a design brief from scratch, but it – and our process around it – still needs work. It’s good we have one and that we don’t have to start from scratch each project, but our template is not intuitively understood by non-designers, not consistently used across projects, and not owned well enough by individual designers to be put to good use in the final work.

A good brief will ultimately suss out: Why are we doing this? I think the design team has often been hesitant to ask this question. Is it a fear of ruffling feathers? Of saying something displeasing? Of looking dumb? Of getting pulled off the work and put on something less interesting? Whatever the case, I believe we need to be bolder in helping to set the agenda for upcoming work earlier in the process.

One recent success I’ve seen in this regard had little to do with a brief, but more in insisting upon having a design research phase prior to building or concepting anything.

On the flip side, you can see the lack of a good, completed design brief process in projects where the value to users was never definite. The work tends to drag on and on. Iterations don’t typically result in tangible benefits. People are confused about what they’re building. You also see repercussions in work that we spent a lot of time on but that never gets shipped. Although I wouldn’t hinge any challenging project’s success or failure solely on a design brief, I think this points to an area where we can get stronger as design leaders.

2. Don’t reinvent the wheel


An excerpt from a Foundation-wide audit capturing our many different button styles

It’s often harder to build on someone else’s work than to start fresh. We have seen this time and time again, from needless recreation of a login process or email templates to the introduction of entirely new styles for pretty well-established projects. Sometimes this evolution is useful, but often it results from a poor hand-off process. We need to work better at practicing the design skill of learning from each other’s thoughts and experiences so that we are not as often building from scratch. I already see this happening the closer we get as a design team.

3. Thoughtful end-to-end experiences


Because of the way many Mofo projects are organized into clearly scoped two-week sprints, designers’ work is often relegated to their own slice of the pie, however this often doesn’t result in the best experience for users. Designers need to worry about what experience they are designing for, not which project or team or timeline, and attempt to work with whomever necessary in order to improve that experience. Redesigning Thimble’s UI was a good example of where this was done well, in that the new Thimble navigation bar had some similarities with the Teach site, making it more likely that users who navigate from one to the other do not end up lost or confused. This was not part of the original brief but was identified out as a design requirement in the design process.

4. Craft, detail, seamlessness

thimble brand

The amount of work we are handed as a small design team is often immense, but we are now ‘grown up’ enough as a team and culture to not use that as an excuse for poor craftsmanship. We have the ability and wherewithal to scope projects, suggest timelines, define styles and guidelines and make decisions that benefit the design.

Mozfest stage design

As designers, we’re the frontline for how users perceive and experience so many Mozilla projects. When we care about making design that is bold, interesting, and delightful – and that truly solves the brief – users can tell; this showed up at Mozfest and in our End of Year Fundraising campaign. It’s also clear when a designer owns their design from end-to-end; instead of passing off to a developer to build, they work with that developer and ensure design QA is followed up on. The new Foundation Research and Open Web Fellows sites did this well.

For me this is the most exciting area of growth as there is so much opportunity for being bolder in our design and ideas, for influencing how Mozilla design shows up in the world, and for building on each others’ strengths to make truly kickass work.

5. Documentation


The styles for some projects, like Webmaker, have been very well documented. Others, like for teach.mozilla.org, are only being documented now. We can make the decision to work from style guides earlier in the life of a project in order to help us make decisions that are more deliberate and that ultimately, I hope, allow contributors to have a more meaningful role in Mozilla’s work.

6. Selling

Good design must be sold. I’ve seen the most amazing design research disappear into the ethers because it isn’t championed over the length of time it needs to be championed. I’ve seen the most innovative ideas disappear because someone didn’t ‘get it’. Part of being a great designer is the ability to influence decisions that lead to implementation of a good idea. This is something most designers can stand to get better at, not just at Mozilla, but I include it here because it is important. Learn how to speak the language of the client. Clearly articulate what is awesome about your design idea. Believe in it and help others believe in it too.

7. Community Design

hour of design

We didn’t do a lot of design outreach as a team this year. Ricardo did some amazing open design streaming on YouTube, among other things, and several across our team have worked with individual contributors. But with the advent of the new Mozilla Community Design repo I’m looking forward to seeing how we can become more involved and more effective at facilitating open design on the web. Many of the Foundation designers are already involved there, which is exciting to see.

Next Steps

These observations are not made in isolation. They come from speaking to many colleagues, including the Foundation designers. They come from slowly digesting the work we produced over 2015, and they come from a long history of working as a designer and absorbing inspiring talks both at Mozilla and outside of it. A number of these points I know our team is actively working on – the list of ‘things to work on’ is as much a list of ‘works-in-progress’ – so none of it should really be all that earth-shattering. But it’s good to get it down.

I’m excited to check back in at the beginning of 2017 to see where we are at. On on, go team go!