Adobe UX Designer — Interview Questions

Adobe UX Designer Interview Questions

Designing at Adobe is unusual because your users are designers. They notice everything, they have opinions, and many of them have used the product longer than you have worked in the industry. At the same time Adobe is trying to bring in people who have never opened a professional creative tool and who will abandon it in ninety seconds if it feels intimidating. Almost every interesting design problem at Adobe is a version of that conflict, and the interview is built to find out whether you can hold both users in your head at once without designing something that serves neither.

Adobe's Interview Process for UX Designers

The loop for design roles typically runs three to five weeks. A common shape reported by candidates is: an HR call, a thirty-minute screener, a one-hour portfolio round, a ninety-minute whiteboarding round, a thirty to forty-five minute hiring manager round, and sometimes an optional director round.

The portfolio round is the centre of gravity. Interviewers go deep on one or two projects, pushing on the decisions rather than the visuals — what constraints you were under, what you rejected, what the outcome was, what you would do differently. Presenting polished screens without being able to defend the reasoning behind them is the most common way candidates lose this round.

The whiteboard challenge is live and typically forty-five to ninety minutes on a deliberately broad prompt. The output is not the point. Interviewers are watching how you handle ambiguity, whether you ask about users and constraints before drawing, whether you take feedback mid-exercise, and whether you can think out loud under pressure without going silent.

Behavioural rounds cover collaboration with PMs and engineers, handling critique, and cultural fit.

Question 1: Walk me through a project that did not work

Pick a project from your portfolio where the outcome was worse than you hoped. Take us through it properly — the brief, what you designed, what happened, and what you would do differently. We will interrupt.

Why interviewers ask this

The portfolio round rewards depth of reasoning over polish, and asking for a failure removes the option of presenting a clean narrative. Weak candidates choose something safe where the failure was somebody else's fault, or a project that was actually a success with a minor caveat. Strong candidates pick a real one, own their part in it, and demonstrate that they extracted a transferable lesson rather than a platitude.

Example strong answer

The strongest version of this answer has a specific shape rather than specific content, so here is the shape, with an illustrative example.

Start with the constraint the project was really operating under, not the brief as written. For instance: we were asked to redesign a settings experience because support volume was high, but the actual constraint was that we could not change the underlying data model, which meant the settings had to keep their existing structure even though the structure was the problem. Naming that up front tells the interviewer you understood the real problem space, and it sets up why the outcome was limited.

Then describe what you designed and, crucially, what you rejected and why. Interviewers push hardest here. Say you considered a task-based reorganisation — group settings by what the user is trying to accomplish rather than by which subsystem owns them — and rejected it because it would have required backend changes we could not get. Instead you designed progressive disclosure with search, hiding the complexity rather than removing it. That is a legitimate decision under the constraint and it shows you chose rather than defaulted.

Then the outcome, honestly. Support volume dropped by less than the team hoped — say a modest single-digit improvement against a target several times that. Search usage was high, which was good, but the tickets that remained were mostly from users who could not name the thing they were looking for, so search did not help them.

Then the part that separates strong candidates: what you learned that was actually transferable. In this example, the lesson is not "do more user research," which is the platitude version. The lesson is that search only helps users who possess the vocabulary of the system, and a settings problem caused by unfamiliar terminology cannot be solved by a tool that requires the terminology as input. That is a specific, portable insight that will change how you approach the next problem.

Then what you would do differently. Two things: I would have tested the terminology hypothesis in week one with a card sort rather than assuming the structure was the only issue, and I would have pushed harder and earlier on the data model constraint. In retrospect the engineering cost of restructuring was quoted to me casually and I accepted it without asking what it was actually based on. Constraints that arrive as assertions deserve one round of interrogation.

Finally, be ready for interruptions and treat them as the point. When someone asks "why not X," the good response is not defensiveness and not immediate capitulation — it is to say what you considered about X, what the trade-off was, and what would have made you choose it. Interviewers are testing whether critique makes you rigid or unmoored, and the right answer is neither.

Follow-up questions

You said engineering told you the data model could not change. Did you ever verify that independently?
If the same brief landed on your desk tomorrow with the same constraints, what is the first thing you would do?

Question 2: Whiteboard — first ninety seconds in Photoshop on the web

Someone who has never used Photoshop opens it in a browser. They arrived from a search for "remove background from photo." Design their first ninety seconds. You have forty-five minutes and we will give you feedback as you go.

Why interviewers ask this

