Acing the app critique product design interview

Six frameworks to consider plus extra resources and exercises.

The app critique is one of the easier interviews you’ll encounter when interviewing for a product design role. Unlike the take home design exercise or the whiteboard interview you don’t have to create something from scratch.

Unlike a critique of an app that you’re designing — you’re not encumbered by any internal constraints (tech, business, etc.) either giving you immense amount of freedom. The challenge then lies in how to come up with reasonable constraints to help you navigate the critique.

As you’re facilitating the app critique, ask yourself—can I work with this team if I was hired?

This article will cover different techniques that you can mix and match to come up with an evaluation criteria for your app.

You’ll also learn:

Interview expectations and how to set critique objectives Six frameworks to help you critique an app Common mistakes to avoid Ways to practice better Plus extra resources to help you level up

This is the 21st post in the mastering product design interviews series. Let’s get started!

Interview format and criteria

App critiques usually last 30–45 minutes. Typically you’ll interview with one or two designers. You’ll be asked to either bring an app for critique (based on interviewer criteria) or the interviewers will pick one for you.

Your interviewers will assess you on:

Collaboration — how receptive are you to feedback? How do you react to different opinions? How effectively can you facilitate the critique?

how receptive are you to feedback? How do you react to different opinions? How effectively can you facilitate the critique? Craft — how well can you take a part and “reverse engineer” an app breaking it down to its first principles?

The craft component will vary depending on the specific role you’re applying for. For visual design you’ll zero in on the UI. UX design roles will focus on information architecture and interaction design. Product design roles tend to be generalist so expect a mix of both.

Based on how you approach the problem and how you respond to questions, your interviewers will also try to gauge which part of the design process is exciting to you.

Don’t forget the interviewer’s perspective. As they’re watching you critique the app they’re also thinking if they can work with you day to day. How you show up matters. Same goes for you. Use this opportunity to see if the culture of this team resonates with you.

Establishing critique objectives

Before diving into the app critique it’s important to understand how the critique will be carried out. Your interviewers might give you a general prompt like “critique app X” or get specific, “how can app X maximize revenue from its existing customer base?”

In either case start with high level objectives:

Context — if you’re bringing in an app yourself, let the interviewers know why you’ve selected it. If an app has been picked for you, you can set the context based on what you know about it.

Goals — if the prompt is open ended, narrow the scope by establishing goals. What’s the business objective? What is the user trying to achieve? What are we trying to get at in the next 20 minutes?

With these established, you can start to take the app apart. These don’t have to be fully fleshed out but it does help to have at least some explicit objectives defined upfront. But be ready to adapt. Even though you’ll come prepared, your interviewers will likely change objectives midstream. Think of the app critique like improv—you’re building on top of interviewer feedback.

Frameworks for critiquing apps

Now the fun part. Here are six frameworks to help you examine the app:

Jobs-to-Be-Done—uncovering the core objective Personas—goals, motivations, scenarios User familiarity—new users, intermediate users, and experts Expert evaluation—using best practices and industry standards Inclusivity—how accessible is this app? Zooming in and out—aesthetic, functional, and strategic layers

Many of these frameworks complement each other and you’ll use a combination of these in your critique.

1/6. Jobs-to-Be-Done-uncovering the core objective

Do you know what job a milkshake is hired to do? In his famous example, Clayton Christensen recounts the story of a struggling milkshake company trying to increase revenue. They try everything—making milkshakes thicker, larger, but nothing works. Only after observing customers buying milkshakes they come to a realization.

Many products fulfill multiple jobs. Photo credits

In the morning, customers prefer milkshakes because they’re a portable source of energy when commuting to work. The milkshake fills them up, it’s easy to hold in the car, and doesn’t leave a mess. In the evening parents swing by with their kids to treat them to the shake. But kids struggle. The straw is difficult to use and the packaging is clumsy at best for small hands.

As you can see the job varies depending on the context. Uncovering the JTBD will provide you objective criteria to critique the app against.

What is the customer trying to accomplish?

If the app didn’t exist what would the customer do?

Is the alternative better or worse than the app? Why?

A JTBD might be enough context to start getting into app flows and the UI.

2/6. Personas: goals, attitudes and behaviors

While JTBD provides an objective high level framework, personas can give you an extra layer of empathy with details. They’re especially helpful when you’re addressing users who are very different from you and the interviewer.

Visualizing assumptions helps uncover different viewpoints. Source

In the app critique context you won’t have research handy so you’ll need to make these up as you go. One way of organizing this info is through porto-personas as coined by Jeff Gothelf. If you have a whiteboard handy, jot down your assumed persona characteristics:

Goals —what objective(s) are they trying to accomplish?

—what objective(s) are they trying to accomplish? Motivation —why are they motivated to use the app?

—why are they motivated to use the app? Attitudes —how do they feel about the task they’re trying to accomplish?

