The forward-deployed design brief: a template for the first client week

In this guide

1. The useful starting point
2. Start with the workflow, not the requested screen
3. Copy this engagement brief
4. A first-week working sequence
5. Example: a confusing approval queue
6. Write acceptance criteria for learning and delivery
7. Close with a usable handoff
8. Build on the earlier guides
9. Questions you might be asking
10. Sources and further reading

The useful starting point

Write a brief around one customer workflow, the uncertainty to investigate, and the evidence needed for a decision. Agree on access, responsibilities, exclusions, and handoff before committing to a solution.

A forward-deployed designer needs enough proximity to understand real work and enough clarity to avoid becoming the person who handles every design request. The first brief should establish both. It is a working agreement that the client, designer, product partner, and engineering partner can revise as they learn.

The template below is a suggested practice. Embedded roles differ across organizations, so use the responsibilities that fit the engagement rather than treating the title as a standardized job description.

Start with the workflow, not the requested screen

Ask the client to walk through the last real instance of the problem. Who triggered the task? What information was available? Where did someone pause, ask for help, or leave the product? Include the workaround and the consequence of an error.

A request for a new dashboard might conceal a missing data source or an unclear decision. Record the requested solution separately from the observed problem so the team can investigate without promising the wrong artifact.

Copy this engagement brief

• Workflow and people: Who is trying to do what, in which environment, and how often?
• Current difficulty: What observable event makes the workflow confusing, slow, inaccessible, or unreliable?
• Evidence available: Which interviews, observations, support records, or product events can we review? What permissions and participant consent are needed?
• Main uncertainty: What must we learn before choosing a solution?
• Smallest useful scope: Which step will we examine first, and what is explicitly outside this engagement?
• Decision rights: Who recommends, who approves, and who resolves a product or engineering constraint?
• Learning deliverables: What workflow map, prototype, findings, or decision record will make the next choice possible?
• Handoff and ownership: Who will implement, maintain, and evaluate the result after the designer leaves?

Assign an owner and date to unresolved access questions. Do not make access to real participants an invisible assumption in the schedule.

A first-week working sequence

Use the first day to agree on scope and observe the existing workflow. On the second, map the steps and review the available evidence with the people doing the work. On the third, identify the riskiest assumption and make the smallest prototype that can investigate it.

Use the remaining time to evaluate that prototype with suitable participants, discuss what changed, and agree on the next step. This is an illustrative sequence, not a guarantee that recruitment or research will fit into five days. If access is delayed, revise the plan openly.

Example: a confusing approval queue

In a hypothetical operations team, staff cannot tell whether a request needs attention or is waiting on another person. A designer observes the queue, maps the status definitions, and finds that two departments use the same label differently.

The first useful deliverable may be an agreed status model and a prototype of the handoff. A full visual redesign would be premature. The engagement brief changes to include the person who owns the status data and the team responsible for exceptions.

Write acceptance criteria for learning and delivery

Before the review, agree on the questions the evidence should answer. Can a participant identify the next action? Do they understand why a request is blocked? Can they recover from a mistaken selection? Record task context and limitations alongside what you observed; a small exploratory study does not establish a population-wide success rate.

For delivery, include accessible interaction requirements, content rules, data dependencies, edge cases, and the unresolved questions engineering must not silently guess. Keep a decision log explaining why the chosen direction differs from earlier sketches.

Close with a usable handoff

Walk the receiving team through a normal case and an exception. Ask them to explain how they would change the design when the underlying workflow changes. Agree on who will inspect the result after release and where new feedback goes.

The Agile Manifesto's emphasis on customer collaboration and responsiveness is compatible with this brief. The brief is meant to make adaptation easier by keeping the goal and ownership visible.

Build on the earlier guides

• The forward-deployed designer’s first 30 days
• Improve your design process with AI: find the rework first
• Agile design when AI makes prototypes faster

Questions you might be asking

Is this a statement of work?

It can inform one, but it does not replace agreed commercial terms. Use it to make the working scope, assumptions, and learning plan clear.

What if the client already knows the solution?

Record the requested solution, then ask what evidence supports it and which assumption would be most costly to get wrong.

Sources and further reading

• Principles behind the Agile Manifesto

Sources checked October 16, 2026. Tool features and plan availability can change; review the linked publisher documentation before connecting an account.

Put one idea to work

Take the next step with a practical worksheet, a clear research question, and a standard you can use to review the work.

Explore design worksheets →Explore more from UX Design Coach