How to Present a UX Case in an Interview to Secure a Job Offer

Hey, everybody! My name is Kirill Seibel, and I’m a UI Director at G5 Games, a mobile game developer and publisher. Over the years as a design manager, I’ve had the opportunity to interview many talented designers who can solve complex problems, work in teams for a common cause, overcome challenges, and achieve outstanding results. However, hundreds of hours of interviews later, I can confidently say that most of these undoubtedly talented people are catastrophically bad at presenting the results of their work. During case presentations, the designers will do anything to confuse me and not get the job:

• They voice what is already visible on the screen (“If the user clicks here, this menu opens…”);
• They forget important facts (“It was so long ago that I don’t remember exactly…”);
• Making excuses (“It could have been done better, but the team let me down…”);
• Avoiding specifics (“We had some problems, but we made some effort and got through it…”);
• Going into unnecessary detail (“I moved the icon not by two pixels, but by four pixels…”);
• They talk not about themselves and their role but about an abstract team (“We made a decision…”).

If you recognize yourself or someone you know, you may be interested in my perspective on presenting UX cases during an interview. I will tell you:

• What I, as a hiring manager, expect to hear during the presentation;
• What I pay attention to during the presentation;
• How to prepare and deliver a killer presentation that will leave the interviewers with no questions;
• And, as an exclusive bonus, how to ensure you fail and don’t get an offer.

What is a UX Case Presentation

More often than not, you will have to talk about your work twice during your job hunting. The first time is when you submit your portfolio. The second time is during a face-to-face interview with the hiring manager.

The UX portfolio is the icebreaker that has to open your way into the interview. Its job is to grab attention and explain the essence of the project in a nutshell. In the context of a job search, it’s your elevator pitch. The people in charge of hiring designers get dozens, sometimes hundreds of responses every day. They don’t have time to study every case in detail. That’s why the cases in a portfolio need to be short, clear, and impressive.

During the interview, you will be required to do something different. You need to be able to express ideas, solutions and the process in a clear, coherent, and concise manner, navigate the presentation material, and the subject matter, draw lessons, and conclusions, hold your audience’s attention, and be confident (or pretend convincingly enough).

Without further ado, let’s look at how to achieve this.

Preparing

There is nothing worse than coming to a meeting unprepared. For me, it is like a nightmare when you are called to answer on the blackboard in school, and you are not wearing trousers. Confusion, shame, and panic are what I feel before I wake up in a cold sweat. I don’t know about you guys, but I don’t like experiencing these feelings.

To avoid this, stick to some simple tips:

• Set a clear goal;
• Gather and carefully check your facts;
• Prepare a presentation;
• Prepare answers to questions in advance;
• Rehearse, rehearse, rehearse.

Set a Goal

“What’s so stupid, mate,” you’ll say, “It’s obvious that my goal is to get the offer!”

Without going any further, you’re absolutely right. But let’s be specific from here on. What offer? What is expected of you? What is your benefit?

If you are going to work in a start-up on a product that helps people with special needs to learn foreign languages, then showing your best promo page might not be the best idea.

Here are some questions to ask yourself before you go into the dragon’s cave:

• What company am I interviewing for? What does it do? What does it make its money on? Who are its customers?
• What product will I be working on? How and what problems does it solve?
• What kind of team would I be working in? What is valuable to them? How do they work?
• What position am I applying for? What is required to do in this position?
• What does the hiring manager expect to see?
• How can I be useful? What strengths do I have? How can my strengths benefit the team, the product, and the company?
• How can I show all this through a case presentation?

The answers to these questions will determine which case you choose to present and what you emphasize.

Let’s say you are going to work in a start-up on a product that helps people with a physical disability to learn foreign languages. You are applying for a job as a junior designer. You have some experience as a freelance UX researcher. And you know that there are no UX researchers in the product team yet.

Why not then focus on a project during your presentation where you’ve contributed to improving accessibility? Delve into how you conducted the research gathering information from open source, recruiting respondents, conducting interviews and usability testing. Show how you listened carefully to your mentor’s advice, and worked hard to learn new practices, methodologies, and processes (in short, being a junior designer they can only dream of).

Gather and Verify Facts

We, designers, are experts at finding information and answering difficult questions. What could be worse for a designer’s pride than to find yourself in a situation where a stakeholder asks a difficult question, and you don’t have the answer at hand? It’s like finding yourself in a boat that has sprung a leak, and you don’t have any tools to plug it. You’re drowning and panicking.

Let’s say you’ve set yourself a clear goal. Choose a suitable case. Figured out what you want to emphasize during the presentation. You could say you’ve built the framework of your ship… It’s a good time to do some solid paneling in the form of verified and carefully sorted facts.

For example, you want to talk about how you have improved product accessibility. Then, it’s time to remember exactly how you did it. How exactly did you realize that accessibility was important for the product? What exactly were the accessibility issues your users were facing? Did they have mobility issues? Or visual peculiarities? How did you design for these users? What was the basis for your solutions? How did you test the solutions? How exactly did you realize that your solutions benefited users and the product?