—how do they feel about the task they’re trying to accomplish? Behaviors — where in the context of a user’s life does the app fit in? Where do they use it: home, work, or on their commute? How do they use it? What else is happening in the background?

Pairing personas with a scenario (think mini customer journey) will help you make the most of them by putting yourself in their shoes and imagining how they would use the app to accomplish a task.

3/6. New users, intermediates, and experts

You can segment your prototypical persona further based on how familiar they are with the app.

Welcoming newcomers

New users offer a different type of challenge compared to your everyday users who are already bought in. The app will need to communicate quickly to entice the user to continue. Depending on how much time you have, consider stepping all the way back to initial app discovery phase. How do the users find the app? What gets them to download and try it out?

As a new user who downloaded the app:

What is the value proposition? Can I easily find it? Does it resonate with my needs?

Do I need to sign up or can I try it out without commitment?

How much effort do I need to make in the beginning?

What barriers or friction do I encounter during onboarding?

Is it clear what I need to do next?

How much guidance do I need in the onboarding process?

How does this app incentivize me to use it more?

The new user perspective might be easiest to take during the app critique. It doesn’t assume prior app knowledge and it gets you and the interviewer on the same page by starting out fresh.

Becoming a regular user

With continued use of the app, the customer gains experience and becomes an intermediate user. Tasks that took a long time are a snap to complete. For an app critique this provides a rich exploration area—how do I as a new user become a repeat customer?

How does the app guide me?

Where can I find shortcuts?

What accelerators exist to improve my workflow?

How does the experience grow with my needs?

How can the experience be more personalized?

This approach works well with popular apps (e.g. Facebook) that you and the interviewer use frequently. Be sure to establish some common ground first though as they might be proficient on parts of the app that you don’t use.

Expert users

Depending on the application, experts have taken the time to squeeze every last bit of efficiency out of the tool. Similar to intermediate users you can think about evaluating the experience from a transition lens:

How does the app level up intermediate users?

Where can you find advanced functionality?

What tools are missing that might be helpful for an expert?

For the app critique, this might be the hardest perspective to take but it might be worthwhile for tools that are highly task oriented. Usually these tend to be enterprise apps like Photoshop or Visual Studio. Taking this perspective shows that you know the user intimately well and that you’ve developed a point of view on how to meet your user’s needs.

4/6. Expert app evaluation: industry best practices

JTBD, Personas, and different user types will help you define a critical path that can help you stay focused in the limited time that you have. As you’re putting yourself in the shoes of your prototypical user and thinking out loud you should also overlay your design expert commentary.

One way to communicate your expertise is by referring to existing popular guides such as Nielsen’s 10 Usability Heuristics which can be applied for different platforms. Depending on the app that you’re evaluating you can also lean in on official recommendations such as Apple’s Human Interface Guidelines or Google’s Material Design.

As an expert, your knowledge doesn’t have to stop at these guidelines of course. This is an opportunity for you to demonstrate your knowledge based on experience. What patterns have you seen hold up over time? What patterns work well for this industry or this audience segment? What have you seen fail or work in practice when testing concepts?

5/6. Inclusivity and accessibility

So far we talked about ideal user journeys and expert evaluation techniques with no mention of edge cases or customer impairments. If you want to step up in the critique—consider accessibility. Ensuring apps don’t exclude users is not a nice to have—in many parts of the world it’s the law.

Google Design team created an accessibility card deck to generate different scenarios

I won’t be able to do justice to accessibility here but for the purpose of the app critique you can think about the following impairments:

Vision — what affordances does the app make for users with low vision, color blindness, or blindness? Think size, color, contrast, or environmental factors like screen glare.

Hearing — how does the app make use of sound, does it provide backup cues? Does it have alternative text or captions? Think about the app’s use in a busy environment, e.g. busy train station.

Motor — does the app require intricate touch gestures? Are tap targets large and easy to discover? Think about using the app while walking.

Cognitive—how much cognitive load does the app require on the user? Does the user need to memorize instructions or remember complicated operations?

For more info, take a look at Inclusive design by Microsoft.

6/6. Zooming in and out on the experience

As you’re going through the customer journey you’ll be at times going back to the strategic goals of the critique to make a point, diving into app functionality or zooming all the way into a particular microinteraction.

One way to think about this is a top-down structure that encompasses visible (aesthetic) and invisible (functional + strategic) layers.

Be sure to cover functional and strategic parts of the experience

Aesthetic — how it looks. Domain of visual design, motion, sound, touch. Functional — how it works. Domain of information architecture and interaction design. Strategic — why it exists. Domain of value props and business strategy.

Aesthetic layer

This layer is a summation of all the parts that you experience when you open up the app. How does this application achieve visual design and consistency?

Brand— what message is the app trying to convey?

what message is the app trying to convey? Visual— how does the app use the visual language (color, shape, type, etc.) to reinforce its identity? What is the aesthetic experience like?

