Growing our Design Team

I recently attended a talk given by Michael Lopp, the VP of engineering at Slack, in which he argues that, in a growing company, culture is defined by the team members who joined in the early days and instinctually believe the future of a company is based on what worked in the past. To be successful in the future, though, the culture must evolve in response to the new and varied experiences brought in by new team members.

Lopp’s argument got me thinking about how this applies on a smaller scale — specifically to our growing design team. In less than a year we have gone from one designer (me!), to a full-time team of three, plus one intern. As the single member of the original team, I keep asking myself what lessons from the past should stay? What needs to be scrapped completely? What needs to evolve?

Document Things and Build a Process

As a team of one, I touched every project, had face-to-face conversations
with PMs and devs, created every single mockup, and hardly wrote a single thing down. As the team started to grow, it was no surprise that this was far from scalable. It makes knowledge share needlessly difficult and allows for too many things to fall through the cracks. Enter documentation and process:

• We started writing design specs to include a clear problem statement for the new feature or service. Defining and documenting the problem upfront is a simple and helpful practice that forces us to ask questions to fully understand what we need to solve for. The simple step of writing this down makes it a handy reference to fight against scope creep, to defend particular design decisions or features, or reason-through a new solution when technical limitations appear.
• We developed a simple design checklist to run through for each feature request we receive from PMs. For example — Who is the user? What is our timeline? What indicates success of the feature? What are our technical limitations? When does this launch?
• We set up a shared Sketch library and a file sharing system to make
  sure every working file is accessible to each member of the team. A no-brainer – Sketch plugins, Google Docs and Dropbox are our besties :)

Proactive Design

Anyone who works on a product is accustomed to putting fires out. Whether it’s unexpected technical limitations that arise shortly before a release or missing the mark on a feature and scrambling back to the drawing board. It’s never fun, but it’s a fact of product life.

On my own, my design process felt more like putting out little fires everywhere; my design process was almost entirely reactive. When the team started to grow, though, we suddenly had time to help prevent those little fires – we had time to focus on proactive design.

By proactive design, I mean:

• identifying and validating areas of friction, and coming up with solutions before alarms sound;
• taking the time to ask questions of devs to understand framework limitations in order to provide feasible designs; and
• formalizing our user testing process – diving into gathering and evaluating feedback.

Encourage Individual Autonomy

Finally, one aspect of our old team culture to preserve is also a fundamental value of our larger company — personal autonomy. I feel strongly that it’s essential to creating good work and job satisfaction.

While we work closely with one another to bounce ideas around and get design feedback, each designer leads his or her own projects. Each designer is responsible for gathering requirements, engaging with the larger organization to understand the problem, getting feedback, and monitoring progress of development.

It can be a tricky balance to help each team member make confident decisions and push back where needed, but also feel comfortable bubbling up major issues to the team. Honestly, we’re still working on this — but so far a few things are working for us:

• A thorough on-boarding process to make sure each designer understands the history of the project and the vision for where it’s going.
• Personal introductions to folks inside and outside of the product team.
• Consistent check-ins to provide the opportunity to tackle problems together and give open and honest design critiques.

No doubt we will identify new problems to fix, and cherry pick habits to bake into formal processes with time. It does feel right, thought, to start with acknowledging the importance of culture within our team and embrace a flexible and inclusive mindset in order to be effective as a team.

Got feedback? We love feedback! Tweet us, @4C_UX.