Plot 47A

Words on design and life by Cassie McDaniel

mofo-design-2015
February 10, 2016

Design at Mozilla Foundation 2015/2016

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.

mountain-mountain

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.
        desktopdailies-tumblr-com-1455136407182
      • 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

buttons

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

xray-full-2

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

webmaker-ui-toolkit

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!

Group hug while others stand to the side
August 14, 2015

That’s a Great Question

When someone says, “That’s a great question!” several things happen.

  1. The person who asked the question feels good.
  2. The person responding gets a moment to think about their answer.
  3. Others in the room who had the same question feel either relieved they’re not the only one with this question or disappointed they didn’t ask first. They might be motivated to think of other ‘great’ questions.
  4. The person who asked a different question but didn’t receive the “great” feedback feels their question wasn’t good enough.

Whenever I say “Great question!” my intention is never to leave anyone out. Using enthusiastic language keeps up the energy and can make people feel comfortable. But singling out individuals often makes others (particularly folks who already feel marginalized) feel disregarded.

I’d like to do better. What if we responded with what we actually mean? We could instead say, “I haven’t thought about that question yet,” or “That’s a tricky one for me to answer.” These responses honor the significance of an unusual perspective, but are more inclusive to those folks who have a hard time speaking up.

It’s a simple change but I think could have a beautiful cyclical consequence: in ensuring all kinds of voices are heard we invite a greater variety of voices to our work. And we need that.

net-hands
August 14, 2015

Skills not talent

Probably your whole life has been centered around pursuing what comes naturally to you. Mine has. We are encouraged as kids to forge career paths around whatever it is we are good at. That’s a fine thing, but the emphasis is wrong – don’t do things because they are easy, do them because they are meaningful.

A talent is being a good conversationalist. A skill is listening when it matters, even when it is hard. A talent is making things look good, while a skill is laying out meaning. A talent is unpredictable. A skill is a finely-tuned and practiced tool.

It is more admirable to work hard than to coast through life on a natural, undeveloped talent. I’d rather see talents controlled and applied where they are most useful than an emphasis on natural greatness. Talent doesn’t have to be your safety net, because skills can be.

July 3, 2015

Not Brave Enough for the Internet

I try not to squeeze my eyes shut in real life but lately the sheer amount of suffering, how deep and wide its reach, how much at the surface of our lives it is, how personal and abstract, how very real it seems, how both unstoppable and sadly stoppable it is at the same time, if we just knew more, did more, did less, knew less, spun around in circles, stamped our feet twice and drank a vat of pig’s blood. (I’d give you examples, but it seems cruel.) I don’t know how to fix any of it, how to truly help, or how to be better than I am other than to turn inward, to look locally, and to say ‘yes’ as opportunities arise. Those feel like cheap solutions in light of huge pain.

Through the lens of social media the stream of despair is heavy and unceasing. Every time I go on Facebook or Twitter: some kind of tragedy, inexplicable horrors, abhorrent abuse, intolerable unfairness, cruelty, bad luck, unnecessary suffering. It is not that I want to squeeze my eyes shut or that I think people should not be sharing these stories by any means, but I often have to click away before I get to the end of the page, before I dissolve into a sopping mess of a person at my desk. For some reason, the stuff of the Internet manages to squeeze past my curmudgeonly, cynical surface and into my soft-hearted empathetic core. It is like there is a vulnerability in me that has not adapted to being able to cope with the rawness of seeing type and imagery together on a screen. And it is often that much more painful because in reality, so much of it is out of my control, if only for the sheer amount of it. I am often left feeling as if no amount of goodness can make up for the losses.

There are beautiful things about the Internet – connections, opportunities, making. A part of me wonders if contentedness depends on shifting the focus to those things.

Still, something dark lingers. Maybe it is not so much finding fault with the Internet, but with the real world that it reflects. It feels as though I am running laps around myself in some kind of ineffectual dream state. Too afraid to do something. Too afraid to do nothing. The only way to cope is to try and live my moments as they happen. Be grateful, kind, humble, brave, and be these things on a daily basis, with people who are closest to you.

How is the Internet treating you these days?

June 19, 2015

Meet your friendly neighborhood designers

This week I am sharing a series of posts to reach design candidates in far-flung corners of the Internet to fill this UX/UI designer role at Mozilla Foundation, and to improve the quality of design candidates everywhere! Check this post for a listing of all the topics as I post them.


Next week all of Mozilla’s employees and many contributors will gather in Whistler, British Columbia for one of our twice-annual company gatherings. A thousand people converge in a single place and it is… intense. There is much anticipation and work needed to prepare for such an event. Still, I wanted to introduce three of our designers at the Mozilla Foundation who graciously took a few minutes from their stretched schedules to answer my silly questions. For that, and for all the dedication and joy they bring to their work on a daily basis, I <3 them dearly, and I know you will too.


_wm-play
_ricardoThe first to respond to my questionnaire was Ricardo Vazquez, perhaps the nicest person on the planet. If he’s not talking about smiling, happiness, good feelings, designing for emotions or microinteractions, then he’s probably out in the wild helping someone do something that matters. He’s extremely dedicated to the craft of UI and he works hard to improve and simplify the interactions of the Webmaker app and platform. He’s based out of the Toronto office. Here are his answers to my silly questions.

Me: What is your design superpower?

