Cohesyve · Practice for candidates
Going for a UI Designer role? Find out how you'd actually score.
Run a UI Designer simulation built the same way employers build theirs, and get a full report showing exactly where you lost marks — before it counts.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
Overview
UI design assessments are typically a scoped interface task with a written rationale, sat under a timer. You are given a product context, a user need and some constraints, and asked to design a screen or short flow and explain the decisions. Employers use them because portfolio case studies are written after the fact and rarely reveal how someone handles the states, edge cases and ambiguity that make up most of the job. This page covers the formats and the scoring.
Why employers assess this role
Interface work in a portfolio is usually the best frame of a long collaboration, and its case study is written to look inevitable. A timed brief shows whether a candidate designs the empty and error states, works within an existing component system, and can defend a layout decision when asked.
What gets tested
The format
Duration
60–120 minutes
Question types
- Scoped screen or short flow design
- Written rationale for the decisions made
- Critique of an existing interface
- Component or design system extension task
Levels
Entry · Mid · Senior
What you'll be asked to do
Design a screen or flow
A defined user need and a limited scope — one screen, or two or three steps. The brief usually omits at least one important detail to see whether you name it.
- •Design the screen where a user reviews and confirms an action with consequences
- •Design a short flow for setting something up for the first time
- •Design a data-dense view where the user needs to find one item quickly
Handle the states
What the interface does outside the ideal case. This is the most commonly skipped and most heavily weighted part of a UI assessment.
- •Show the empty state for a view the user has not populated yet
- •Design the error case for a submission that fails after the user has waited
- •Show what the interface looks like while data is still loading
Work within a system
Supplied components or an existing product style. Assessors look for consistent reuse and a clear signal when you have had to create something new.
- •Build the screen using only the supplied component set
- •Extend the system with one new component and justify the need for it
- •Fix a supplied screen that uses the system inconsistently
Explain and defend the design
The written rationale, and sometimes a live follow-up. Employers use it to test whether the layout was reasoned or assembled.
- •Explain what the user should notice first on the screen and how the design achieves it
- •State the assumption you made about the user and what would change if it were wrong
- •Say what you would test first if this shipped
Cohesyve for candidates
Practise a UI Designer assessment before the real one
Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.
Sample tasks — and what strong looks like
Design the confirmation screen for an action the user cannot easily undo.
MidWhat strong looks like: Makes the consequence legible before the primary action, distinguishes the destructive path clearly, and does not rely on colour alone to carry the warning. Weak submissions present two visually equal buttons and a generic message asking whether the user is sure.
Design a list view where the user needs to find one item among many, and include the empty state.
EntryWhat strong looks like: Establishes a scannable structure with a clear primary column, provides a way to narrow the set, and designs an empty state that tells the user what to do next. Weak submissions design only the populated ideal case and leave the empty view as a centred message with no action.
Given a supplied component set, build a screen using it and flag anything you had to add.
MidWhat strong looks like: Reuses components as intended, resists inventing variants for convenience, and names the one genuine gap with a reason. Weak submissions quietly restyle existing components so the screen no longer matches the rest of the product.
Critique a supplied interface and set out what you would change, in priority order.
SeniorWhat strong looks like: Ties each problem to what the user is trying to do — a primary action competing with three others, contrast that fails at small size, grouping that implies a relationship that does not exist — and ranks them. Weak critiques list aesthetic preferences and describe the interface as cluttered without saying which relationships cause it.
How to prepare
- #1
Practise designing the empty, loading and error states as part of the main task rather than as an addition, since they are the most heavily weighted thing most candidates skip.
- #2
Work to a timer that includes the rationale, and treat the written section as a deliverable rather than as a note added at the end.
- #3
Rehearse building a screen from a supplied component set without adding new variants, which is closer to real product work than designing from scratch.
- #4
Learn the accessibility basics that recur — contrast ratios, target sizes, not carrying meaning by colour alone, and a sensible focus order.
- #5
Practise critiquing live interfaces in specific, ranked terms, connecting each problem to the user's task rather than to taste.
- #6
Prepare a habit of writing down the one thing the user should notice first, then checking whether your layout actually delivers it.
Common mistakes
Designing only the ideal populated state and omitting empty, loading and error views.
Introducing new components or type styles when the supplied system already covers the need.
Giving several actions equal visual weight so no primary action is apparent.
Relying on colour alone to signal status, warning or a destructive action.
Producing a polished visual with no rationale, so the reasoning has to be inferred.
Filling the screen with information because it was available, rather than because the user needs it there.
How it's scored
| Criterion | What strong looks like |
|---|---|
| Hierarchy and clarity | A single obvious primary action and a reading order that matches what the user came to do. |
| State coverage | Empty, loading and error cases are designed and useful, not placeholder text where a real state belongs. |
| System consistency | Components and type scale are reused as intended, with any addition identified and justified. |
| Accessibility | Adequate contrast, usable target sizes, meaning never carried by colour alone, and a sensible order for keyboard use. |
| Rationale | A concise written explanation naming the assumptions, the trade-offs and what the candidate would test first. |
Frequently Asked Questions
How much of the flow will I be asked to design?
Usually one screen or a short sequence of two to three. The scope is kept small deliberately so assessors can look closely at hierarchy, states and system use rather than at breadth.
Will I be given a design system to work in?
Frequently, because product design is mostly system work. When one is supplied, consistent reuse is marked, and creating a new component without flagging it is treated as a mistake rather than as initiative.
Do I need a prototype or is a static screen enough?
Static screens plus a description of the interaction are usually sufficient unless a prototype is explicitly requested. Time spent on prototyping polish rarely earns more than time spent on states and rationale.
How much does the visual finish matter?
It matters, but less than candidates expect. A clean, consistent screen with the states covered and the reasoning explained generally outscores a highly finished one that only shows the ideal case.
Should I do a practice run before a real assessment?
Yes — the pacing is what catches people out. Cohesyve provides three free scored assessments with a written report, so you can find out whether you consistently run out of time before the states and the rationale.
Practise another role
Cohesyve · Practice for candidates
Practise a UI Designer assessment now — free.
Three free scored assessments, a full report on every run, and a learning pathway built from what you got wrong. No card required.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
For hiring teams
Hiring for a UI Designer role? See how your applicants perform before you spend interview time.