by Sunil Shrivastav
Some useful tips and strategies for walking through the design case study during an interview. And how I applied this during my own interview for Zalando.
My design career spans some twenty years now. During that time I must have been involved in more than a hundred interviews (usually as part of the hiring panel!). I’ve seen a lot of changes in the way designers make portfolios, as well as how hiring panels want work to be shared. Lots of mature design companies have started eliminating design tests, focusing instead on detailed portfolio walkthroughs. At Zalando we call these design deep dives. Candidates are expected to present 2 detailed case studies from their work to help interviewers better assess their depth, skills, style and overall professional fit.
Some candidates come up with a beautiful narrative, while others present what feels like fragments of information that don’t quite fit together. Yet one consistent pattern has emerged from interviewing. And that’s that designers are focusing principally on What they did in the project, the outputs, rather than the specific outcomes. Which means they really only skim across the surface of the story. We call it a deep dive for a reason. If you just focus on outputs you haven’t told a story, and more critically you haven’t shown us how your mind works, or Why what you have done matters. In addition to the why, the How is important — demonstrating expertise in the details of design doing. Design deep-dives are for showcasing the complete process with outcomes and impacts.
Myself and a colleague were recently interviewing a designer with 10 years of experience. They were walking us through a case study, and showed us a slide with some post-its, they explained that they did user research and then explained why. The next slide? Straight into prototypes.
So what happened here? I personally was excited to hear why the candidate decided to do user research. But then they failed to go beyond this, leaving out how the user research connected with the prototypes in any meaningful way. There was no depth, and no coherent narrative thread between a discrete series of events. It was mostly about the What (outputs), and failed to engage on the How and Why of what happened (outcomes and intentions). Here’s what we might have hoped for from an experienced designer:
These are crucial parts of the case study which interviewers expect to hear about.
How do I know all this? We’ve all had our fair share of failures. Myself included.
A few years back, I was being interviewed and needed to present a case study myself. After the interview, I realized that I’d missed a few crucial parts in my presentation. This made me even more conscious of what’s essential when interviewing. And then, a few years later I had my big opportunity to put this into practice.
In late 2019, a friend of mine joined Zalando’s tech team. Shortly afterwards he called me to say: “you belong at Zalando”. I was intrigued, of course. We’d worked together before, and he knew what was important to me as a designer. He talked about the company and products and constantly discussed the culture, team, and processes — and how Zalando put users’ problems at the centre of the design, and how the rest falls in place. This sounded like something I wanted to be part of, and in 2021 I had my chance to apply.
I did lots of research, and once I understood the company, one thing was clear: I needed to carefully craft my case study and communicate the right balance between a thought leader, strategist and designer. Drawing on my own experience of the failed deep dive, I took the opportunity to create a framework for myself. I shared this with a few of my designer friends, who assured me it worked. I named this framework ‘dSix’. It has 6 dots which cover what I felt I needed to share in my design case study. And for deep dives, it meant I could connect all the dots and build a solid narrative focusing on outcomes and impact.
This sets the scene for the story, and allows you to show you understand the bigger business picture. This should include an explanation of what the project was about and why it was needed, as well as what you did to understand the business domain. Having set the scene, you can start to share your involvement:
This is your opportunity to explain how you approached the problem you have established, and to provide a clear rationale for your decisions.
Once you’re done with Dot 2, take a step back and mention the problem statement again, connect with research findings and insights, and narrate how your solution will solve the problem for users and the business. But, again, plan this so it only takes no more than 2–5 minutes.
If your solution is live, try to show the data around adoption, how numbers have been impacted, how the solution has a positive impact on users and the business. If it’s not live yet, still try to anticipate the adoption and impact once it goes live. You can share data from testing, which shows how users have reacted to the new solution.
Always share learnings/challenges/failures. Don’t be shy about acknowledging failures. It demonstrates that you have an open and growth mindset. (You might want to wait for a question around this and then answer. Acknowledging mistakes is a great way to engage on a human level and potentially more convincing than a sanitized version of your story.)
When explaining challenges and how you solved them or answering interviewers’ questions, you should use the STAR method (Situation, Task, Action, Result). It helps you to make your case stronger and assists interviewers in decision-making.
It’s critical to show that you can think and explain things on multiple levels. I know you might be thinking, oh my! So many things to remember. I only have 30 minutes! But I can assure you it is achievable. Projects are generally divided into these stages. Discover, Define, Design, Deliver. That sets up a structure, and allows you to think through the right time frame for each stage.
Do a dry run 2–3 times before you present. This can help you time things, which you can adjust to be sure you can cover everything that’s important. Then, if you carefully craft your deep dive, you can predict likely questions and prepare in advance. One way to predict is just ask yourself what question you would have asked as an interviewer.
… how I put this to work in my Zalando interview. I received the schedule in advance from the Zalando recruiter, indicating that the design deep-dive would last 90 minutes, and should cover at least two case studies. So I formed a plan allowing 30 minutes per case study, with 30 minutes for Q&A. I then restructured my case studies according to my dSix structure. This involved reducing a lot of material, but my method provided a rigorous discipline for doing this: Dot 1: 5–10 minutes, Dot 2 and Dot 3: 20 minutes, Dot 4: 5–10 minutes. Dot 5 I decided to leave for the Q&A, and Dot 6 I managed to cover for both case studies during the 90-minute session.
My structure helped me to decide what to show and what to skip; what to highlight with my narrative; and what to leave in the parking lot*. I’m glad I had this, as one interviewer asked a question that wasn’t in my case study during the interview, but I had it in my parking lot. I was able to quickly answer their question, and demonstrate that I had thought of everything. It was a tight run for me, and the clock was always running in my head during those 30 mins. It creates much anxiety, but trust me, take a deep breath and start.
Yes, there’s a lot of pressure, but remember interviews are for both sides to decide if there’s a good fit. I constantly research the company to understand what to expect during interviews. But I also closely observe the interviewers. I note what kind of questions they ask, are they good listeners, If I miss something, how do they react, do they show empathy? I’ve always believed that interviewers represent the company culture and maturity. While going through the interviews with Zalando each round amazed me — the panel, the questions they asked, and that they didn’t shy away from showing they appreciated my work. This is something I hadn’t experienced in the 20 years of my career as an interviewee!
I’m happy to say that I joined Zalando as a Principal Product Designer. I hope my story and methodology are useful, and maybe I’ll see you on a deep dive for Zalando soon.
I have been asked so many times how to show a case study. There is no one right way. It depends on what you are communicating and how you want to communicate. I have seen presentations in PowerPoint, pdf, live product walkthroughs and raw design files. That’s great, but interviewers are also interested in your creative execution and managing side. So I prefer showing everything in one design file (mostly Figma in presentation mode), and It’s okay if it’s a bit raw as long as you can communicate and engage the interview panel with your story. It’s good. It’s essential to show your raw creative side, all explorations, how you manage your file and design assets.
- William Rushton