Ricardo: My perspective on design is emotional. When I was in university, I became eager to find out more about how we construct our identities as members of society. Do we follow an archetype? Do we deconstruct ourselves in order to fit in a particular community? Questions like these, albeit more philosophical in nature, have ended up guiding my approach to design. When I was doing my undergraduate research I focused on the emotional impact of certain creative outputs on an individual. For example, music accesses deep emotional connections to memories, experiences, and happiness. This can be applied in to UI design as well. I seek to emotionally connect individuals with the products and features I design.

We know you fantasize about other careers. After being a designer, what career would be your second choice?

It is hard to beat design, but in another life I would have loved to represent Canada on its national rowing team. I love rowing. I started during my first year in university and have kept at it since. Rowing allows me to find stillness in my day and focus on the sound of water rushing by me. A close third would be to become a professional trombone player and have the opportunity to play at Carnegie Hall.

What is your favourite (perhaps surprising) design tool?

I think it might just be the train! I take the train everyday to work. During this time I am able to find silence and let my mind wander off to unexpected places. Sometimes I encounter a Eureka moment, other times I’m left content with having daydreamed.


_teach-homepage
_Sabrina_NgNext, meet Sabrina Ng, UX/UI designer based out of Vancouver. Sabrina’s work has been described as meticulous, insanely thorough and very thoughtful. She designs well under pressure and with huge amounts of uncertainty and complexity. More than any other designer in the org she has also influenced every corner of the Foundation, touching design for nearly every project, from Maker Party branding work to the Mozilla Advocacy website. She’s now leading the design for the latest lovely incantations of teach.mozilla.org.

Me: What was your favourite snack when you were five? What does that say about who you’ve become?

Sabrina: A glass of Ovaltine with condensed milk accompanied by toast with a thick slice of butter, made for me by Grandpa daily. Exercise goes a long way if you have a horrible diet! Also, being aware that not all things from loved ones are necessarily good for you or that you have to accept them.

If you could completely eliminate one thing from the world, what would it be?

Food allergies. I don’t like being limited by a fear of mysterious foods. :(

We know you fantasize about other careers. After being a designer, what career would be your second choice?

If it wasn’t in the realm of design, perhaps some sort of dancercise fitness instructor or occupational therapist. But I have thought about architecture too.


_webmaker-logo
_jordan-gushwaFinally, meet Jordan Gushwa, Mofo’s newest hire. Jordan lived in Qatar for several years leading a design team at Virginia Commonwealth University before moving back to Portland. He’s taught classes on mobile and responsive web design and clearly has superpowers around branding and typography. We’re so excited to have him on our team and already contributing in major ways, like having redesigned the new Webmaker logo… in four days.

Me: What is your design superpower?

Jordan: Vision. I have 20/15 in one eye. This makes me super good at registration when screen printing. I can also use my Macbook screen at the highest resolution making everything super tiny and giving me more desktop space than other people :)

What was your favourite snack when you were five? What does that say about who you’ve become?

Something grownup like a slice of cold steak out of the fridge. I have always had too much respect for grownups. I hold famous old school designers in higher esteem that I probably should.

If you could completely eliminate one thing from the world, what would it be?

Bad lamps and expensive nice lamps. I’m hitting up all the designer clichés right now but it’s hard to find a nice lamp for under $500! (We have been looking in Portland for a year.)

We know you fantasize about other careers. After being a designer, what career would be your second choice?

I have always wanted to be a chef, but I know it would be terrible. I would like to be a research chef, one that invents amazing new dishes but does not need to run the kitchen any more.

What is your favourite (perhaps surprising) design tool?

A chisel and mallet.


A big thanks from me to Ricardo, Sabrina and Jordan for humouring my questions! I am so excited to hang out with them and the whole team in Whistler next week. People often say they stay where they are because they like the people or they like the work. I feel privileged to say I stay at Mozilla for both.

I hope some poor soul has found my blog posts this week helpful as they think about their next career move. I’ve tried to write with candor and share advice I have found helpful in my own many job searches. Maybe these posts will prompt someone awesome to want to join us, but at the very least I hope it will help some students as they embark on their paths toward becoming great designers.

June 18, 2015

Frequently Asked Interview Questions

This week I am sharing a series of posts to reach design candidates in far-flung corners of the Internet to fill this UX/UI designer role at Mozilla Foundation, and to improve the quality of design candidates everywhere! Check this post for a listing of all the topics as I post them.


Preparing for an interview

I’ve said this in previous posts this week, but it is astounding how many candidates make it to the first interview without knowing anything about Mozilla or the position. It’s worth doing a bit of research beforehand. Doesn’t have to be a lot, but at least Google the company – there’s a lot in our recent history to be aware of. Mozilla is a big organization and nearly everything we’re doing is open and online so it’s hard to humor any excuses for not doing this.

Also, Google who your meeting is with. Why wouldn’t you? I expect that you will probably read my tweets and maybe glance at an article I’ve written, and if a topic I’ve written about comes up in an interview and you are able to speak to it, that’s interesting. It’s a little awkward perhaps but nice because I know you care about this interview.

Questions I ask candidates

What follows are a bunch of questions I normally ask in interviews. Maybe you want to take these and practice with a partner or friend? I did a lot of this early in my career and it never hurt. I felt more prepared and at ease at least, which was half the battle.

  • What brings you to Mozilla? Why do you want to work here?

