The Design Enablement Checklist
A lightweight mechanism for onboarding and upskilling new designers.
Problem Statement
New designers working with software for high-context domain spaces struggle to get up-to-speed without dedicated support.
Solution
A simple figma tool/checklist plus application of the gradual-release-of-responsibility model for upskilling new designers.
Design Process
Scope
listen
Research
literature review
qualitative research
Solution Selection
consider options
draft checklist
Seek Feedback
talk to Users
talk to Stakeholders
Build MVP
the figma 'product'
Measure
assess
Scope
listen
My organization builds software for a very small community of highly trained analysts that work in a specialized environment. As a result hiring and onboarding junior designers can be quite challenging.
New designers must learn a complex domain space, with its own lexicon and customs.
They must also integrate into the organization's community, taking part in rituals and practices that are likely to be different from any place they've been trained in product design practices.
And they must do so while delivering high-quality design work as soon as they are assigned to a product team, typically with minimal oversight.
Many designers I led had struggled to deliver meaningful contributions early in their employment, and our experienced designers often reminisce about their first months on the job in less-than-glowing terms, and remark about how difficult it was to get up-to-speed.
I needed something small, lightweight, and easy to maintain, that would help new designers feel confident that they were acclimating to their new environment and delivering quality work.
Research
Literature review
The product designer guides, books, and handbooks that I considered recommending to new designers felt poorly targeted and unwieldy in their application.
Qualitative research
I interviewed a designer within the org who had been paired with several new designers over a span of years and synthesized her observations about what made a designer easier or more difficult to onboard successfully.
Solution Selection
consider options
There were several ways to solve this problem. We considered adding additional courses to the "onboarding" period when new employees are getting introduced to the organization, having design leaders check in with new designers every day, and several other (even less viable) options.
The one we settled on trying first was simple:
1) Exclusively add new designers to teams that already had one experienced designer.
2) Give them a simple list of activities we expected them to master and have them practice the "gradual release of responsibility" model.
draft checklist
I rattled off the first list of general practices we follow in a few scattered patches of time between meetings as a checklist in a google doc. I thought I had an MVP.
Seek Feedback
The framing practices I settled on during my first attempt were not especially rigorous, so I wanted to make a point of doing an additional round of research to see how the product I'd built would be received.
talk to users
I spoke to the designers who were most likely to be paired with a newly incoming designer and asked them for feedback. They loved the idea, but also I was literally their boss, so we were facing the HiPPO problem at its most blatant. They had no feedback about how to improve it or whether anything was wrong.
talk to stakeholders
I got some time on the calendar of our design practice lead and explained the problem I was facing, then showed him the document. We spend some time pairing in a whiteboarding application, re-focusing certain sections, extending and shortening others.
In the first session we mostly focused on content, and at the end of it, it was hard to see value -- we had changed a few words and the number of tasks, yes, but we had moved from my nice, clean checklist to pile of digital sticky notes that wouldn't be easy for incoming designers to use as a product--I wanted something clear and simple that gave someone confidence that they were on the right path, this wasn't it, yet.
Build MVP
A subsequent session with the design practice lead yielded what I was looking for --
the figma 'product'
My design pair suggested we build it out of components from our own design system library in our shared-resources Figma directory, which gives it a very specific feel and means working to update or adjust it actually helps the user get more comfortable with our design system components as they go.
The checklist is simple, clear, easy to find, and easy for our designers to fork, remix, and adjust to meet their individual needs.
(click to enlage)
Measure
A product like this is just an output, without some method for measuring the usefulness of the tool, we can't know if it's contributing to our outcomes.
Assess
I started with two design pairs using this new product now as a daily practice. I received early positive feedback and made a few tweaks, but the real proof-in-the-pudding came at the end of 2022, when the first couple of novice designers that were using this system reached the end of their "onboarding" period and started working independently.
The results were excellent. And the more closely the designer had stuck to using the system, the easier it was to quickly work with them and get them up to speed on another practice that wasn't covered by the checklist.
The designer who most thoroughly engaged with the system was ranked higher in job performance for that period than any other incoming designer when we submitted performance ratings at the end of the year.