how does the app use the visual language (color, shape, type, etc.) to reinforce its identity? What is the aesthetic experience like? Motion —how does animation help orient the user? Are there any signature moments?

—how does animation help orient the user? Are there any signature moments? Sound —how does the app use sound to inform?

—how does the app use sound to inform? Touch—what gestures exist and are they easily discoverable?

Pairing this layer with personas will be helpful. This is also a prime layer to think about accessibility and inclusivity.

Functional layer

Below aesthetics lies functionality—these are core mechanics that help the user accomplish their goal.

Information architecture — how is the information labeled and organized? What paths exist to browse or search?

— how is the information labeled and organized? What paths exist to browse or search? Interaction design — how does the app work? What macro and micro flows exist? What patterns are being used, what are the trade offs?

This layer pairs well with personas and expert evaluation.

Strategic layer

In this layer you’ll find problem framing and value proposition.

App — why does this app exist? For who? What problem is it solving?

— why does this app exist? For who? What problem is it solving? Business — What problem is the company trying to solve? What are the values that we believe in? How does the company want to portray itself? How does it make money? What’s the company’s mission? What values does it abide by?

The strategy layer overlaps significantly with JTBD so you’ll probably be going back and forth between the two.

Avoiding common app critique mistakes

From my time as an interviewer I’ve seen a couple of mistakes that designers make when doing critiques for interviews.

Stopping at aesthetics

Sometimes it’s tempting to dive right in and point out all the things that look off on the UI. Don’t get stuck on aesthetics. None of that will matter if the app doesn’t help the user achieve it’s core goal in the first place. Establish your first principles based on the frameworks above and work forward.

Stuck on one approach

If you had an app that you’ve already picked yourself–then you’ve already came prepared with how you’re going to critique it. But be ready to adapt your approach and consider different methods when prompted. Doing so also allows you to show off other tools at your disposal and handling ambiguity is a sign of maturity as a designer.

All praise with no substance

I’ve encountered situations where instead of critiquing the designer lavishes praise on the app. As an interviewer this tells me that you can’t reflect critically on the work and you assume that whatever’s been launched is best.

Ha Phan’s tweet is on point, don’t blindly copy—understand first

Always ask why. Why does this work well — what makes it good? Why does this not work — what things make it less effective? A critique framework helps you stay objective and avoid this pitfall. I also recommend looking at similar apps and comparing them against a user’s job to be done, see below.

Getting better at critique

Like any activity, you’ll get better at critique with practice. To make the most out of your practice I recommend critiquing an app with a group, isolating your weaknesses, and comparing and contrasting similar apps.

Critique in diverse groups

Practice critique with a partner or two. Get a group of designers who have different strengths and feel free to include other disciplines such as engineering. Practicing together with a diverse group will widen your perspective significantly, compared to practicing alone.

Isolate and focus on an area of growth

If you’ve already evaluated your craft skills, you probably uncovered one or two areas of opportunity. Let’s say you’re interested in motion design. Look at the app strictly from that lens—how does it use motion to communicate? Try replicating the interaction in your favorite prototyping tool. By copying work you’ll learn more through practice helping you see the finder details.

What job does a running app solve in this context? Source

Comparing similar apps with JTBD framework

Look at similar apps through the lens of a JTBD statement. How’s one app better than the other? What does “better” mean? For example if a tourist is visiting a city and wants to go from point A to point B? You can start from a narrow app lens and zoom out from there:

Getting a rideshare (Lyft, Uber) Renting out a car and driving yourself (e.g. Getaround—how does it compare to rideshare?) Taking public transit (e.g. Transit app—how does it compare to Uber?) Walking by foot (e.g. how does the city help me understand my current location and my proximity to the destination?)

You can do similar types of exercises in other industries like sports (e.g. training for a marathon), social interaction (e.g. Facebook), or finance (e.g. Mint). Remember the customer’s objective—while there’s an app for that, it doesn’t mean that the alternatives don’t exist or aren’t better.

Additional resources

If you’re interested in growing your critique skills, here are some handpicked resources to help improve:

Jobs to be done and personas by NN/G. This article is short read on how to use both methods effectively.

Discussing Design by Adam Connor. This book goes into the mechanics and the nitty gritty of critique facilitation.

How to make sense of any mess by Abby Covert. A short read that arms you with basic information architecture tools and techniques.

Elements of User Experience by Jesse James Garrett. This is a short, quick read that breaks down a design problem into multiple layers: visual, skeleton, structure, scope, and strategy.

About Face 4 by Alan Cooper. A hefty volume of nearly 700 pages it’s a solid reference for all things interaction design.

What’s next?

Previously we covered how to crush the whiteboard challenge. In the next article we’ll look behavioral interviews—communicating effectively with multiple stakeholders such as designers, product managers, engineers, and researchers.