editione1.0.3
Updated October 11, 2023You’re reading an excerpt of Land Your Dream Design Job, a book by Dan Shilov. Filled with hard-won, personal insights, it is a comprehensive guide to landing a product design role in a startup, agency, or tech company, and covers the entire design interview process from beginning to end, for experienced and aspriring designers. Purchase the book to support the author and the ad-free Holloway reading experience. You get instant digital access, commentary and future updates, and a high-quality PDF download.
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, and so on), giving you an immense amount of freedom. The challenge then lies in how to come up with reasonable constraints to help you navigate the critique.
important As you’re facilitating the app critique, ask yourself—can I work with this team if I was hired? Do they seem like people I can bounce ideas off freely?
We’ll cover different techniques that you can mix and match to come up with evaluation criteria for your app.
App critiques usually last 30–45 minutes. Typically, you’ll interview with one or two designers. Either you’ll be asked to 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?
Craft. How well can you 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 evaluating 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.
important If you’re critiquing an app remotely, instead of trying to hold up your phone to the camera, it’s a better experience to dial into the meeting with your phone and share your phone screen. I definitely recommend you practice dialing in and setting up your phone permissions ahead of time as the setup can get tricky and you don’t want to be wasting precious time during the interview fiddling with settings.
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 up-front. 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.
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 them in your critique.
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 do they come to a realization.
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 it 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 jobs-to-be-done, or 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.
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.
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 proto-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?
Motivation. Why are they motivated to use the app?
Attitudes. 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.
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 the 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 like 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 perspective:
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 well and that you’ve developed a point of view on how to meet your user’s needs.
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 want to 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?
So far, we’ve 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. The Google Design team created an accessibility card deck to generate different scenarios.
The 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—for example, a 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 of the user? Does the user need to memorize instructions or remember complicated operations?
For more info, take a look at Inclusive Design by Microsoft.
As you’re going through the customer journey, you’ll at times be going back to the strategic goals of the critique to make a point, diving into app functionality or zooming all the way in to a particular micro-interaction.
Consider both visible and invisible layers.
One way to think about this is a top-down structure that encompasses visible (aesthetic) and invisible (functional and strategic) layers:
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.
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?
Visual. How does the app use the visual language (color, shape, type, and so on) to reinforce its identity? What is the aesthetic experience like?
Motion. How does animation help orient the user? Are there any signature moments?
Sound. How does the app use sound to inform or entertain?
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.
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?
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.
In this layer you’ll find problem framing and value proposition.
App. Why does this app exist? For whom? 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.
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 its core goal in the first place. Establish your first principles based on the frameworks above and work forward.
Stuck on one approach. If you have an app that you’ve already picked yourself, then you’ve already come 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, 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.
Spending too much time describing the UI. Don’t get stuck explaining what you see or what the app does. If you’re not actively sharing your mobile app screen where the interviewer can see it, it’s ok to give some context but make sure you focus more on the critique itself. Interviews want to know your thinking, they don’t want you to to recite the UI.
important 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.
Like any activity, you’ll get better at critique with practice. To make the most of your practice, I recommend critiquing an app with a group, isolating your weaknesses, and comparing and contrasting similar apps.
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.
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 through that lens—how does it use motion to communicate? Try replicating the interaction in your favorite prototyping tool. Copying work will help you learn more through practice and see the finer details.
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, a tourist visiting a city wants to go from point A to point B. You can start from a narrow app lens and zoom out from there:
Renting a car and driving yourself (for example, Getaround—how does it compare to rideshare?).
Taking public transit (Transit app, for instance—how does it compare to Uber?).
Walking (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 (training for a marathon), social interaction (Facebook), or finance (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.
If you’re really interested in diving into strategy and product positioning, go beyond the app. Look into how the app presents itself in the App Store, Play Store, on web (even if the web site is just a glorified ad for the native app download). When you have the app, look at how it tries to pull you in via non-app channels such as e-mails, pushes, etc.
If you’re interested in growing your critique skills, here are some handpicked resources to help improve:
Personas vs. Jobs-to-Be-Done, by NN/g. A short read on how to use both methods effectively.
Discussing Design, by Adam Connor and Aaron Irizarry. A book on the mechanics and the nitty-gritty of critique facilitation.
How to Make Sense of Any Mes, by Abby Covert. A short book that arms you with basic information architecture tools and techniques.
The Elements of User Experience, by Jesse James Garrett. A quick read that breaks down a design problem into multiple layers: visual, skeleton, structure, scope, and strategy.
About Face, 4th ed., by Alan Cooper, et al. A hefty volume of nearly 700 pages, it’s a solid reference for all things interaction design.
In this example, we’ll go through Yelp’s iOS app, evaluating the app in a couple of ways. We’ll make our first impressions by examining the home page, and then get a sense of its structure by navigating to different pages. We’ll look into personalization and go through one of the core flows by looking for a nearby restaurant.
We’ll evaluate the app based on its visual and interaction design. We’ll also consider strategy, also known as “product thinking” or “business acumen,” to understand the why behind the UI decisions. Although it’s not our primary concern, we’ll also pay attention to copy and messaging.