On design tasks
Yesterday morning, whilst sitting blurry-eyed in a train from France to the UK I noticed the revival of a design topic on Twitter that I find interesting: Design Tasks. The exercise of giving design position interviewees a task as part of the interviewing process. They are a bad idea for a number of good reasons, but I’ll outline some of my own here in more detail than Twitter discussions will allow.
I won’t aim to pick apart Monzo’s process here, as it’s indicative of a growing norm and the design team there probably see this as aligning to it. What I want to explore here is why is this happening, and what can we do to stop it?
Peter Merholz and Kristin Skinner wrote in their book, Org Design for Design orgs, the following regarding design tests:
A topic of some controversy within product design circles is whether candidate interviews should involve some kind of design test or challenge akin to what happens in engineering interviews. Our firm, resolute response to this is “no.” Design tests set up an unhealthy power dynamic in the interview environment, when instead you should be fostering collegiality. The context in which the challenge is given (typically narrowly time-boxed and with only a little information and little support) is wholly artificial—and so whether a candidate succeeds or fails is not a meaningful indicator of actual practice. There is nothing you will find out in such a test that you couldn’t better learn through probing the candidate about their portfolio.
In 2018, another lengthy thread sprung to life on Twitter between Jared Spool and others, and then again a couple of days ago. It’s probably happened a bunch of times in the intervening days and months, too. Like spec work, this topic just won’t go away. And, like spec work (and Brexit for that matter!), I feel we have to understand the decisions people make – however much we disagree with them – to respectfully attempt to change their position.
Peter also wrote a couple of years ago the reasons he feels these tests do not work. I agree with all of them. But I’d like to add some thoughts and suggestions on how we can make it better.
Why are design tests bad?
I asked this on Sunday. My first comment was framed so that designers might try to understand what we might not be doing well that we could do better. A better portfolio, supportive material in addition to case studies, for example? My subsequent tweet was aimed at organisations. Why do they feel that design tasks are useful and appropriate?
They indicate a wobbly stool
We’ve heard about the three-legged stool of product. Each leg representing design, engineering, and product. Personally, I think there’s another leg: research. I agree with Peter that design tasks originate in engineering:
I can’t say for certain, as I haven’t done the research as to where design exercises emerged as an interviewing practice (it’s not from traditional design practice), but my guess is that they came about in technology companies where software engineering was the dominant practice. Design had to overcome its perception as squishy, soft, “make it pretty,” by demonstrating rigor, relying on data, and generally making the practice of design operate more like engineering.And engineering hiring interviews involve technical exercises (coding challenges and the like), so shouldn’t design hiring interviews?
This makes sense. Critically, though, it shows a lack of understanding of the differences between engineering and design. In an engineering-led culture, design tasks are normalised because similar tasks are normalised for engineers. But the methods by which these over-simplified tasks are accomplished differ enormously from discipline to discipline.
A process the org understands
I get this. I really do. Assessing the talent, potential, and skill of a designer alongside their manner, personality, and aptitude is a difficult job. One that takes many years to become good at. So, when you have an organisation that is scaling quickly, or a team that is small and functional but outgunned by engineers 20 or 30 to 1, then time and experience is incredibly precious.
In these environments, senior design leaders are often not involved in hiring directly. They are involved with managing upwards and laterally. Socialising changes in organisation direction. Influencing outcomes. Leading product strategy. The very people who have the experience to very quickly assess and judge design talent will not be in the room. So organisations need a process that will enable less experienced team members across teams or organisation to make decisions. Often, these people are not designers.
A design task is the answer to this problem. It’s simple. Easily understood. The results can be judged on face value. But, just like NPS and other data golems, just because it’s simple and understandable doesn’t make it a good idea.
Design tasks are spec work
Spec work is bad. No ifs, buts, or exceptions. The continued practice is damaging to the profession. As the son of an architect I’ve seen first hand the exploitation of businesses small and large by design competitions and speculative proposals. In architecture, that ship has sailed. And, for a while, it was looking pretty good for this industry too. Design tasks are a step in the wrong direction. Nobody should work for free for a potential job. Just because it happens elsewhere doesn’t make it right.
How can we do this better?
We can do better. In fact, we’ve been doing it for decades.
For organisations hiring designers
I hope it goes without saying that you should not include a design task.
- Set expectations. I admire Monzo for their openness. I wonder, though, if this process was transparent for every applicant or this is a retrospective piece. Regardless, an organisation should be transparent about what it expects from a candidate and the commitment and timescales involved. This needs to be up front and the candidate needs to know where they are every step of the way and what to expect next.
- The power does not sit entirely with you. The interview process is a tricky balance, especially early in your career when you might not have the self-belief or confidence to view them as an opportunity to interview your potential employer. Design tasks go a step further in unsettling this power balance. By setting a task, you are now testing the applicant. Not only that, but you are doing it on the back of a poorly conceived tool.
- Portfolio review. An experienced designer must review a portfolio. Even if the portfolio is comprised of many written case studies and few pictures, it demonstrates an applicant’s ability – either visually or less so. Certainly for visual/UI positions, it’s a must. As a person doing the reviewing, I know this can be a tiring and time-consuming prospect. But, it’s your job ok? Your job is screening for quality. Your job is to be present in the recruitment process. A design task cannot do this. Junior members across a team cannot do this.
- Structured interviews. As I said, assessing skill and design craft is something that is hard to articulate and scale across an organisation. It’s also really hard to compare one designer to another for the same role if the portfolios are very different. This is what the design task aims to do: level the playing field on something that can be cross-compared. But we can do this with semi-structured interviews, in the same way we conduct user research. As a hiring team or manager, it’s critical you articulate what you need. From that, you can design questions that can tease out insights from candidates and you are able to then cross compare them.
- The right people in the room. Please, please get the right people in the room to ask questions. This includes the senior designers, and people who will work with the applicant on a day to day basis.
For individuals interviewing for design roles
- A collection of stories. Make your portfolio a collection of case studies and stories that you are extremely familiar with. You should be able to talk confidently and excitedly for up to 45 minutes and hold a room captive. They should stand up to scrutiny. You should be able to deftly engage in critique with your interview panel. This is your work. Feel proud, excited, and engaged.
- Be honest about your involvement. If you didn’t do something, say so. If you document a whole case study about a product of which you only designed the onboarding, then just document and explain the onboarding. A good interviewer will understand and thank you for this. The quality of questions, and therefore your answers, will be higher.
- An equal process. You are also interviewing your potential employer. Aim to move towards frank discussions of things that concern you. Ask for reassurance. Hold your interviewer to account. Know your worth.
Design tasks are a symptom.
They are a symptom of a culture imbalance. They are a symptom of a wobbly stool. Of design leaders who don’t have time for design. Of a quality vacuum. They are a symptom of a broken recruitment process and of organisations that prefer applicants who have time outside of work to conduct the tasks, regardless of their personal circumstances.
UPDATE: 15:11, 24th February.
Andy posted a few thoughts on my post. Andy is right, of course, as a designer working in-house as part of a large, complex organisation, it’s difficult to pin point projects and write about or display them in a traditional portfolio – the type you’d expect a graphic designer to have. So, I suppose, it would be useful to define what I mean by portfolio.
As I said above, to me, a portfolio is a collection of stories. This may be visual. It may not be visual. I’m of the belief that design is a broad discipline and you can be a great designer without going anywhere near Figma. Certainly, the more senior you become, the less hands-on ‘traditional’ graphic design you might do.
A successful portfolio demonstrates that design is a problem solving activity set within the context of user and business need. If you can frame a problem, articulate the problem solving journey, and demonstrate your response – be it visual or otherwise – this is a valuable part of your portfolio. I’ve hired quite a few designers over the years who I’d class as excellent lateral thinkers, problem solvers, or writers with relatively average graphic design skills. Equally, I’ve hired designers where I spotted raw visual talent but they needed a lot of work in other areas.
Tags that this post has been filed under.