The quiet fear every client has when signing a design contract is this: I am about to pay a lot of money for three weeks of meetings, and then someone will show me a mood board.

It is a reasonable fear. "Discovery" is the single most abused word in this industry, and plenty of engagements really do spend three weeks producing nothing a client can use.

So here is the week-by-week version. Not the sanitized process diagram with five arrows — what genuinely happens, what you should have in your hands at each point, and the specific warning signs that an engagement is going sideways while there is still time to fix it.

Week 1: Getting to the truth, fast

Days 1–2: The kickoff, and what makes it useful

A good kickoff is not an introduction meeting. Introductions take four minutes. The rest of the session should be spent extracting things that exist only in your team's heads.

Expect to be asked: what have you already tried and why did it fail? Which decisions are genuinely open and which are locked? Who can approve work, and who merely has opinions about it? What happens to this company if this project succeeds — and what happens if it does nothing?

That last question matters more than it sounds. It is how a team calibrates ambition. A project that saves a struggling product gets different treatment from one that optimizes a healthy one.

Days 2–4: Audit and data archaeology

While you continue running your business, the team goes through what already exists. Every screen in the current product, documented. Your analytics, read properly — not just the headline conversion number but where sessions end, which paths get abandoned, and what mobile does differently from desktop. Your support tickets, which are the cheapest and most underrated source of UX insight in existence. Your competitors' flows, walked through end to end.

Days 4–5: User contact begins

Scheduling interviews takes longer than conducting them, so outreach starts in week one even if conversations happen in week two. If the engagement includes research and nobody has asked you for user introductions by day five, something is wrong. Say so.

What you should have by the end of week 1: a written audit of the current experience, an analytics summary with the drop-off points identified, and a revised project brief reflecting what was learned in kickoff. That revised brief should differ from the original. If it does not, nobody listened.

Red flag: a week-one deliverable that is mostly process diagrams and timelines. You already know the timeline. You are paying for findings. Any team offering serious UI UX design services should be able to tell you something about your own product by day five that you did not already know.

Week 2: Finding the actual problem

Days 6–8: Research and synthesis

User interviews happen — typically five to eight for a focused engagement. Five sounds too few to people encountering research for the first time. It is not. By the fifth conversation, the major patterns are repeating. Twenty interviews produce more confidence, not more insight, and the budget is better spent elsewhere.

Usability testing on the existing product runs alongside. This is often the most uncomfortable part of the engagement for clients, because watching a real person fail to complete a task on your product is genuinely painful. It is also the moment the project becomes real. Ask to watch at least one session live. Not a recording — live. Nothing else changes a team's mind as quickly.

Days 8–10: Defining the problem

Synthesis is where the work either earns its fee or does not. The team turns a pile of observations into a small number of clearly stated problems, in priority order, with evidence attached.

The deliverable here is deceptively simple: a short document that says here is what is actually wrong, here is how we know, and here is what it is costing you. Often it contradicts the original brief. You hired someone to redesign the dashboard, and the finding is that the dashboard is fine but users never reach it because activation fails three screens earlier.

What you should have by the end of week 2: a prioritized problem statement backed by evidence, research findings in a form you can share internally, and agreement on which problem is being solved first.

Red flag: findings that match the original assumptions exactly, with no surprises. Real research always produces at least one thing nobody expected. If there are no surprises, the research was either skipped or shaped to confirm what was already believed.

Week 3: Making it concrete

Days 11–13: Divergent exploration

Multiple directions get explored — genuinely different approaches, not three versions of the same layout with different button colors. For a checkout problem, that might mean one direction that reduces steps, one that reorders them, and one that changes what is asked for entirely.

This phase is intentionally fast and intentionally rough. Low fidelity exists so ideas can be killed cheaply. A direction that dies on day twelve costs an afternoon; the same direction dying after full visual design costs two weeks.

Days 13–15: Convergence and first fidelity

One direction is chosen, with reasoning, and taken to a level you can react to properly. By the end of week three you should be looking at real screens — your actual content, realistic data, the states that matter including empty, loading, and error.

A prototype should be in your hands. Not a slide deck of screenshots. Something you can click through on your own phone, on your own time, without a designer narrating it.

What you should have by the end of week 3: explored directions with the rationale for the choice, high-fidelity screens for the core flow, and a clickable prototype you can share with your team.

Red flag: week three ends and you have seen no interface. Some engagements legitimately need longer discovery — enterprise systems, regulated industries, genuinely novel problems. But that should have been stated in week one, not discovered in week four.

The rhythm underneath all of it

Three things should be true throughout, and their absence tells you more than any deliverable.

You see work in progress, not just finished presentations. Big reveals are a sign of a team optimizing for applause rather than outcomes. Weekly working sessions where you see rough, unresolved work are how projects stay on course. Well-run UX engagements are boring in exactly this way — no surprises, because nothing was hidden.

Decisions get written down. Not just what was decided, but why, and what was rejected. Six months later when someone asks why the form works this way, that record is the difference between a confident answer and a redesign.

Engineering is in the room early. A designer who has not spoken to your developers by week two is designing in a vacuum, and you will pay for it in build time.

What to do with this

Take these three weeks and send them to whoever you are hiring. Ask: is this roughly your process, and if not, what is different and why?

The answer is enormously revealing. A team with a real process will tell you precisely where theirs diverges and defend the difference. A team without one will agree with everything you sent.

You will learn more from that single email than from any portfolio.