This is the whiteboard round. The prompt is intentionally broad and the interviewers are watching process, not output — whether you scope before drawing, whether you name assumptions, whether you incorporate feedback rather than defending your first idea. Weak candidates start sketching screens in the first two minutes. Strong candidates spend the first five to eight minutes narrowing the problem out loud.

Example strong answer

I would spend the first several minutes asking rather than drawing, and I would say that is what I am doing so the interviewers know it is deliberate.

The questions that actually change the design: Is the goal here conversion to a subscription, or genuine adoption of Photoshop as a tool? Those pull in different directions — one wants the user to hit value fast and then meet a paywall, the other wants them to learn something. Do we have the image already, or does the session start empty? Is there a constraint that this has to be the real Photoshop canvas, or can the first ninety seconds be a purpose-built surface? And what happens after — is there a next step we want them to take?

I would state my assumptions if the interviewers do not answer: the goal is adoption with conversion as a downstream outcome, the user has an image on their device, and I can build a purpose-built entry surface that hands off to the full canvas.

Then I would frame the core design tension, because it is the whole problem. This user came for one specific job. Photoshop is a general-purpose tool with an interface built for people doing hundreds of jobs. If I show them Photoshop, I lose them — the panels alone will end the session. If I show them only a background remover, I have built a single-purpose utility and taught them nothing about Photoshop, and they have no reason to return or to pay. So the design has to complete their job first and reveal the tool second, in that order, and never the reverse.

My sketch would go something like: an entry screen that speaks their language — the words from the search that brought them, not our product vocabulary — with one obvious action, which is to add their image. Drag, browse, or paste, with paste worth calling out because a surprising share of these users have the image in their clipboard. Then the operation runs automatically without them asking, because they already told us what they wanted by how they arrived, and asking again is friction. Result on screen in seconds, with a clear before and after so the value is legible.

That is roughly the first thirty seconds and the job is done. The next sixty are the interesting part. I would not dump them into the full application. I would offer two or three adjacent moves that are visibly related to what they just did — refine the edge, drop in a different background, resize for a specific use — presented as a small set of tiles rather than a toolbar. Each one they take is a step deeper, and the canvas can gain one element of the real interface at each step, so the tool assembles itself around their work rather than confronting them at the start.

Download comes with no gate, and the gate — if there is one — sits at something that implies commitment, like saving to the cloud or history.

Throughout I would narrate the trade-off I am making, and when the interviewers push back I would treat it as new information. If someone says the auto-run is presumptuous, I would take that seriously and talk through the alternative of a single confirming click, and what evidence would decide between them.

Follow-up questions

The background removal produces a poor result on this user's image. Redesign that moment.
Business says the download must be gated. Where do you put the gate, and what do you tell them it will cost?

Question 3: Designing for the expert and the beginner at once

Illustrator has users who have been in it since the nineties and know every shortcut, and it has students opening it for the first time this week. A simplification that helps the second group is often experienced as a downgrade by the first. How do you design for both without building two products?

Why interviewers ask this

This is the defining design problem at Adobe and it comes up in some form in nearly every loop. Weak candidates propose a beginner mode and an expert mode and consider the problem solved. Strong candidates understand why modes usually fail and reach for progressive disclosure, defaults and adaptivity instead.

Example strong answer

My starting position is that a beginner mode and an expert mode is the obvious answer and usually the wrong one. It fails for three reasons that are worth naming.

First, nobody self-identifies accurately. Beginners do not want to be labelled beginners and will pick the full version out of pride, then be overwhelmed. Second, it forks the design, the documentation, the tutorials and the support burden, and one of the two forks inevitably gets less attention. Third, and most damaging, it creates a cliff. A user who has outgrown beginner mode has to voluntarily jump into an interface they have never seen, at which point they experience all the intimidation we were trying to spare them, just later.

What works better is a single interface whose complexity is revealed rather than switched. Concretely, three mechanisms.

Defaults do most of the work. The expert and the beginner can share the same interface if the beginner never has to configure anything to get a sensible result. Every dialog with six options where five have a right answer for a first-time user is a place where a good default removes complexity without removing capability. Experts change defaults; beginners never see that they existed.

Progressive disclosure handles the surface area. Advanced controls live behind a consistent, learnable affordance rather than being present at all times. The important detail is consistency — if the pattern for "there is more here" is the same everywhere, discovering it once teaches the user the whole product. Inconsistent disclosure is worse than no disclosure because it makes depth feel arbitrary.

