When any new hire starts at Drift, they’re handed a stack of cards containing our leadership principles. One that stood out on my first day and still resonates strongly is principle #8: Be a curious learning machine.
So, true to this principle, I found myself reading one of the books on our company’s book club list – a list of books provided for free to everyone in the company.
The Talent Code by Daniel Coyle describes “talent hotbeds” that produce a statistically unlikely number of world-class individuals in a given field – Florence from 1300 to 1600 in art, the Dominican Republic in major league baseball or the Spartak Tennis Club in Russia for women’s tennis.
These hotbeds share a surprising number of characteristics. One of them is that individuals and coaches from these hotbeds all participated in a method of improvement called deep practice. Coyle describes deep practice like this:
Struggling in certain targeted ways – operating at the edges of your ability, where you make mistakes.
But I’m a product designer, not a tennis player…So how does deep practice apply to my field?
If you’ve ever worked in a company with a design team greater than one, I bet you’ve spent time thinking about design systems. As design leaders, we’re obsessed with design systems. More accurately, we’re obsessed with finding a scalable way to make our UIs both consistent and high quality. And we look at design systems as the way to achieve this goal.
Easy enough right?
Build the system, designers will use it and voila, consistent design. Well, no, not really. Every design system I’ve worked on (through my career at TripAdvisor, UpServe, LogMeIn, LastPass and now at Drift) has struggled in the same way. We build it, we publish it in a sweet PDF (now we’re cool and use InVision DSM), we give a presentation to the team and then…nothing. People continue to design and develop in the same way they used to.
That’s because as a design leader, I was missing a key component – practice. Practice is what makes a system stick – because it takes time and skill to use a system. There is no design system in the world that is thorough enough to ensure it will be used correctly.
Unless you practice.
Why did I avoid practice?
First excuse:
It feels awkward for a design leader to ask your highly sought after, highly paid, oh-so-valuable-please-don’t-leave-us-for-a-new-startup designer to practice designing.
Well guess what design leader…best-ever in the world basketball player Michael Jordan practiced all the time. So does every other world-class athlete, musician, speaker, leader. Just go ahead and google “[your hero’s name] quotes about practice” and I bet you’ll find some good ones.
Andre Agassi has a good one, so does Michelle Obama, so does Pablo Casals, so does Arnold Palmer, and Serena Williams’ is great. Those people never felt too good to practice and neither should we!
Second excuse:
It’s difficult and scary to give specific feedback to each designer when they practice.
Well, this is where you need to start practicing yourself. Your goal? Become a master coach. As defined by Coyle,
Master coaches are the human delivery system for the signals that fuel and direct the growth of a given skill circuit, telling it with great clarity to fire here and not here. A coach’s true skill consists not in some universally applicable wisdom that he can communicate to all, but rather in the supple ability to locate the sweet spot on the edge of each individual student’s ability, and to send the right signals to help the student reach toward the right goal, over and over.
As a design leader, this is your job – learn to love it and then spend a lot of time on it (ahem, practice). I do mean a lot. You are going to have to look at, evaluate, zoom in to 256,000% and give specific feedback down to the hex value and pixel about exactly what to do and not do to meet your standards. This is not the time to pull a punch – clarity does not equal cruelty.
Enter the DDCC
So at Drift, we’re following in the footsteps of other world-class organizations by practicing. Coyle says we’ve got to:
- Observe the task as a whole (in our case, create a design system and show what ‘good design’ looks like)
- Break things into small chunks and practice them separately
- Repeat and be mindful when it goes well
I’ll dive into how we follow through on step 2 with our weekly practice habit. We call it the Drift Design Consistency Challenge, or the DDCC for short. It goes like this:
1. Each Monday, I post a challenge due Thursday at 3 PM
These are small pieces of UI to update, new components to add to our design system or design briefs for new layouts.
2. Each Thursday I receive all the sketch files and start recording videos
This video feedback I provide is anywhere from 5 to 15 minutes per designer where I’m going through the sketch file. I’m measuring distance, checking colors, showing off the pieces of the system that they missed and, above all else, making corrections.
Corrections are short, almost staccato in nature. I try to avoid words like “I think…” or “Maybe you should…”. This is a place for clarity of my expectations. Often times I also create the file to show exactly what my expectations are.
3. Designers watch their video and practice using the feedback
If they missed the mark, they need to recreate the file to meet the standards I’ve set for them. Otherwise, they only need to mindfully watch and make adjustments to their file. Sometimes we figure out a flaw in our design system or component usage guidelines. In these cases, we discuss any updates that need to be made to the design system during design critique the next week.
4. Repeat
Over and over again, we repeat this process. And you know what? We’re getting really good at it. Each week I see results that are more consistent, more thorough and higher quality than the last.
More so than any design critique, any usage guidelines post or any PowerPoint deck I’ve used to ensure consistency and quality – I‘ve found that it’s deep practice that’s key.
So what can you do?
If you work on a design team, or any team that needs to collaborate, ask yourself “How might we practice our skill?” Maybe you’re a front-end development team that needs to implement a design consistently. In that case, why not practice tearing down a design into components? Or practice naming components semantically. I wonder if every front-end developer at Drift would choose the same class names for a new component. Hmm ?
If you’re a product manager, practice writing a project brief (or one-pager or whatever your organization calls these), a ticket or running a kickoff.
At Drift, our product team has started to practice mock downtime incidents to improve the speed and clarity of the team responsible for fixing the service. The result? A drastic reduction in service downtime once an issue is identified.
So think about how you can practice your skill set and how your team can practice working together. Just ask MJ – it’s worth it.
Or, better yet, come join our practice-obsessed culture here at Drift. The design team is expanding! We’re hiring a Product Designer – get more details and apply here. Or learn about life at Drift here.