Collect quotes from interviews with users. Find product metrics. Get the most relevant layouts. Make sure your information is real and true.

Prepare Your Presentation

OK, half done! At this point, you already know what cases you are going to talk about, what you are going to emphasize, and what ironclad facts will make your story compelling.

Now, your case needs a strong structure: Context → The task → Your role → The work process and design solutions → Challenges → Achievements.

1. Start With the Context

This may come as a shock, but more often than not, the interviewers know nothing about the product in your case study. Therefore, it would be very kind of you to say a few words about the product in general before getting down to business. What’s the point of it? How does it benefit its users? What stage of development is it at? What challenges does it face, and how is it developing?

Example: “I’ve been working on Launcher X. It’s a desktop application that integrates all of CompanyX’s apps, and allows you to keep track of game events and make in-game currency and item purchases. It gives players the ability to manage their games in one place and keep up to date without logging into the client. The Launcher has a long story. So it has accumulated visual, UX, and technical issues.”

2. Describe the Task

It’s time to move your story forward!

Tell us about what made the business turn on the bat-signal and call in the highly skilled product designer in your person. Maybe a flurry of messages from visually impaired users hit the support? Or a marketing survey found that a significant proportion of the service’s audience are people with arthritis? What conclusions did you draw from this? Why did you think it was important? How was the task formulated in the end?

Example: “The product manager has noticed a decrease in retention. At the same time, we received over 1,000 messages to support us about availability issues. This coincided with an increase in the 60+ audience following the onset of the coronavirus and lockdown. As a result, the business decided that Launcher X needed a redesign.

The design team was tasked with improving the accessibility of core scenarios in Launcher X, reducing support strain and increasing retention.”

3. Describe Your Role

A co-dependent relationship is when people don’t think of themselves as separate. People in such relationships tend to say “We did this,” “We went there.” Designers sometimes find themselves in this relationship with the product team. Yep it’s bloody great that you can build a strong relationship and work together towards common goals. But what about you specifically?

Say less “We” and more “I.” Tell me exactly what you’ve been doing on the team, what exactly were your contributions, what were you responsible for. Make a special point about what is valuable to the employer.

A bad example: “We worked on improving the game download scenario. Our team collected product metrics, formulated hypotheses and research questions, recruited respondents, conducted usability tests and user interviews, designed all major user-flows, validated design solutions, presented results to stakeholders, and passed specifications to the development team.”

A good example: “The design team has been busy improving the game’s download script. My part of the job was to improve the navigation bar (about 15% of the requests to the support concerned it). As a junior designer, I participated in the discussion of hypotheses and research questions, prepared prototypes for usability tests, ran one test under the supervision of a UX-researcher, designed the navigation bar myself, prepared a specification for the development team, and presented my part of the design to stakeholders at a design demo.”

4. Describe the Work and Decision-making Process

The work process can vary from company to company, product to product, and team to team. But what is usually important for interviewers is not to see specific actions, but to make sure that your work and its result is not the embodiment of primordial universal chaos.

What matters is your thought process, your ability to make logical connections and structure your work process.

Usually, the story about the work process includes:

• Research. Tell us what information you wanted to get about the users, the product and the business. Why it was important to get this particular piece of information. What methods did you use to get it? Why these particular methods. How did you apply them. What insights you gained.
• Prototyping. Explain how you put the research findings into practice. What decisions you made. Why you found particular solutions to be optimal.
• Validation. Explain how you tested the design decisions. Which methods you used. Why did you use these methods. What conclusions you reached. What actions you took then.

In your design story, focus on the aspects that fit your purpose.

5. Describe the Challenges

Actually, difficult situations are just a part of your design story. But it’s so important that I’ve decided to make it a separate point.

Of course, everyone loves a success story, where the process runs smoothly, stakeholders are enthusiastic about the proposals, the sun shines brightly and unicorns bounce on the rainbow. But personally, I appreciate failure stories more. At what point did things not go according to plan? Maybe the CEO decided to radically change strategy just before the launch? Or the development team realized they couldn’t use a key API? Or maybe a product manager quit in the middle of a project? And most importantly, how did you react? What action did you take?

Prepare your failure story in advance. If you don’t know what to talk about, here is a cheat sheet:

• Describe the situation.
• Talk about what you did in the situation.
• Describe the result of your actions.
• Tell what lesson you learned from the situation.

Example: “The developer told me through the product manager that he couldn’t make changes to the navigation bar in the current sprint. But I knew that the navigation bar is one of the most problematic places in the Launcher X interface, and we frequently received complaints from users through our support channels.

So I scheduled a personal meeting with the developer and asked why we couldn’t make the planned changes right away. It turned out that the navigation changes were via binary updates, and the next update isn’t scheduled until 2 weeks later. It turned out that this is not the first time this has slowed down the development team and the delivery of updates.

I passed this information on to the product manager. As a result, much of the Launcher X infrastructure was redesigned, and the speed of delivery of new features has almost doubled.”