What I’m looking for: I want to know if you care about our mission but I also want to know explicitly how you found out about the position. It’s an easy way to gain mutual ground off the bat, if there is any, and it’s solid information for me to put to use when posting future positions. It’s a good question for me to gauge a candidate’s sincere interest in the position, too. If someone is just dipping their toes in the water to see what’s out there, I am less interested in them than in the candidate who says Mozilla is the only company they applied to.

  • How did you get started with design?

What I’m looking for: That you take design seriously. I tend to fall on the word-ier, head-ier side of design, but that doesn’t mean you have to. I just want to know that you carefully consider your design decisions, that you’re able to back them up, that you are confident in your abilities. It doesn’t matter to me if you were trained at the most prestigious university or if you were self-taught, but I would like to understand your approach to learning and staying current in the industry.

  • Where do you look for design, illustration, UI inspiration?

What I’m looking for: Does anything inspire you? What kinds of things get you pumped up? I want to geek out with you. It’s great when someone can do this easily with new people; I’d hope they could bring a similar openness and excitement to brainstorming sessions and everyday work.

  • Do you have experience working remotely?

What I’m looking for: We’re a remote team whether you choose to work out of an office or not. Traversing time zones and not getting lost in that world requires communication superpowers. Experience with this mode of working means you’ll know it has its ups and downs and are willing to work with them. If you don’t have experience working remotely, it’s not a deal-killer if you can work out of a local office (NYC, Toronto, Portland, Vancouver, SFO) but in that case it helps to demonstrate effective communication skills through writing, showing up to meetings on time, etc.

  • What are you looking for in your next position?

What I’m looking for: I want to know if Mozilla is a good next step for you. Can we offer you the kind of career growth you are looking for? We want happy employees and won’t get that if we have mismatched expectations. It also shows you are thoughtful and self-aware.

  • What are your salary expectations?

What I’m looking for: I want to know if your financial aspirations are way out of our budget. Under-asking can also be a flag that the candidate doesn’t have quite as much experience as I’d thought. Neither is right or wrong necessarily, but there is a happy medium and it pays (often literally) to do research prior to the initial interview. Check out AIGA’s design salary calculator and ask around to friends for the going rates.

  • Would you call yourself perfectionist?

What I’m looking for: I feel like this is the only trick question I ask and now that I’m giving away the secret I may have to get smarter about how I interview! But, this is not a yes or no question. The correct answer is “Yes and no.” A lot of people clearly identify as a perfectionist or not, and it’s totally okay to embrace that tendency, but a good candidate will be able to speak to the value of shipping and of working to deadlines. I love perfectionists; I often am one myself. But at Mozilla we design products iteratively and we need designers who can work to a certain level of quality, pushing the designs when needed but also able to let go when it’s time to press publish.


Questions candidates ask

I do appreciate when questions come naturally out of a conversation, and I do leave some minutes at the end of an interview to address any concerns a candidate may have. It’s okay to recycle these particular questions, they are the most common or impactful ones, but I urge you to think about your own values and experiences and to formulate unique inquiries that will be helpful to you in making a decision about the position.

  • What kind of projects will I actually be working on?

The best question, and not frequently asked! At the Foundation the design team separates its work into product buckets. We have Learning Products (Webmaker app and webmaker.org),  Learning Networks (teach.mozilla.org), and our ongoing Engagement work which includes communications, fundraising and Mozilla Advocacy.

Right now we don’t have full coverage of our Learning Networks and Engagement work. (This could probably be said of all these buckets though). Some of this outstanding work is high level product thinking and strategy, and some is complete execution from the beginning concepts and UX thinking down to working with engineers, or getting your own hands dirty in pixel implementation.

Given the depth and breadth of work at Mofo, we try to find good matches within the team for skill-sets, people chemistry, interests and growth. Because we’re doing a variety of tasks there is room to move people around a bit. Designers in the org are expected to help make big decisions about new features, lead discussions, think big, implement well. It’s a lot to expect but also a huge opportunity to drive the direction of large-scale products.

Lastly, the design team works together frequently whether by reviewing each others’ designs in weekly critiques or pitching in illustration skills for a sister project. For as much as we like people to be able to focus on a single project at a time, there are many opportunities to hop into other projects.

  • What is the design team process like?

Our team is writing a Design Handbook about our process with everything you need to know and then some. Read it here. We’ll also be documenting and updating some of our material linked from our work hub, http://build.webmaker.org/design.

  • Will I be able to continue practicing my dev and design skills?

Absolutely. This is something we care deeply about, and as recently as last week we had a discussion with designer-engineer hybrid folks to try and figure out how we could better support people with mixed skill-sets. We often have small tasks for prototyping new features that are prime for someone who wants to pick up new skills and there are plenty of people within design and engineering teams that make good mentors. We have many designers with engineering skills and engineers with design skills and people all over the organization with surprising backgrounds – so just because you fall under one team’s umbrella certainly doesn’t mean you’ll never be able to do something other than what your job title dictates.

  • Do I have to learn dev skills?

Not by my book. As any good interactive designer, you should be deeply aware of the possibilities and constraints of technology but that doesn’t mean you need the skills to actually produce shippable code. Design is deep enough to specialize.

  • Can I work remotely?

