The forward-deployed designer’s first 30 days

In this guide

1. The useful starting point
2. Days 1–5: observe the work as it happens
3. Days 6–10: choose a bounded problem
4. Days 11–20: test a usable change
5. Days 21–30: make the team less dependent on you
6. A field-brief prompt
7. What to put in your case study
8. Continue with a related guide
9. Apply this with a practical template
10. Questions you might be asking
11. Sources and further reading

The useful starting point

A forward-deployed designer works close to a customer implementation, connecting user needs, design decisions, and delivery. Begin by observing the workflow, agree on one outcome, test a small change, and leave reusable evidence and patterns.

The title forward-deployed designer can describe different jobs. Gamma's role description emphasizes customer design work, education, and product feedback. Other organizations may emphasize workflow discovery or implementation. Read the actual responsibilities before assuming the title means on-site work, production coding, or a particular level of seniority.

This guide proposes a 30-day approach for an embedded designer joining a customer team. It is a practice framework, not a claim that every employer uses this model. For the broader role overview, see our forward-deployed designer skills and portfolio guide.

Days 1–5: observe the work as it happens

Meet the sponsor, the people doing the task, the implementation engineer, and the person who will support the system. Ask each what a successful outcome looks like. Record disagreements; they often explain why a feature request has become urgent.

Observe a few real tasks with permission. Follow the work across spreadsheets, messages, and unofficial workarounds. Ask what happens when the usual path fails. Do not treat the sponsor's preferred solution as the problem statement.

Write a short evidence note after each observation. Separate what you saw, what someone told you, and what you infer. AI can help organize those notes, but generated personas or simulated interviews cannot establish what these customers need.

Days 6–10: choose a bounded problem

Agree on one task, the affected users, a baseline observation, and a decision the team can make within the engagement. Name constraints such as permissions, platform components, supported devices, and available engineering capacity.

Create a boundary between a local configuration and a change to the shared product. A customer-specific request may be useful without belonging on the platform roadmap. Keep the reason for that classification visible so the customer does not mistake a prototype for a future commitment.

Days 11–20: test a usable change

Imagine a hypothetical service team that cannot confidently assign incoming cases. The request is for a more colorful dashboard. Observation reveals that people do not know which records need attention or why.

The designer prototypes a queue showing the reason for attention, the next action, and who owns it. An engineer checks that the required data and permissions exist. People who perform the task try the prototype using representative cases, including missing information and a reassigned case.

Record task completion, hesitation, and incorrect actions. Small qualitative sessions reveal problems; they do not prove a population-wide conversion improvement. If the change ships, plan how production evidence will be collected and who will review it.

Days 21–30: make the team less dependent on you

Deliver the tested flow, state coverage, component decisions, evidence notes, and unresolved questions. Walk through an exception with the support owner. Ask someone else to explain the workflow back to you and make a small update using the handoff materials.

The lasting output is not only a set of screens. It is an understandable system of decisions that the customer and product team can continue to improve.

A field-brief prompt

Organize these approved observation notes into a field brief. Separate observations, reported needs, assumptions, and requested solutions. Identify one bounded user task, constraints, competing explanations, and a testable change. List evidence gaps. Do not invent user quotes, research findings, or roadmap commitments.

What to put in your case study

Show the original ambiguity, the evidence that changed your direction, the constraint you worked within, and what happened when people tried the result. Explain your responsibility and your collaborators' contributions. If outcome data is unavailable, say what was tested and what remains unknown. Honest field judgment is more persuasive than an invented impact number.

Continue with a related guide

• Improve your design process with AI: find the rework first
• Agile design when AI makes prototypes faster

Apply this with a practical template

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

Questions you might be asking

Must a forward-deployed designer code?

Some roles include implementation or coding, while others emphasize configuration, education, or design. Check the actual role scope.

What makes a useful handoff?

Evidence, tested states, decisions, reusable patterns, open issues, and a named team capable of maintaining the work.

Sources and further reading

• Gamma: Forward Deployed Designer role

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