Mozilla

I joined the team at Mozilla for a number of reasons but two really stick out. First and foremost I was excited to try and change the definition of what an "app" was and the work I did on Mozilla's Open Web Apps initiative certainly helped influence the industry thinking about the place of web applications in a growingly mobile-centric world. I was also very excited to join a growing UX organization as a leader to try and help embed user-centered thinking into everything the company did. Little did I know that I would also get to manage a team through some of the most difficult situations I've ever faced in my professional life: three CEO changes and two company-wide reorganizations in two and a half years.

Leading the team

I was extremely fortunate when I started at Mozilla, the overall UX organization had solid leadership into the executive ranks and I joined a group of UX leaders who were thoughtful, experienced, and shared my desire to make real institutional change. My team, what would become the Open Web Apps UX group, benefitted from that strong group of leaders in the company and made my job a lot easier… at least until the reorgs started. When the company rearranged itself to put everyone into a product vertical, instead of the functional groups we were in when I started, my team was suddenly isolated from the other six UX groups that had once all been "our team." There was a lot of worry to manage and reassurance was constantly part of my job. Despite these fairly large challenges, I managed to form better working relationships with our engineering and program management teams in our product group and reversed the stereotype of "UX as a bottleneck" which let us take the lead on a lot of projects, not a normal way of doing things at Mozilla.

Projects we lead were often the ones that garnered the most press, and excited the most people. Advocacy and changing industry opinions were our main objectives as a company, and my team constantly achieved those goals despite the very serious headwinds that were the FirefoxOS project and organizational upheaval. Our lead in successful projects and the stable foundation of how the team operated went a long way in relieving my designers' anxieties.

Project – MDN redesign

The Mozilla Developer Network(MDN) is a community contributed, Mozilla edited and maintained resource for web developers. “Encyclopedic” is often an adjective used to describe the site and the traffic it sees is huge. Try searching for something that has to do with Javascript and it’s usually the first result. At it’s core its, and quite literally the technology is, a wiki. It’s a website that sees hundreds of changes a week to both content on individual pages and the number of groupings of pages themselves. Our challenge was to bring some order to this massive changing site that made it easier to read and find the information contained in MDN, made it easier to contribute content to MDN, and made it easier for Mozilla to expand MDN to include the new products it was launching

A well thought out information architecture was the goal, and what I focused on in the project, but designing an IA for a site that could have six new sections next week and then ten fewer the week after that was a new challenge. Instead of building a rigid map of what we thought the site should be, we worked with a group of contributors and the editors of the site to create a framework everyone believed in and that met all our goal. To get to the final solution, we ran a series of interviews with the internal stakeholders, another with a group of highly active MDN contributors and then ran a fairly large open card sort with 100 MDN users.

When we started the project we pulled a snapshot of every page on MDN, and found out the site had roughly 39,800 pages and over 500 categories at that time. This obviously made creating a deck of cards to be sorted a little daunting, we needed to consolidate themes. We worked through this with our stakeholders and contributors in our interviews and ended up with a still rather hefty but much more manageable 93 cards. I should note here that having a very enthusiastic and engaged user-base is the only thing that makes a card sort with this many cards possible. We ended up with an 11% abandonment rate, and hit 100 responses in less than 36 hours.

From this point we took our list of categories the participants created and used some affinity diagraming to come up with a basic set of categories for the site, aided by the giant similarity matrix. While there weren’t very many surprises in the similarity matrix, some of the phasing used in the categories was different that what we had initially come up with and we let the tone and phrasing of our users influence our final wording. Under these new groupings we reused most of the existing IA inside of individual topics. In “Zones” each product group chose created a new IA for their new section on MDN.

While I was focusing on the IA of the redesigned site, the other half of the team was working on a new layout and identity for MDN. We had seen in research that developers were using tablets as a dedicated documentation screen in their work, and our new layouts made the experience of reading an MDN article on a tablet just as easy as on a 27" monitor. My role in these pieces of the project was largely to provide design direction to make sure that we were applying these new styles consistently and in service of the new IA and the findings our research had uncovered. The end result is a website that is still one of the authorities on web development knowledge but that has been able to grow as Mozilla has grown. We saw a huge surge in usage after the new design was rolled out, especially on mobile devices.

You can visit the live site at developer.mozilla.org

Project - Open Web Apps UX

When people would ask me what I was working on while I was at Mozilla my answer would often be, "The design team is my biggest design project." My role at Mozilla required me to be a design director, project manager, product manager, and researcher. The role I played most consistently on any given project was "whatever was missing." I touched every piece of work that came out of my team, and I am exceptionally proud of the many things we accomplished. Here are a few better write-ups or live versions of some of our work:

• Rebranding and Pattern Library for Firefox Marketplace
• Redesigning how Developers publish apps
• Redesigning the Mozilla Developer Network site (above)
• RecRoom – an opinionated Open Web App framework
• App Maker

In addition to putting on whatever hat needed to be worn to get a project completed successfully, I treated the processes the team followed like a design project. I found a lot of success in small process changes to the team:

I instituted and ran a weekly critique session. While this was initially seen as very "strange" to have a closed designers-only meeting, it dramatically improved the confidence and performance of my team. I've written more in depth about the process here.

I designed and built a series of Jekyll templates that allowed the designers to easily publish their design work to Github, where all of our developers and community contributors spent a lot of their time. This allowed us to get more eyes on our work, get more community involvement, and get more conversations going with members of the engineering teams. You can check out the templates and use or adapt them for your own work over on Github

I brought UserTesting.com into Mozilla and designed a series of test templates to let any designer (or anyone else) on any team in the company quickly create and run methodologically sound usability studies, even if they had no experience. The adoption was amazing and we started producing better, more defendable designs shortly after implementing it. I’ve written in more depth about the process here.