Chances are good! The Foundation’s design team is scattered between Portland, Vancouver, Toronto, NYC and my small hometown in Paris, Ontario. So you will be working remotely with this team to some degree regardless of where you are. You can choose to work out of an office in one of our main hubs (Toronto, San Francisco, Portland, New York, Vancouver and possibly London). Many people work remotely part of the week and saunter into the office for snacks and camaraderie later in the week. The more experienced you are with remote work the more likely we are to accommodate a full-time remote situation for a new hire, otherwise it can just be too hard on a new employee to feel like they’re working in isolation and not connecting with a team.

  • What tools does the design team use?

Half of us use Sketch and the other half use Creative Suite. It comes down to preference, though those of us not yet on Sketch have active goals to make the switch given we’ve heard great things about it. Designers should feel free to use whatever works for them, whatever can get the job done quickly and well. If a sketchbook can do the trick and is fastest, awesome. If it’s better to animate it in AfterEffects, or to make a gif, go for it. We try new online tools all the time as well – currently Redpen for design feedback, Invision for prototyping, Google slides for gathering ideas. We have a corporate subscription to Google app so we use Drive for file-sharing. For bug tracking and project management type tasks we use Github, sometimes Bugzilla. For real-time communication we use open source software Etherpad, for collaborative note-taking, and Vidyo for, well, video calls. Mofos tend to be willing to try anything that helps us work quickly and efficiently.

What’s next?

By this point, you should have a good understanding of what Mozilla’s hiring process looks like, some tips to improve your cover letter and portfolio, and now a whole arsenal of questions and answers up your sleeves. You should be set to apply for any open design jobs (including ours). Tomorrow will be my last post about design hiring for the week and it’s a fun one – I’ll introduce you to a few Mozilla Foundation designers, talented colleagues I’m humbled to call my team. Seeya then.

 

June 17, 2015

Oh-Portfoli-Oh

This week I am sharing a series of posts to reach design candidates in far-flung corners of the Internet to fill this UX/UI designer role at Mozilla Foundation, and to improve the quality of design candidates everywhere! Check this post for a listing of all the topics as I post them.


I set out to write this for designers building their own portfolios, but a lot of this advice could be handy for other types of websites too. Much of it is familiar material for seasoned designers but I imagine myself as a young graduate and this kind of thing might have been helpful as a checklist. So here goes.

The basics

  • Show the work, don’t hide it on an interior page. Make it your homepage, even. It’s what I came to look at so make it easy to get to. Also, you don’t need to fancy-up your work by photographing it on screens and at an angle. That makes me think you’re not confident that the work can stand on its own. Just show it, full-resoluation and with live links if you can.
  • It’s not terrible to use a template. I can usually tell when you’ve used one, and all that means is that I focus in a little more on the work (which is a good thing). Just don’t let the template design get in the way of your own designs. It should be neutral and quiet and if you’ve paid good money for it, it had better work on mobile!
  • Make sure all the links work. And don’t have ‘coming soon’ sections.
  • Don’t be too wordy. I won’t read most of it, so it’s a waste of your time to put it together. There is a true value in knowing the appropriate length of content for your audience and designing for them instead of for yourself.
  • Lay out what your role in the project was. Tell me if you did the illustration and copywriting, or just the UX. I’ll ask eventually and it’s better to be upfront about this.
  • Can you just make a pdf? Sure! As long as it’s easy to share with colleagues and meets some of the above criteria, I’d love to see your work in whatever form you can provide.

When choosing what work to include

  • Show your versatility. If you can design with many different styles, show me. If you have a hidden talent for designing logos in addition to your UI chops, show me.
  • Only show work you’re proud of.
  • Show your process; write a wee bit. Show sketches. So few people do this, it shocks me, and always stands out when I see it.
  • I think it kind of okay to show old work if you place it in context, i.e. clearly label it from 2010 and call out what still makes it special. The reasons I say ‘kind of’ is because it makes me wonder what you’d been doing between 2010 and 2015, and often the aesthetic is so out-dated that it is hard to assess generously. It’s your portfolio though, and your call.
  • How many projects? Somewhere between 6 and 12 I’d say, depending on the depth to which you show them. Show more if you’d like but make sure you’re proud of every piece.
  • What about work done under NDAs? I wouldn’t include them. They’re awkward. If you really want to show me you can screenshare during an interview but most of the time I’d rather skip the password and look at work that’s open.

About sections

Should you include one? Sure, I like to know a little more about who we may hire, but you don’t have to go into a lot of detail. I definitely think you should not include a picture of yourself. It makes me deeply uncomfortable to know that seeing a photo of an applicant might bring out some kind of subconscious bias I might have. A colleague of mine and I have talked about going a step further and eliminating names from applications to make them truly blind; I’m not sure how that would work with design applicants given folks’ personalized portfolios, but I’d sure love to see it happen eventually.

Blogs

Should you have one? Probably. How else do you think and share and communicate and work openly?!? Definitely not a requirement, but I like seeing the extra effort put into this when possible, even and especially if they are really short posts about things that inspire you or make you think. That said, blog because you want to blog, not because you want to back-fill an empty shell of a blog you pretended to maintain over 2014. I will find out eventually! You could probably substitute the word ‘blog’ with any other social media platform. Mostly for me this is about understanding your values and how you think.

Contact page

You don’t need one. Just gimme your email address, please.

Some inspiration

Lastly, here are a handful of portfolios I like pulled from recent grads at the University of Florida (my alma mater) and other rando professionals I like. Many of them break the rules I listed above but they do it so beautifully, with great content and some with impressive interactions.

