A team starts designing screens before understanding the product goals, users, or constraints. Halfway through development, requirements change, edge cases appear, and everyone realizes the UI doesn’t match the real-world workflow. This leads to rework, design debt, and frustrated stakeholders.
Before discussing screens, get clear on why the product exists and what “good” looks like.
In the initial kick-off, aim to answer these early:
👉 If you don’t understand business priorities, you can’t prioritize UX decisions properly.
Design scope depends heavily on who is using the system.
Capture:
| Area | Questions |
| User types | Internal staff, brokers, customers, admins? |
| User roles | What permissions differ? |
| Technical ability | Highly technical or non-technical? |
| Frequency of use | Daily operational tool or occasional system? |
| Environment | Desktop? Mobile? Field work? Low bandwidth? |
👉 If we don’t know the users, we can’t know how much UX is required.
An internal admin tool used daily by trained staff requires very different UX effort compared to a customer-facing public product.
We must know what we are replacing or evolving.
Ask:
This helps identify:
Not every project needs the same depth of design.
Characteristics
Typical Deliverables
Characteristics
Typical Deliverables
Characteristics
Typical Deliverables
👉 Over-designing wastes time. Under-designing causes rework. The review determines the correct level of depth.
Before starting UI work, write a short scope summary that everyone agrees on.
Confirm in writing:
This prevents the classic:
“I thought design included...”
👉 Alignment early is cheaper than correction later, and it protects your relationship with your client.
A proper design spec review:
Good UI is not about making things look nice.
It’s about designing the right solution at the right level of effort.