When hiring product designers, I look for ᴄᴀʀᴅɪᴏ
Interviewing is more of an art than a science. Design portfolios, in theory, are supposed to help with that: examples of a designer’s past work tell the interviewer how good the candidate is.
Except, well, they don’t.
A design is only as good as its effectiveness at addressing some problem. But the problems designers solve are wicked problems — with no clear boundaries or inherent solution conditions — so without a deep understanding of the context, it’s impossible to tell whether a particular design decision was good or bad. Not easy to do in an hour-long interview loop, unless you have a plan.
From STAR to CARDIO
There are two qualities I look for in a designer that can’t be easily gleaned from the visual artifacts: how well they understand the business context of their work, and how effectively they use research to inform their design decisions. To evaluate these qualities as quickly as possible — whether in a live interview or a read-through of a portfolio case study — I start with one prompt:
Tell me about a change you had to make to your initial design that ended up improving it.
In the answer, I listen for six different things. The Context of the work, the Assumptions behind the first iteration, and the Research done to test those assumptions give the candidate an opportunity to show how well they understood the problem. The Discoveries that came out of that research, the Iterations produced as a result, and the Outcome of those changes show how successful the designer was at converting research insights into effective design decisions. Any case study that makes it easy for me to find these things reflects very well on the candidate!
Cᴀʀᴅɪᴏ is my design-specific spin on sᴛᴀʀ, the technique used for interviewing at Amazon (among many other companies), unrolling the Task and Action components to better fit the iterative nature of the design process. Just as with sᴛᴀʀ, the interviewer prompts the candidate with follow-up questions if necessary to help them put their best foot forward.
Context: why did this work matter?
The first part of the story frames the rest of it. What problem was being solved from the user’s perspective? Why did the business prioritize this problem? While the emphasis should be on the designer’s role, the broader details show that the designer understood what they were doing beyond wireframing someone’s solution requirements.
Assumptions: what was the initial hypothesis?
While the first draft is never perfect, it’s a good glimpse into the designer’s thought process. Why did they believe that this was the right thing to design? Did they have ownership — or at least understanding — of the solution direction that seemed likeliest to solve the initial problem or move the right lever?
Research: how was the hypothesis tested?
Feedback loops are the key to the design process. Did the designer seek to disprove their hypothesis, or merely validate all of their assumptions? Were they appropriately rigorous for the scope of the work?
Discoveries: what new things did they learn?
Was the designer able to draw useful conclusions from the data? Even if the initial hypothesis was proven correct, effective synthesis of the gathered data adds nuance and informs further refinements.
Iteration: how did the learning shape their design decisions?
Research is only as valuable as the actions that it drives. Was there conflict with business needs, and was the designer able to use the data to convince stakeholders, or effectively compromise?
Outcome: what was the impact of the decisions?
“The PM signed off on the mockups so I was done” is not success; we are paid for moving metrics that matter to the company and the customer. Tying the design back to the initial objective helps the interviewer evaluate all the other dimensions of the designer’s work: the quality of the initial hypothesis, research, synthesis, and the refinement of the design.
Thirty minutes of Cᴀʀᴅɪᴏ every day
I use these same six dimensions when reflecting on my own work — not just when writing up the case study, but during the process itself, so that I can be confident that I am making good decisions and, if need be, justify them to peers and stakeholders. Am I understanding the business need (or helping the business understand it)? Am I making design decisions based on real data, or repeating assumptions? Are my research artifacts and experiments designed to answer the questions I have?
And of course, the million dollar question: am I able to link my decisions to tangible business outcomes, so that the value of my work is clear?