Enjoy! Tomorrow – Frequently asked interview questions.

June 16, 2015

Don’t tell me everything (advice for cover letters)

This week I am sharing a series of posts to reach design candidates in far-flung corners of the Internet to fill this UX/UI designer role at Mozilla Foundation, and to improve the quality of design candidates everywhere! Check this post for a listing of all the topics as I post them.


Time I spend looking at your stuff:

Cover letter: 6 seconds
Portfolio: 30 seconds (if I like it)
Résumé: 5 seconds (if I look at it at all, initially)

I don’t say this to be a jerk but to illustrate how quickly you need to get my attention.

Factors that might adjust these lengths of time are where I am at in the hiring process and what level role I am looking for. The position open now is for a mid- to senior-level designer so it’s important I find someone who knows how to communicate effectively. Inevitably, it is the cover letter I look at first to help me figure this out. And for that you have six seconds.

The function of a cover letter is to tell me if a person is human, if they can be direct about what they want, and whether or not they can string together a sentence. It truly does not need to show me that you’re a creative person.

Here is a formula for a good cover letter.

Dear person,

I found your open UX/UI role through ___________ and wanted to apply because ____________. I am crazy excited about what Mozilla is doing because _____________. For the past couple of years I’ve been doing ___________, but this position will help me _________. I would love the opportunity to share my work with you and to hear more about the role. You can see stuff I’ve been doing recently at www.ilovedesign.com.

Thanks for your time,
Person McPerson
@personmcperson

This might look boring to you. So let me illustrate why this is actually good.

  • It’s short and to the point and doesn’t sound like it was written by an egomaniac. It’s friendly, but professional. There are no grammar or spelling mistakes. Shows you’re respectful of our time.
  • It is equal parts you and us. It tells me something about your history and your interests (which I will be able to ask about in our initial conversation) but it also shows how and why you are interested in the role.
  • It includes a link to the portfolio (which is clearly stated in the job description as being mega important). It demonstrates an understanding of what the hiring process is like by making this super easy to access. And it shows you stand by your work. You’re not trying to cover it up with fancy words and ideas.
  • It shows you’ve read the job description and that you know something about Mozilla, yet it doesn’t mention Firefox. (It’s okay to mention it briefly, but that’s not what this position is about).
  • It’s not ranting. I don’t need to hear about why your current job sucks. We can give that the nuance it needs in a conversation, if you must. And if I really want to hear your ranting I can go right to your Twitter account.

I was curious if my own cover letter when I applied to Mozilla holds up so I dug it out of the old gmail archives. Originally sent February 7, 2013. It could be shorter, but the similarities are uncanny! (Pats self on back) Look at what a dork I am:

Hi Ryan and Brett,

Chris Appleton mentioned you’d be hiring a UX Designer for the Webmaker tools. He knows I’ve been looking for a position at Mozilla so forwarded your addresses, and I’m really pleased to submit my résumé (attached) and portfolio for your consideration – www.cassiemcdaniel.com I do have more of an interactive design / UI background, but user experience has always been a crucial part of that skill set.

I saw Mark Surman speak at CreativeMornings the other week and really love the Mozilla mission. I am keen to find out more about how things work over there. I hope we are able to meet for a good chat at some point soon!

Thanks for your time,
Cassie

Cassie McDaniel
www.cassiemcdaniel.com
@cassiemc

I’m definitely not saying your cover letter should sound like me – it should very much sound like you – but you really don’t have to reinvent the wheel for this or spend too much time on it. Keep it straightforward, brief (for crying out loud keep it brief), and be honest about why you’re interested.

The cover letter is just the beginning. It’s getting that foot in the door, which I acknowledge can be difficult. I hope this makes it easier.  Tomorrow I’ll share some tips for improving your design portfolio which will be the real clincher! ‘Til then, amigos.

01b-hiring-process
June 15, 2015

Design Hiring Process

This week I am sharing a series of posts to reach design candidates in far-flung corners of the Internet to fill this UX/UI designer role at Mozilla Foundation, and to improve the quality of design candidates everywhere! Check this post for a listing of all the topics as I post them.


First: a warning. Everything I’m writing about over the next few days is dependent on a number of factors – who I am, who you are, what kind of organization I work at, what industry we’re in, what time of day it is and whether or not it is raining. Nothing is a rule. Please don’t do exactly what I tell you; adjust it as necessary. My main objective is to just offer insight, a small glimpse behind the hiring curtains, data points – so that you can go forward and make your own informed decisions about what to do or say, what not to do or say. If some of this advice helps you find a job, amazing, the Internet works! If it prevents you from getting a job, then Brett Gaylor my previous boss taught me everything I know. :)

Okay, now that the disclaimer is out of the way!

Tomorrow we’ll get into the nitty gritty of how to be a better applicant, but today I wanted to start with outlining the hiring process. We’ve all been there as applicants, but not everyone’s been on the other side of the fence doing the hiring and it can be helpful to know how things look from the employer’s perspective. I’ll show you how it works on my team at Mozilla (other teams at Mozilla will be different).

For the record, “How does your hiring process work?” is also a perfectly legitimate question to ask in your first interview no matter where you are interviewing. It will help you avoid the stress of not knowing response timelines or how much time you need to set aside for future interviews or other activities you might be asked to do.

What happens before the job is posted?

