The art of presenting a design deep dive in interviews

Some valuable tips and strategies for walking through the design case study during an interview. And how I applied this during my interview for Zalando.

Diving deeper

My design career spans some twenty years now. I must have been involved in more than a hundred interviews (usually as part of the hiring panel!). I’ve seen many changes in how designers make portfolios, as well as how hiring panels want work to be shared. Many 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 two 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 essential — demonstrating expertise in the details of design. Design deep dives are for showcasing the complete process with outcomes and impacts.

A recent real-life example

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:

How they went about identifying user segments.
How many users they interviewed, and why this number?
Some of the findings and insights.
How they translated these findings and insights into the design strategy.

These are crucial parts of the case study which interviewers expect to hear about.

Another recent example (my own)

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.

Dot 1 — Plot building

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:

Explain your involvement and the project duration, also the team size as well as roles and responsibilities. It’s important to acknowledge others to show you are a team player and value collaboration.
Explain the problem. This might be shared in the form of a problem statement, which should cover both what this would mean for users and the business. And don’t forget to mention how you went about understanding the problem and its root cause.
Share any data that supports the current issue/problem. (Do not show this if data is sensitive or you are not supposed to share publicly. Instead, you can just give a high-level overview without showing any data or getting into the details. This indicates that you are aware of sensitivities, and have strong business ethics).

Dot 2 — Explain the research, design and approach to the solution

This is your opportunity to explain how you approached the problem you have established and to provide a clear rationale for your decisions.

Explain why you decided to use a specific design process (e.g. double diamond) and not another. If you do not explain, you can expect this as a question from the interviewer, so be ready to answer. Use this as an opportunity to learn other design processes.
Explain the primary research methodologies used. Again, not just what you did but why you made these choices. Include an explanation of how you planned and conducted the research phase with your rationales. Don’t forget to share the findings and insights (making clear you understand the difference).
Show secondary research. If you have skipped primary research in your project, put your emphasis on this. Cover all the points specified for primary research, plus connect your primary research findings and insights.
Remember, a design without research becomes Art, so make sure these lay solid foundations for your subsequent explanations. Focus on how you translated research findings and insights into the strategy / the steps you followed.
Explain the design phase in detail and focus on strategy, solution and rationales.
Make sure you show important flows/features which connect back to the problem.
While walking through designs, always try to connect back to research findings and insights.
Show and talk about the validation of your designs. Focus on how you performed the test with users to validate your solution and show data around these. Talk about what worked, what didn’t and what you did to fix that.

Dot 3 — Show the outcome

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.

Dot 4 — Show the impact

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.

Dot 5 - Share

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.)

Dot 6 - Be a STAR

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.

Connect all dots and craft a good narrative, and add some personality

It’s critical to show 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, and Deliver. That sets up a structure and allows you to think through the correct time frame for each stage.

Practice

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 important. Then, if you carefully craft your deep dive, you can predict likely questions and prepare in advance. One way to predict is to ask yourself what question you would have asked as an interviewer.

Last but not the least…

… 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 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 could quickly answer their question and demonstrate that I had thought of everything. It was a tight run, 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, whether they are good listeners, If I miss something, how they react, do they show empathy. I’ve always believed that interviewers represent the company's 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 helpful, and maybe I’ll see you on a deep dive for Zalando soon.

* Parking lot (The right tool for presentation)

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, and how you manage your file and design assets.

The goal of this presentation is to impress, rather than inform"

- William Rushton