A Framework for Building a Design Practice
Don’t just do design, practice it.
For the better part of the last 5 years, I’ve spent my time leading and building design teams (with Jet Cooper for the first 4.5 years, and more recently with Shopify). However, it wasn’t until the shift from co-founder to director of design (a role that enabled me to focus and double down on my craft), that I was really able to articulate what it truly meant to build a design practice. As such, this article represents the set of ideas, thoughts, and opinions that have accumulated through my experience of building effective, healthy, and happy design teams. I hope you find it helpful.
But First, a Quick Story
In early 2009, Satish and I set off to start Jet Cooper. For the first 4 months there were just two of us (Satish brought in all the work, I did all the design and development). From there, we grew steadily from two to four to eight to ten over the next year or two. It was a glorious time: we came in every day and for the most part, huddled together and figured out what we had to do that day. It was a perfect reflection of raw creative chaos and the luxury you had as a small and nimble team.
Before we knew it though, we grew larger and things started to break. Our daily team regroups were becoming overwhelming, team members started becoming more isolated in their projects, consistency in work quality was harder to sustain, and it was simply harder to keep everyone on the same page.
Looking back, there was an important lesson here: when you’re small enough as a team, you can show up every day and just wing it. But beyond a certain threshold, you need to start modelling things to sustain your success. Our magic number was 10, but this can vary between teams.
This is fundamentally why it’s important to build a practice. Without a practice, you’re just doing design — a short-term activity. But when you practice design, you’re focusing on long-term sustainable success.
A strong design practice should therefore be:
- Scalable: it enables you to integrate new members into the team seamlessly
- Repeatable: it ensures great work isn’t a lottery
- Autonomous: it removes the dependency on gatekeepers
- Intentional: it ensures decisions aren’t made arbitrarily
- Transparent: it is clear and accessible to everyone in the company, not just the design team
Components of a Design Practice
Okay, so we’ve established what it means to have a practice and why that’s important. Now let’s make things more practical.
When I talk about building a practice, I refer to 3 tangible components:
- Production Model
I could spend days talking about each of these in detail (trust me, I have), but for now, I’ll discuss them at a high level.
Consider the tools your team uses to facilitate collaboration, communication, decision making, project management, and other activities. For example, we use tools like InVison for design reviews and Dropbox for file management, among a few other standard tools.
Identify what you need to accomplish and choose the best tool for the job. I’ll warn you now though: choosing tools is not always a rational exercise. But as you’re doing it, it’s important that you consider how tools integrate with workflows, how they’ll scale with your team, and also what their financial impacts are. These factors will determine the success of adoption of any given tool.
2. Production Model
The production model is what I call the system of techniques you employ as a team to conceptualize, produce, and ship great work in the trenches of your projects. This is not a trivial task: it’s not as simple as throwing talented people into a room and hope they come out with great products.
How do designers on the same project work together?
How do they integrate with other disciplines (front end development, engineering, product management, research, data, copy)?
How do activities change and adapt through the life cycle of a project?
You need to think through all the mechanisms that contribute to a well-oiled problem-solving machine.
Some of the things we do include:
- The focus model: everybody works on a single project at a time.
- Project pods: projects are assigned cross-disciplinary pods that are composed of at least one product manager, one designer, and one developer.
- Physical proximity: our seating is arranged by project, not by discipline.
- Start and end together: we minimize stagger by starting and ending PMs, designers, and developers on projects at the same time.
- Demo days: once a week, the pod takes a step back and reviews the product holistically.
- Retrospectives: periodically, the pod conducts a retrospective to identify challenges and develop new experiments to improve process.
These are just a few things we do at a macro level, but there are plenty more (crazy eights, storyboarding, groupboarding, etc) — and they all vary by context, team, and project. Find techniques that work best for your team, and continue to think about them actively. The process is the product; how you work is just as important as what you work on.
Rhythm deals with everything that you do as a design team that builds and maintains the momentum of learning, sharing, and collaborating as a discipline (independent of any one particular project). We maintain our design rhythm with:
- Dailies: designers across the team post work-in-progress at the end of each day to InVision for review by their pod, designers working on related projects, and myself.
- Fresh eyes: peer reviews happen twice a week to not only build rapport between designers, but to facilitate feedback cycles with fresh perspectives.
- Design talks: once a week we gather as a design team to do show and tells, mini field trips, or simply talk shop.
While the production model addresses how we solve problems more effectively as project pods, thinking about rhythm helps us continue to develop holistically as a design team.
To summarize, your tools, production model, and rhythm are 3 critical components of your design practice. Dissect them, put them under a microscope, and keep strengthening them over time.
It’s not uncommon to talk about building culture as a loose and ambiguous concept. However, the fact of the matter is that you cannot build culture directly. Instead, it manifests out of the things you tangibly do as a design team.
In other words, it’s from our ongoing work on the components mentioned above that our design culture gains definition.
Culture is critical to the health and happiness of your team. It’s far less tangible than tools, production models, and rhythm, but holds greater weight on your ability to sustain success over time. And while you can’t build your design culture directly, you can in fact measure the health of it. You can do this by observing your team’s ability to have:
- a common language with which to discuss design
- a mutual respect for each other’s strengths
- a shared responsibility for each other’s work
If you’ve achieved all of these things, you’re probably running a very healthy and happy design team (bravo!). If you’re lacking in one of these areas, you can address it by examining one of the components of your practice.
Said another way, having a strong practice (and in turn, a healthy culture) breeds resilience. And in my opinion, the teams that come out on top are the ones that measure their success not by how often they’re right, but by how resilient they can be when they’re wrong.
If you’re leading a design team, you’re accountable to empowering your team to do their best work. There’s no better way to do this than to stop simply doing design, and start practicing it.
This is an ongoing body of work for me and I always welcome new observations and opinions that stem from experiences other than my own. If you lead a design team, don’t hesitate to get in touch.
If you’ve found this helpful, please recommend and share with loved ones.