Justifying that a new hire is needed to the powers that be can be a lengthy affair. I don’t fully understand every detail of it, but the gist is that at a company as big as Mozilla it isn’t as simple as factoring a new salary into the budget and posting the position. That’s part of it – employee costs at Mozilla have a huge financial algorithm behind them (salary, benefits, equipment, office space, travel expenses, setup costs, even snacks and meals, and then measuring that against existing and projected budgets) but there is also the factor of how new employees will fit into existing teams and strategic plans. That’s the part I have a better sense of.

In an ideal world, the amount of work a team needs to do will match perfectly with their ability to do so, which looks like that pretty straight green arrow on the graph below. There will not be too much work, and there will not be too little.

01-hiring-diagram

For this thought experiment lets focus on increasing capacity (rather than the less desirable alternative). The further that arrow moves right along the horizontal axis as the amount of work increases, so too must the team’s capacity increase in order to maintain a balance. When the capacity does not increase, that’s when you end up with a sad, droopy red line. This  might look like asking a team to keep working harder and harder but without hiring more staff. We’ve all been there. Green is the ideal. Red is the reality.

02-hiring-diagram

There may be better diagrams for this, but I think of that space between the red and green lines as stress. Stress on individual team members, stress on management and stress on the organization as a whole. The problem with stress is that it jeopardizes any work you’re actually managing to get out the door, and typically it stresses your best employees who are the ones that tend to take more responsibility for all the things falling into their laps.

Some stress on a team is healthy. Similar to how forcing design constraints can make people think more creatively, so too can limiting a team’s capacity; it forces hard decisions about priorities, it prevents people from going too far down rabbit holes (whether getting lost in details or working too much in isolation), and it can create a competitive and challenging environment that high achievers thrive in.

03-hiring-diagram

The trick to timing a new job posting well is to anticipate the point at which healthy stress becomes detrimental, and to make changes to address this as soon as possible. Generally, most people notice this too late – when someone has turned in their resignation letter, when design begins looking lackluster, or when complaints rise to an annoying din. Our goal on the Mozilla Foundation’s design team (especially in this period of product growth) is to plan well and create a repeatable, efficient process – both for design in general and for hiring.

The other basics to understand are this:

  • Good job descriptions are both well-written and well-thought-out. They address a clear need in the team. So hiring managers should be able to easily answer a question from an interviewee about what projects they would be working on, at least in the short-term.
  • I wrote the job description, not a robot. It wasn’t taken from a template site. And since I am human it’s definitely not perfect. Feel free to challenge me on any of the assumptions. For instance if you don’t think you need to know UX design and UI design and animation, please, convince me why and tell me how you could still do the job.
  • Many conversations happen before a new position is posted. I talk with my team, my manager, our HR manager, and often other team leads to assess everything from whether or not we actually need another person to what kind of skills we need. By the time actually posting the job surfaces on my to-do list, it is one of the final steps in the process. I point this out mainly to illustrate the process’ complexity, which might come in handy when you are thinking about how to negotiate your contract.

What happens when you apply?

If someone applies at Mozilla, they submit their résumé and cover letter through Jobvite. Jobvite recognizes me as the hiring manager for this position and so I get email notifications for every applicant, which I typically look at in a filtered list in Mail. What Jobvite includes is the cover letter and résumé. I might skip the résumé as it generally looks junky by the time it arrives in my inbox, so most of the time I just scan the cover letter looking for a link to your portfolio. I love people who make this easy for me by including a link in their cover letter!

jobvite-to-mail

I do skim every cover letter and open up every link I receive unless there is something clearly wrong with the application (e.g. the letter isn’t written in English, or the applicant is not within our hiring jurisdictions which we state very clearly on the job posting – currently US, Canada and the UK).

Often I spend less than five seconds on a portfolio, and probably less than a minute on most applicants in general. But I do look! I am very proud of that – I doubt most people even look past a bad cover letter.

More on that coming later this week but I will say that a well-done portfolio can hugely make up for a terrible cover letter. However, seeing both in great condition is what gets me really excited about a candidate.

What happens after you’re selected for an interview?

process-overview

First interview

As the manager for the position being hired, sometimes I will conduct the first interview and other times I enlist help. This is where companies might typically use a recruiter but I like getting my hands dirty. The initial thing I’m looking for in the first interview is whether or not you’ve done your homework. Do you know what position you’ve applied for? Do you know anything about the Mozilla Foundation? It’s amazing how many talented applicants do not pass this first interview because they cannot speak to these questions. It seems really basic to me, but there it is. We obviously can’t justify moving forward with a candidate who hasn’t prepared for their first interview.

01-interviews

The first interview may seem slightly technical when I ask designers to walk me through a project in their portfolio, but this line of questioning is actually more about communication and personality than it is about the work. How well can you speak to the objectives of your work? How excited do you get when talking about it – are you mostly positive or negative? What seems to motivate you? Have you represented yourself accurately in your application materials? Are there opportunities here for me to figure out how well you work with others? This is probably the most stressful interview for a person, so while I actively attempt to put the candidate at ease and get them to see why Mozilla is an awesome and friendly place to work, it’s also a good chance to dig into how a person handles high-pressured situations.