Adaptivity handles the transition, and this is the part that avoids the cliff. The interface can respond to demonstrated behaviour rather than to a declared identity. Someone who has used a tool twenty times can be shown its options inline. Someone who repeatedly uses a menu item can be offered the shortcut at the moment they use it, which is also the moment it will stick. The critical constraint is that adaptivity must never move or remove something the user has already learned. Interfaces that rearrange themselves destroy the muscle memory that makes experts fast, and for Adobe's professional users that is the single most valuable thing they own. So the rule I would hold to is that the interface can add and reveal, never relocate or hide something previously present.

There is a fourth mechanism worth mentioning, which is separate entry points into the same product rather than separate modes of it. A task-focused entry — "remove a background," "make a poster" — that hands off into the full canvas gives the beginner a door sized for them without creating a second product behind it. The tool is the same; only the way in differs.

Finally, on how I would validate: I would not test a simplification only with beginners, which is the common failure. I would run it with long-tenured professionals specifically looking for whether anything they rely on became slower, and I would treat "an expert now needs one extra click for something they do fifty times a day" as a serious cost rather than a rounding error. Fifty extra clicks a day is how you lose the users who evangelise your product.

Follow-up questions

A default you chose is right for eighty percent of users and actively wrong for a professional segment. How do you decide?
Give me a case where you would accept slowing experts down.

Question 4: A colour tool for users who cannot see colour

Roughly one in twelve men has some form of colour vision deficiency, and Adobe's tools are saturated with colour-dependent interfaces — swatches, layer labels, selection highlights, curves. Pick one of those and make it work for a designer with deuteranopia. Then tell me what you would have done differently at the start.

Why interviewers ask this

Accessibility questions in a creative tool are genuinely hard because colour is not decorative here, it is the subject matter. Weak candidates recite WCAG contrast ratios. Strong candidates distinguish between colour used as information and colour as content, and think about the professional's actual workflow rather than compliance.

Example strong answer

The first distinction I would make is between colour that carries interface information and colour that is the user's content, because they need completely different treatments.

Interface colour — a layer label, a selection highlight, a warning state — is information encoded in hue. That is a straightforward accessibility failure and the fix is well understood: never let hue be the sole carrier. Layer labels get a shape or a pattern alongside the colour. Selection gets a distinct outline treatment rather than only a coloured overlay. States get an icon or text. Contrast ratios matter and I would meet them, but contrast alone does not fix hue-only encoding, and that is the more common mistake — two colours can have identical luminance and be indistinguishable to a deuteranope while technically passing a contrast check against the background.

Content colour is the harder and more interesting problem. A designer with deuteranopia working in Illustrator needs to make colour decisions about output they cannot fully perceive. This is not something I can fix by adjusting the interface; the colour is the deliverable. What I can do is give them reliable information about it.

I would pick the swatch and colour-picker experience for this. The core change is to make numeric and named values always visible rather than hidden behind a hover or a secondary panel. A professional who cannot distinguish two greens can absolutely work with them if the interface tells them, always and without asking, that one is a specific hex value and the other is another. Colour becomes data rather than perception. I would also surface relationships explicitly — this swatch is a tint of that one, these two are complementary — because those relationships are exactly what a colour-deficient designer cannot see and what they most need in order to make good choices.

Alongside that, a simulation view that shows how the current document appears under different types of colour vision deficiency. Adobe has shipped versions of this before and the value is real, but its placement matters: if it lives in a menu three levels deep it is a compliance feature, and if it is a toggle in the workspace it is a working tool. I would put it where a designer would actually use it repeatedly, and I would make it work for the deficiency the user themselves has, not only as an empathy tool for designers checking their work for others.

I would also add contrast checking directly against the artboard rather than as a separate step, so that a designer gets a signal at the moment of choosing rather than at the end of a project.

On what I would have done differently at the start: the honest answer is that accessibility is being retrofitted here because colour-as-information was baked into the interface language early, when the assumption was a designer with typical colour vision. The lesson is that any time hue is chosen as the encoding for a distinction, it should have been designed with a second channel from the beginning — shape, position, label, or texture — not because of a compliance requirement but because it makes the interface more legible for everyone, including people working on a bad monitor in bright sunlight. Retrofitting a second channel into an established visual language is far more expensive than designing with one, and it produces a compromised result.

Follow-up questions

The professional segment says the always-visible hex values add clutter. How do you resolve that?
How would you prioritise this work against a feature request with clear revenue attached?

Question 5: Designing an interface for something that is sometimes wrong

Generative Fill produces a result the user did not ask for maybe a third of the time. The model will improve but it will never be reliable in the way a brush is reliable. Design the interaction around that. How does the user stay in control of a tool that has its own opinions?

Why interviewers ask this