6. Conclude with Achievements

If you expect to get the job, your case should be a story with a happy ending. From the hiring manager’s point of view, a happy ending is when design challenges are met, stakeholders are happy and product metrics grow convincingly and irrepressibly.

• At the end of the presentation, remind them what your task was and what the challenge was.
• Talk about what you ended up achieving.
• Explain exactly how you realized you had achieved success.

Example: “The design team was tasked with increasing the accessibility of basic scripts in Launcher X, reducing the number of support messages and increasing retention. My part of the job was to redesign the navigation bar.

As part of the Launcher X redesign, I updated the navigation bar to WCAG standards. As a result, the usability testing revealed no critical UX issues with the navigation. And a month after the Launcher X redesign, not a single message was received by customer support regarding the navigation bar.”

Prepare Your Answers to the Questions

However consistent and accurate your presentation, interviewers are likely to have questions. Some of them will be uncomfortable. But the good news is that most of these questions are predictable. You can prepare for them.

If you’ve done everything right — structured your presentation clearly, filled it with real facts, stressed important things — then the questions will be about your own assertions.

Let’s look at an example.

Let’s say that during a presentation you state: “I have chosen usability testing as my main research method”.

That’s a great statement! Let’s look at what questions the interviewers might have.

• “… main research method … “. What other methods did you consider? What methods were not the main methods? What did you mean when you said “main”?
• “… I have chosen …”. How did you choose the research method? Who was involved in making the decision? Why did you choose that particular method?
• “… usability testing …”. How did you prepare for the test? How exactly did you conduct the usability testing? Why exactly in this way? What was your sample of respondents? Why this sample? How did you present the results to the team? How did you prioritize problems? How did this testing affect the design?

You see? There’s nothing supernatural about it. All you have to do is:

• Break down your presentation into key statements;
• Check your own statements with clarifying questions;
• Prepare answers to these questions in advance.

That’s it! You are now covered in question-reflective alloy armor.

Rehearse, Rehearse, Rehearse

You have done a great job, you are a real hero. You know what to talk about, what to emphasize, how to sequence the story, and how to answer difficult questions. After all that, it would be a shame to fail because you forgot to mention an important fact or inserted an inappropriate joke out of excitement. For your presentation to be truly killer, all you have to do is rehearse the story so that it becomes your second nature.

I, for example, do the following:

• First, I say the text 3–5 times without preparation or structure. I just say whatever comes to mind, referring to the notes, with awkward pauses, with mistakes, with stupid facial expressions. As a result, some thoughts and ideas begin to repeat themselves;
• I write down a rough outline of my presentation;
• I repeat the presentation 3–5 more times according to the plan;
• I prepare sample slides for the presentation;
• With the slides, I talk through the presentation 3–5 more times, considering the timing;
• I correct and polish the presentation;
• I talk through the final version of the presentation 3–5 more times.

Of course, a good case presentation does not guarantee you a long-awaited offer. Hundreds of factors can influence the decision. Your previous experience and achievements, feedback from previous employers, how confident you were during the presentation, what the quality of communication was during the remote presentation, how much the interviewers ate before the presentation. Not all of these factors are under your control.

But the good news is that about half of your success in the job search is a great presentation of your case. And it’s entirely in your hands.

So fear nothing, prepare carefully and brave the dragon’s cave!

Harmful Advice

Of course, I respect and understand those designers who are determined to completely fail the interview and not get an offer. I have prepared a short guide for these mates too.

So, what do you do if you decide to epic fail:

• Do not set any goals for yourself. Let the case presentation be natural and spontaneous. Just follow your inspiration. Your intuition will tell you what to talk about.
• Don’t try to structure your story. Your story will come out hollow and too polished. People love spontaneity and unexpected twists and turns! Speak from the heart and don’t limit yourself to a boring structure.
• Don’t prepare slides for your presentation. You don’t want to look too prepared, do you? As if you are desperate for the job. If the company really wants to get someone like you, let the interviewers work hard and use their imagination too. You don’t have to illustrate every brilliant idea you have.
• It would be great if you could forget a couple of important facts about your case. This, on the one hand, will help you avoid uncomfortable questions. On the other hand, it shows how busy you are. You have so many projects that you can’t keep all the details in your head.
• Never talk about yourself and your role in a project. Always say ‘We’, ‘Us’, ‘Our’. This will help you take some of the credit and make your case more impressive. And if there are difficulties, you can blame it on a bad team. It’s a win-win!
• If you are asked an uncomfortable question about a case in an interview, try not to answer it specifically. It is better to move the conversation to another topic. Speak as much as possible to fill in any awkward pauses and to prevent the interviewer from bringing you back to the heart of the conversation. Try to cover your tracks. Use scientific terminology whose meaning you don’t understand (it’s likely that interviewers aren’t familiar with it either and will be too embarrassed to elaborate).
• Don’t prepare your answers to the case questions in advance. You’ll never be able to get inside the interviewers’ heads, and guess what they’ll be asking about anyway. Why then waste your time and energy on it at all?