A third part of the first interview is to figure out if you meet basic requirements for the position. We have a budget and want to know if your salary expectations fit, and we don’t want to waste time if this basic point of agreement is wildly off, so we will ask you this upfront. We also ask about where you would prefer to work (in an office or remotely) and we will want to make sure that occasional travel is okay with you (we currently travel around 2-4 times a year to work in person as a team). The ability to hit all these questions on the head is not necessarily a deal-breaker, but these answers are all super useful information to have to inform our decision-making. If you are ever wondering in an interview why I am asking a particular question, I am more than happy to oblige you with an answer.

Second interview

The second interview is much more technical. This is the point where we can really geek out about typography, illustration, photography, animation, copywriting or whatever you’re into. Sometimes I’ll do the second interview but often this is a great opportunity for you to meet another designer on our team. It’s worth saying that sometimes when you meet other people from the team they can be less experienced in interviewing candidates, so talking to you is actually practice for them. It’s hard to know just how experienced an interviewer is, and it shouldn’t change the way you should present yourself as they are still assessing your skills, but perhaps it makes it a little less nerve-wracking to know that everyone has the same kind of butterflies in their stomachs when meeting someone new for the first time.

02-interviews

It’s usually during this interview that the candidate starts to relax. They’re talking about their work, what they know, they have a slightly better idea of what they’re getting themselves into so their excitement starts to show and they generally ask better questions. I really enjoy second interviews both as a person doing the hiring and those times when I’ve been a candidate myself.

Moar interviews?!

Past the second interview, we are generally looking for any red flags: Does this person really know what they’re doing? Would they be a good cultural fit? How well do they handle stress, get along with others? Does their desired career path match up with what we can offer?

03-interviews

You are probably wondering, ‘How many interviews are there?’ In Mozilla’s case, typically at least three: one with the design team manager (me), another with a teammate (another designer or engineer), and a third with my boss, VP Product, David Ascher. More commonly I would say there are four or five interviews. I had six when I joined. We want to make sure we have a well-rounded picture of you from various perspectives and teams and we want to give you a chance to meet people and get a sense of who you would be working with. Interviews truly go both ways!

If all the interviews go well, we are ecstatic at this point. We’ll ask for three references – one from a previous manager, one from a peer, and a third of your choice – which we will do the legwork to follow up on. This is a very important step in the process and we take it seriously. Typically it is me doing the follow-up with these people as it is a great opportunity for me to figure out how I can better support you as a manager. What I ask references is another blog post for sure!

reference-checks

The debrief

After these boxes are ticked the entire hiring team will debrief and talk about you. It’s an uncomfortable prospect to think about, but it’s ultimately good for you. If you had a crappy day during one interview and were really tired, but came to life and gelled well with a team member during another interview, that stands out. We understand that interviews are not very much time to get to know someone and we take that into account by considering the experiences of all interviewers and doing our best to create a well-rounded picture of you and your skills. This debrief also helps us surface any discrepancies and figure out if we need to ask any harder questions or if we are prepared to make an offer.

The offer

By the time we make an offer you’ll usually know it’s coming. It is, hopefully, a moment of celebration for both of us! And it usually is pretty easy given we’ve discussed expectations upfront in that first interview and talked extensively by this point about what you’re looking for in your next position. In my experience when thinking about an offer, it has paid dividends to take a moment before accepting. Consider everything outside monetary compensation: the work-life balance, the work itself, the team, benefits, what your day-to-day will look like, and how you actually want to spend your days. It can be difficult to turn down an offer at this point after you’ve invested all this time in the application and interview process, but I’d rather that than hire an unhappy camper. That said we (I) have been turned down and it sucks! I know, boohoo employer, but I’m just telling you this because it presents an opportunity for you. The next section is about that.

A note about doing work before you’re hired

It seems everyone has a different opinion about this but here’s mine. On the plus side, contract work allows both employer and employee to get to know one another in a real working context before committing to a full-time position. On the downside, it favors candidates who are able to work in their spare time or who don’t need full-time benefits and can take the risk on you. We don’t have a clear stance as an organization, but I lean toward not doing it if at all possible. I would rather use the tools we have to assess someone’s work and character, despite that being difficult and not foolproof, because it seems more respectful to me and I’m usually confident in the final assessments. However, some teams ask candidates to fly to a city to meet the team in person (likely Vancouver or Toronto) for a final interview and in the odd case where we do hire someone on contract before we make a full-time offer we will always pay. These decisions are far from rote and are very situational, but whatever you do please don’t work for free, potential hire or not!

Hiring in waves

When we make an offer it is not guaranteed that the person will accept. We whittle candidates down to an elite small group and chose to pursue just one person, but when we make an offer and that person ultimately chooses to go somewhere else the hiring team goes back to the drawing board. It can be an exhausting turn of events. We sometimes revisit applicants who already applied, but in my experience that rarely works out and it’s usually better to start fresh.

process-waves

So just because a position may have been posted for awhile is no reason not to apply. The team may just be starting to examine a new wave of applicants and you might be a needed breath of fresh air.

I hope that some of this has been insightful. It’s turned out to be much more long-winded than anticipated so I am going to go ahead and press publish, extra commas, grammar problems and all. I’d love to hear some experiences from other people whether from the hiring or the interviewing side and figure out ways to make our process better. Share in the comments or send me an email. Tomorrow I’ll share even more unsolicited advice for improving your cover letter and portfolio. Stay tuned!

Mozilla design team
June 14, 2015

Designers, get hired

(I’m looking for you)

