What to claim, and what not to
The re-scoped role says “some UI/UX”, which is an invitation to overclaim. Do not take it. Claim the layer, not the craft.
Not this
“I do the UX — research, wireframes, the interface, the design system.”
Testable in ninety seconds by anyone who owns a design function, and failing that test costs you the whole round.
This
“I make the design decidable — the flow, the states, the edge cases, and something clickable people can argue with. If there's a designer, they should be doing the interface.”
A ceiling volunteered in her own domain is what makes every other boundary you draw credible.
The value you are selling is not visual. It is that the design argument happens in a clickable artefact over two days, rather than in a sprint over two weeks — and that the version handed to engineering already has its edge cases answered.
Walking through a redesign
Expect “walk me through a redesign you did” in some form. Five beats, ninety seconds, and the second beat is the one nearly everyone skips.
What it was and who used it
One sentence. Name the users by their job, not by a persona label. “Twelve cost-centre owners doing a monthly submission” beats “finance stakeholders”.
How you knew it was broken
The evidence, and it must not be an opinion. People exporting to Excel every time. The same question arriving weekly. A task taking four screens. Usage falling off after week three. This beat is what separates someone who designs from someone with taste.
The structural change
Not the cosmetic one. What you removed, what you reordered, what you stopped asking people to do. If the change you describe is visual, she will assume the problem was cosmetic and the answer deflates.
The number afterwards
Time per task, adoption, ticket volume, export rate, error rate. A redesign story without a number is an anecdote. If the number is unflattering, use it anyway — it is more credible than a good one.
What you got wrong first
One clause, then stop. It pre-empts the follow-up she was going to ask and it is the cheapest seniority signal available.
The trap in this question
Describing a redesign in terms of what it looks like. She is not asking whether you have taste — she is asking whether you can find the real problem, which in finance tools is almost never visual. It is usually that the number cannot be traced, the data is stale at the moment of use, or the task spans four systems.
Finance interface rules
Most candidates answer design questions with consumer-app instincts, which are wrong here. These six are on the round-one domain page and worth being able to state cold; the three after them are the ones that show depth.
| Rule | Why, in one line |
|---|---|
| Density over polish | Professional users on the same screen daily. Generous whitespace is friction, not elegance. |
| Every number traceable | Drill-through, named source system, as-of timestamp. Distrust is the default reaction to a number you did not produce. |
| Design the honest states | Stale, partial, still-reconciling, source-down. Most dashboards have one state — “fine” — and show yesterday as though it were today. |
| Tabular numerals, right-aligned | Columns must be scannable vertically. Mixed units and abbreviated magnitudes cause real errors. |
| Export is a feature | They will take it into Excel. Design a good export and you get thanked instead of routed around. |
| No motion, no novelty | Nothing animates in, nothing reveals on scroll, and never put a number behind an animation. |
Three that show you have actually built for finance
Definitions live in the interface, not in a wiki. Hover or click on “headcount” and it tells you whether contractors are in, whether it is at period end or average, and who owns the definition. Every finance disagreement is a definitions disagreement wearing a data costume, and putting the definition next to the number is the cheapest fix in the entire domain.
History has to be honest about restatement. When a reorg happens, does the view restate the past under the new structure, or preserve what was true at the time? Both are legitimate and they answer different questions — but the interface has to say which one it is doing, and most do not. Raising this unprompted is a strong fluency signal.
Design for the close, not for the average Tuesday. Finance tools get used hardest in a compressed window under deadline pressure, often by someone who does this once a month and has forgotten the flow. Optimise for the person who is late, interrupted, and about to be asked why the number moved.
The person who defends the number
One idea, worth keeping as a spare sentence for any design question you have not prepared.
“The user I design for in finance isn't the person reading the number — it's the person who has to defend it. If they can't see where it came from and as of when, they'll rebuild it in Excel, and then you've got two numbers and an argument.”
It generalises. It explains traceability, as-of stamps, export, definitions and honest states in one sentence, and it is a design principle rather than a feature list — which is the register she works in.
The prototype contract
Prototyping is the part of your scope that both interviewers care about, for opposite reasons. She fears you will demo something to an exec and create an expectation her team cleans up. The build lead fears the same demo becomes an unspoken commitment to ship. One rule answers both.
“I say what it is before I open it — disposable, nothing is built, the numbers are fake. I make it look unfinished on purpose, because a polished screen creates a date in someone's head whatever I say. And nothing goes upstream that the build team hasn't seen first.”
- “Before I open it” — the framing has to precede the demo. Afterwards is too late; the expectation forms in the first ten seconds.
- “Look unfinished on purpose” — the concrete practice. It is what makes the answer sound like a habit rather than a policy.
- “Nothing goes upstream unseen” — the clause that reassures both of them, and the one to keep if you only keep one.
Say a recognisably identical version of this to whichever interviewer asks. It is the answer most likely to be compared between them.
If she asks about your design process
Keep it small and concrete rather than naming a methodology. A method with four named phases invites her to test all four.
- Watch, do not ask. Twenty minutes of someone doing the real task beats an hour of “what would you like it to do”. Workarounds are the requirements.
- Straw-man, never a blank page. Reacting is cheap; inventing is expensive. Bring something wrong on purpose and let them correct it.
- Test the task, not the opinion. Hand it to five people, give them a real task, stay quiet. Five is usually enough to find the structural problems.
- Freeze the states before the pixels. Empty, loading, stale, partial, error, too-much-data. Agreeing these before anyone estimates is where most of the rework hides.
Four steps, each with a reason and none of them branded. If she pushes on any one of them you have a specific answer, which is not true of a methodology name.
Traps
Answering with consumer instincts. Simplify, delight, reduce clicks, beautiful whitespace. All wrong here, and she will hear it immediately.
Claiming research you did not do. If you have not run usability sessions, say what you did instead — sat with users, watched a close, read support tickets. Those are legitimate evidence. Inventing a research practice is testable and fails on the first follow-up.
Describing the redesign as a rescue. Someone on her side of the org may have designed the thing you are describing, or something like it. Describe the problem structurally and without contempt for whoever built it — how you talk about absent colleagues is itself the assessment.
Going long. Design is the subject you are most likely to over-talk because it is the one you enjoy. Ninety seconds, then stop and let her ask.