Every design team at Adobe is now designing around probabilistic output, and this is the question that reveals whether a candidate has thought about it structurally or just seen some prompt boxes. Weak candidates design a nicer prompt input. Strong candidates focus on reversibility, expectation setting, and giving the user leverage over the outcome without requiring them to become a prompt engineer.

Example strong answer

The central design principle I would work from is that when a tool is unreliable, the cost of a wrong result has to be near zero. Everything follows from that.

Concretely, that means the operation must be trivially reversible, non-destructive, and cheap to retry. Generative Fill should never modify the underlying pixels irrecoverably; it should produce a layer the user can discard, mask, or blend. If undoing a bad generation takes one obvious action and costs nothing, a one-in-three miss rate is an acceptable working rhythm — it becomes like taking multiple photographs rather than like making a mistake. If undoing is awkward, the same miss rate makes the tool feel hostile.

Second, generate multiple options rather than one. A single result frames the interaction as the tool answering a question, which sets the user up to judge it as right or wrong. Three variations frame it as the tool offering material, which sets the user up to choose. That is a small change in interaction model and a large change in how failure feels. It also gives us useful signal: which variation gets picked is a preference judgment we can learn from without asking the user to rate anything.

Third, expectation setting before the fact rather than apology after. The interface should communicate what this tool is good at and where it struggles, in context, at the point of use. If it handles textures and backgrounds well and struggles with hands and text, saying so quietly at the moment the user is about to select an area is far more useful than a general disclaimer nobody reads. This is not a legal caveat; it is a way of teaching the user to aim the tool.

Fourth, give the user leverage that is not prompting. Prompt text is a poor control surface for designers — it is imprecise, it requires vocabulary, and it makes the user responsible for the model's failures. Better controls are the ones designers already know: selection shape, reference imagery, sampled colour or style from elsewhere in the document, strength and blend controls on the result. The more the outcome is shaped by direct manipulation and the less by describing, the more it feels like a tool and the less like a request.

Fifth, iteration in place. When a result is close but wrong in one region, the user should be able to act on that region rather than rerolling the whole thing. Rerolling discards the parts that worked, which is the most frustrating failure mode of generative tools.

On the emotional register, I would be careful with the language. Anthropomorphising the tool — having it apologise, or say it is thinking — makes its failures feel like a character flaw and invites the user to argue with it. Neutral, mechanical language keeps it a tool. Designers do not want a collaborator with opinions; they want an instrument that does what they aim it at.

Finally, I would want to measure the right thing. Not generations per session, which goes up when the tool is bad. The metric that matters is the rate at which a generation is accepted and survives into the final saved document, and how many attempts it took to get there. Attempts-to-accept is the honest quality signal, and it is the number I would design against.

Follow-up questions

Generating three options triples GPU cost. Defend it to a PM who owns that budget.
A user gets a result that is technically fine but tonally inappropriate for their brand. Is that a design problem?

Question 6: Your design is too expensive

You have designed an interaction that user testing shows is clearly better. Engineering estimates it at three times the cost of a simpler version. The PM wants to ship the simpler one to hit a date. You are in the room. What do you do?

Why interviewers ask this

Adobe's behavioural rounds probe collaboration with PMs and engineers specifically. Weak candidates either describe fighting for the design as a matter of principle or describe accepting the compromise as being a team player. Strong candidates treat it as a shared decision with real information on both sides.

Example strong answer

I would try to move the conversation from a contest between two positions to a shared question about what we lose, because as posed it is a standoff and standoffs get resolved by whoever has more organisational weight, which is a bad way to make product decisions.

First I would want to understand the three-times estimate. Not to challenge engineering's competence, but because "three times" is usually three times a small number or three times a large one, and those are different conversations. I would also ask what specifically drives the cost. Often one element of a design carries most of the expense, and if I know which one, I can look at whether that element is what makes the interaction better or whether it is incidental. In my experience there is frequently an eighty percent version that costs closer to one-and-a-half times, and finding it is a design problem I should be solving rather than a compromise being imposed on me.

Second, I would be specific about what the evidence actually shows. "Clearly better" needs a number attached. If testing showed users completed the task faster or with fewer errors, I would say by how much and on what sample. If the improvement is large and on a high-frequency path, that is a strong argument. If it is a modest improvement on something users do rarely, I should be honest that the case is weaker, even though it is my design. Overstating my own evidence is the fastest way to lose credibility for the next disagreement, which will matter more.

