Product Design Roles v3
Just over a year ago, we posted a major overhaul of our Product Design Roles documentation. With that revision, we aimed for our role documentation to facilitate more actionable discussions between managers and their teams, set clearer expectations for each level, as well as help our designers and design managers set better goals. And while we’ve gotten a lot of positive feedback from our team over the past year, we’ve also noticed a few holes and areas we could improve our documentation. After going through a couple of performance review cycles and running our now-annual Product Design Offsite, we had the feedback we needed to evolve our documentation.
What We Discovered
No one knew how to get promoted. While the documentation was pretty solid for understanding the expectations of each level once you were there, there was no guidance for designers on which skills we felt were must-haves for promotion. Even amongst the managers, there was disagreement about which skills were most important and when a designer was ready to take on more responsibility.
Some of the language was unclear. In the past year, we’ve begun doing an exercise with the Product Design team (designers and managers both) that we call Calibration. We make a spreadsheet with every skill from the role document listed, and ask each designer to indicate what level they think they’re at for each skill based on the existing documentation. Separately, their manager also fills out a duplicate spreadsheet about that designer from their perspective. And then, the designer and manager get together and compare their results side-by-side. If that’s confusing, here’s what it looks like in practice after both designer and manager have combined their spreadsheets:
We’ve found this to be an amazing tool for ensuring managers and their team members stay aligned, as well as for sparking interesting conversations when there’s misaligned perspectives. We found while some of the misalignments were simple disagreements, we also found that our documentation, at times, lacked clarity and created different perceptions of what the document even meant.
There were some skills we clearly cared about day-to-day and at review time, but had failed to cover. For instance we covered writing, but no other forms of communication (cue forehead-slap). Or we covered running quantitative experiments, but it turned out a lot of designers were running their own qualitative studies (and we just hired our first full-time User Researcher!). But the overlap between the two types of data and expectations for how designers gather and work with data were not represented at all. Yet we talked a lot about these things all the time!
Organization-specific language was old and outdated. We had a lot of terminology in our role document that was specific to how we were organized at the time we wrote the doc. Terms like “councils” or even “groups” and “squads” turned out to not be durable enough and had stopped making sense entirely based on how our department had evolved.
What We Did
We’ve cleaned up a lot of the wording and even rewritten entire skills to make the expectations clearer than ever before. We’ve removed all org-specific language, and added new skills (and combined a few) to cover all of the things we expect from designers.
Additionally, we’ve added clarity around which skill is a requirement in order to get promoted for each level. In the final document, you’ll find asterisks next to certain skills at each level. When we’re talking to designers about what they need to work on to pursue promotion, we use those asterisks.
Finally, we’ve moved our role documentation (and will be moving more of our documents soon) to Github! This allows us to open Pull Requests against our existing document, make changes and share those changes with the team prior to finalizing and merging it in. We’ve made the repo open and attached the GNU Free Documentation license to it so anyone can grab the docs we’ve made and use them however they want.
FAQ
What about the manager roles? Good catch! We haven’t tackled the manager roles, though that is my very next step and coming soon! The designer roles impacted the most people on the team and were most in need of adjustment, so we chose to start there.
Doesn’t this raise the bar? I was talking to Sabrina, one of our amazing design managers, about the possibility that changing this document could be perceived as moving the bar on people. She replied that, from her perspective, it wasn’t the bar that had changed, but rather our ability to articulate where the bar is. In other words, this new document reflects what we’ve always considered the expectations for the Product Design team, but in a clearer way than we’ve been able to before now.
Will you revise this every year? That’s the current plan! As we use this new document more, we’ll be learning its strengths and weaknesses, and will think about what the next iteration should cover sometime next summer after our yearly Product Design Offsite.
What other documentation will you release on Github? We’re planning to transition all of our recruiting and design process documentation to this repository. We’ll be making more announcements as we flesh out the structure there. This is definitely just a first step into a much larger world.
We’re super excited to have this document for our team and, as always, to share our documentation with the entire design community. Hit us up in the comments with any questions or thoughts. We’d love to hear them!