Tldr; Every day next week starting tomorrow I will share a series of posts about hiring and getting hired to distill some mystery around filling this UX/UI designer role at the Mozilla Foundation. If you’re interested in the position (our team is amazing!) apply at that link or simply email me with a link to your portfolio: cassie@mozillafoundation.org.

Day 1: Design Hiring Process
Day 2: Improving your cover letter
Day 3: Improving your portfolio
Day 4: Interview FAQs
Day 5: Introduction to some Mofo designers


I’ve been looking for a new designer for the Mozilla Foundation for awhile. We recently hired one talented new designer (Jordan Gushwa) to grow our team, then lost a designer (Jess Klein), so the position reopened. Hiring is the job that never ends! Sometimes we find a candidate that goes pretty far in the process but for some reason or another it doesn’t work out, so we slap our foreheads and start over again. Every day I check my inbox for new job applicants and about once or twice a week I schedule interviews. We have had many great recommendations and I’ve spoken to some impressive people but we are still looking for the right fit, and it’s a fit I can’t compromise on: Hiring is crazy important! The trickle down effects are enormous on our entire team’s day-to-day work and happiness, and the success of our products depends on it. I know I and my colleagues care deeply about working with someone who is passionate, real, and who inspires us.

I’ve read many articles about hiring for diverse teams – how to write job descriptions so they are welcoming and attractive and aren’t exclusive or intimidating, and while I’m conscious of trying to write something that isn’t too boring, pedantic, limiting or restrictive, vague, obtuse or misleading, the truth is that if Mozilla’s mission excites you and you are a designer with some experience, I really want you to apply. I’m not sure how else to say it. If from the get-go it seems like it could be a good fit (from our end, if your portfolio reflects the kind of work and thinking we will need you to do, and from your end if it seems like the kind of work you’d like to do), a conversation is usually all it takes to figure out the details and get us both excited. Most of the time it is not your résumé or your history that matter, but how you talk about what you’ve done and where you want to go.

If we end up interviewing you, that’s a pretty huge vote of confidence that we believe you could do the job. That said, we want to use open and inclusive language, and we also want to attract confident, skilled people. I will be honest: this UX/UI gig is a hard job. It’s challenging anywhere (or at least I hope you challenge yourself) but at Mozilla, we expect an extra lot from designers. We are in a time of flux where design has become more integral to everything we ship at Mozilla, and that means we need design leaders who can ask tough questions, handle complex requirements, and ship fucking awesome work. But – and don’t stop reading – as a design team infrastructure, we support, enable, trust, and encourage Mozilla designers to do the best work of their careers. More than any other place I’ve worked.

If you care about something, if you have an idea, if you are willing to work hard, Mozilla can help you make things happen. We (and when I say we, I don’t mean just the designers but also our engineers, product managers, metrics and marketing folks, teachers, community leads, managers, etc) are a team of scrappy, talented, ambitious makers who want to make the world a better place by a method that happens to be through learning and making stuff online. That doesn’t mean we know everything; we are in fact in a constant state of learning from each other and our users and trying out new ideas.

Because job descriptions are hard to get right, and because taking a new job is in many ways a gamble, I wanted to write a series of posts this week to help distill some mystery around the position we currently need to fill and to share a little more about my thinking as a team lead. So next week, I’ll be sharing a post a day around some theme related to hiring. I hope these posts are useful outside of our own hiring context too, as I see a lot of applicants who I think would benefit from a bit more transparency around the hiring process, regardless of where they end up working. I’ll share some frequently asked questions that I ask in interviews but also from applicants who ask me about the job and Mozilla. I’ll share some good interview tips, tips for improving your online portfolio, and I’ll introduce you to a couple of Mozilla designers. Through all of this, I hope you’ll have a better understanding of how this role – and design in general – impacts Mozilla’s work.

I have to admit, I’m a little nervous about sharing some of this. It has the vague uncomfortable stench of talking about something that is taboo. Give away the test questions before the test, what!?  Or, Share our hiring process? What if other companies steal it? Or, perhaps the dominant fear is that by sharing my tricks I might be enabling candidates to game the system. These fears are my own, so I choose rather to believe that the right candidates will already deeply know what I’m sharing here and that hearing what they know repeated back to them in this context might just affirm their desire to take the leap and apply.

I’m not sure exactly why the right candidate may not have applied yet, outside of not knowing that the position exists, but I hope to reach them regardless. The right candidates might be people who are full of energy and potential but are too afraid to step into a role they’re not fully prepared for. They are talented, but might feel a little disheartened by the industry right now. They are passionately involved in their own projects, but want to be passionate about their day job too. They might feel different from their other peers and want to join a more inclusive team. These candidates may see Mozilla and think ‘tech company’ and might wrongly assume there is no place for designers here. They may have worked in technology their whole careers, but aren’t sure how to continue growing their careers, and how to keep making tech more human. These candidates might currently be doing good work, and are probably even enjoying the work they are doing, but they want greater positive impact on the world.

If you fall into one of those categories, or even outside of them and you just want to design alongside me and our kickass design team, I want to hear from you. Apply here or simply send me an email with a link to your portfolio: cassie@mozillafoundation.org I’d also be very interested in feedback about our process, especially ideas to make it better.

So, make sure to check back here throughout the week for nuggets of advice and encouragement. Feel free to send me specific questions. Just hold on to your butts, designer friends, as you’re about to become very hirable.

Older Posts