Third, I would name the cost of the simpler version explicitly and get it written down. If we ship the cheap version, what do users experience, and is it a permanent state or an intermediate one? There is a large difference between a simpler version that can be upgraded later and one that establishes an interaction pattern users will learn and that we will then be reluctant to change. If it is the latter, I would say so clearly, because that is a cost the PM may not be pricing in and it is genuinely my job to raise it.

Fourth, I would look for a third option. Ship the simpler version to a subset and the better one to another, if that is feasible, and let the data settle it. Or ship simple now with the better version explicitly scheduled, with the scheduling written into the plan rather than promised verbally, because verbally-promised follow-ups do not happen.

If after all that the PM still wants the simpler version and I disagree, I would disagree and commit. I would make sure my reasoning is documented so that if the metric underperforms we know why to look here, and I would move on without relitigating it. Designers who treat every compromise as a battle lose influence over the decisions that matter most. I would spend my credibility on the cases where the cost is large and permanent, not on every case where I am right.

Follow-up questions

Three months later the simpler version is measurably underperforming. How do you raise it without saying you told them so?
What if the PM's real reason is the date and they will not say so directly?

Question 7: Consistency across twenty applications

Adobe ships a large suite. A user moves between Photoshop, Illustrator, Premiere, Acrobat and Express in a single day. Each has decades of its own conventions and its own team. How would you think about consistency across that surface, and where would you deliberately allow inconsistency?

Why interviewers ask this

Design systems questions test whether a candidate understands that consistency is a means rather than an end. Weak candidates argue for total unification. Strong candidates identify which layers benefit from consistency and which conventions are load-bearing for expert users and must not be touched.

Example strong answer

I would start from why consistency has value at all, because that determines where to apply it. Consistency is valuable when it lets a user transfer learning from one place to another. It has no value, and can have negative value, when it forces two genuinely different things to look the same.

So I would separate the surface into layers.

At the bottom are the things that should be rigorously consistent because they are identical problems appearing in different applications: authentication, file open and save, sharing and permissions, cloud storage, preferences, account and billing, keyboard conventions for universal operations like undo. A user who learns how sharing works in one Adobe app should never have to relearn it in another. These are also the places where inconsistency is pure cost — nobody's creative work is improved by Premiere's share dialog being idiosyncratic.

In the middle are visual and interaction primitives: buttons, fields, menus, panels, dialogs, iconography, spacing, type, colour semantics. These should come from a shared system so the suite feels like one product and so teams stop re-solving solved problems. This is what a design system like Spectrum is for, and the value is as much in engineering and accessibility as in aesthetics — a shared, accessible component library means every team inherits keyboard navigation and screen reader support rather than each getting it partly wrong.

At the top are the core working surfaces, and this is where I would deliberately allow, even protect, inconsistency. Photoshop's tool behaviour, Illustrator's path editing, Premiere's timeline — these are not arbitrary differences. They are the accumulated result of decades of optimisation for genuinely different tasks, and expert users have deep muscle memory in them. Unifying them in the name of consistency would impose an enormous cost on the most valuable users to deliver a benefit that mostly accrues to people who use one app anyway. A timeline and a canvas are different because editing video and retouching a photo are different, and pretending otherwise produces a worse tool.

There is a subtler case worth flagging: things that are conceptually the same but named differently across apps. Artboards, canvases, pages, sequences. Here I would push for consistent naming even where the underlying object differs slightly, because vocabulary is where cross-app confusion actually bites, and it is cheap to fix relative to interaction changes.

On how to actually make this work organisationally, which I think is the real question: a design system only holds if adopting it is easier than not adopting it. That means investing in the component library, the documentation and the migration tooling to the point where a product team saves time by using it. Systems that are enforced by review rather than made attractive by quality get worked around, and you end up with the appearance of consistency and the reality of drift.

I would also build in an explicit path for exceptions. A team with a genuine reason to deviate should be able to, through a process that captures why — because those exceptions are often the system's next feature, and a system with no exception path either strangles product work or gets ignored.

Follow-up questions

A team wants to deviate and their reason is that they think the system component looks dated. How do you respond?
Where would you start if you inherited a suite with no shared system at all?

Preparation tip

The portfolio round is where Adobe design candidates most often lose the loop, and the failure mode is presenting outcomes instead of decisions. Interviewers go deep on one or two projects and push on what you rejected, what constrained you, and what you would change — so prepare two projects to a depth where you can defend every choice for twenty minutes, rather than preparing eight projects at surface level. For the whiteboard round, practise the first eight minutes specifically: scoping out loud, naming assumptions, asking about users and constraints before you draw anything. Candidates who start sketching immediately almost always solve the wrong problem, and interviewers notice the difference between a designer who is thinking and one who is performing.

Back