What Your Product Design Consultant Must Clearly Document Before Day One Starts

In nearly every failed design consulting engagement, there’s a turning point the Foundey can later pinpoint the exact moment things started to unravel. More often than not, it happens in that window between the initial sales call and signing the contract, when the Foundey chooses to rely on verbal assurances instead of securing clear, written commitments.

The design consultant said all the right things. They understood the problem. They had worked on similar products They described a process that sounded exactly right The founder felt confident moving forward with the Product Designer collaboration. The contract said the agency would deliver "UX improvements across the core product flows." Eight weeks later, the invoice arrived—along with polished Figma files. But despite the effort, nothing in the product measurably improved.

The verbal commitments were never wrong. They were just never specific enough to hold the engagement to any standard beyond file delivery.

The document I am going to describe is what you request from any product design consultant before a single design decision is made. It is a one-page written commitment that transforms the engagement from a production relationship into an outcomes relationship.

Why Written Pre-Engagement Commitments Change Everything

When a product design consultant puts their intended approach in writing before the engagement begins, three things happen simultaneously.

First, the consultant is forced to move from general process description to specific problem analysis. Writing "we will redesign the onboarding flow" is easy in a sales call. Writing "we believe the onboarding completion rate is 31% because users encounter an OAuth permission request at step three without sufficient context for why it is necessary, and we intend to address this by redesigning step two to front-load the value explanation that makes step three feel logical rather than arbitrary" requires the consultant to have actually thought about your specific product.

Second, the quality gap between consultants becomes immediately visible. Ask three consultants for a written pre-engagement analysis and you will receive three documents that differ more than any three portfolio reviews would. The one who has actually thought about your product produces a specific document. The one who is applying a generic template to your product produces a general one

Third, the engagement has a reference document. When sprint three produces work that diverges from the original intent, the written commitment is the shared reference that resolves the disagreement. Without it, every disagreement about direction is an argument between memories of a verbal conversation

The Five Elements of the Written Pre-Engagement Commitment

Element 1: The Specific Problem Diagnosis

The consultant's written statement of what is wrong with the product, based on their review of your funnel analytics and session recordings not based on what you told them in the sales call.

This diagnosis must be specific. "The onboarding needs improvement" is not a diagnosis. "63% of users who complete account creation abandon the product before reaching the core value feature, and session recordings show the abandonment clustering at the data

source connection step where users encounter a third-party permission request without prior explanation of why it is necessary" is a diagnosis.

The specificity requirement filters for consultants who actually looked at your data. A product design consultant who cannot write a specific diagnosis before the engagement begins has not done enough pre-engagement analysis to produce an accurate diagnosis during the engagement regardless of how polished their services may appear.

Element 2: The Root Cause Hypothesis

Distinct from the diagnosis, the root cause hypothesis explains why the diagnosed problem exists. The same symptom (abandonment at step three) can have multiple root causes: the user does not understand what they are being asked to do, the user understands but does not trust the request, the user understands and trusts but lacks the technical information needed to complete the step.

Each root cause has a different design intervention. A consultant who writes a specific root cause hypothesis before week one has already done the analytical work that determines whether the eventual design intervention will address the right problem or solve the wrong one competently.

Element 3: The Success Metric

A single specific number that the consultant believes the engagement should move, stated as: current baseline, target improvement, measurement method, and measurement timeline.

"Current onboarding completion rate: 31%. Target: above 50%. Measurement: step-level completion tracking in Mixpanel for the redesigned flow. Timeline: measured across 300 trial signups after the new flow ships, approximately 6–8 weeks post-launch"

This element is the one most product design consultants resist including because it creates accountability they would prefer to avoid That resistance is information A consultant who is confident their diagnosis is correct and their proposed intervention is well-designed should be willing to state what they expect it to produce

Element 4: The Week-One Deliverable Description

What specifically will the consultant deliver by Friday of week one, in enough detail that you can evaluate whether it arrived.

Not "we will deliver initial designs." Specifically: "By Friday of week one, we will deliver a friction map of the current onboarding flow (specific UX problems at specific steps with session recording timestamps as evidence), a root cause analysis for the top-priority friction point, and three design concept directions for addressing the root cause."

Element 5: The Non-Design Variables List

An explicit list of factors outside the consultant's control that could prevent the target metric from improving even if the UI/UX Design intervention is correctly executed: acquisition channel mix changes, engineering implementation deviations from design specifications, marketing copy changes, pricing changes, or product updates to adjacent flows.

This list protects both parties It protects the consultant from unfair accountability for metric failures caused by factors they cannot control. It protects the founder from having a non-performing design engagement explained away by post-hoc non-design factors that were never specified in advance.

How to Request This Document Without Losing Good Consultants

The framing matters. Do not present the written pre-engagement commitment as a test or a contract negotiation. Present it as a shared alignment tool: "Before we start, I want to make sure we are both working from the same understanding of the problem and the same definition of success. Can you spend 30 minutes writing up your initial analysis based on the product access and analytics I shared, so we can review it together before the engagement begins?"

This framing makes the document a collaboration artifact rather than an accountability mechanism which it is both, but the first framing is more conducive to an honest, high-quality response.

A product design consultant who responds to this request with a comprehensive, specific document has demonstrated exactly the analytical quality you need throughout the engagement A consultant who responds with a polished but general document has demonstrated exactly the template-application quality you want to avoid.

Foundey produces this pre-engagement written analysis during their free Jam Session a live working session where their team reviews your product, identifies the highest-priority friction point, and writes up the diagnosis, root cause hypothesis, and proposed intervention direction before any contract is signed. Their client results including the

FuseAI story where a product launched in 30 days with a 40% click-through improvement begin with exactly this written foundation.

After the Written Commitment: How to Hold the Engagement to It

The written pre-engagement commitment creates a reference point but not automatic accountability. Three practices maintain the connection between the commitment and the work throughout the engagement

Weekly written check-ins, not just calls. After every sprint week, the consultant writes a brief update: progress against the committed deliverables, any findings that suggest the root cause hypothesis needs revision, and the specific measurement being set up for the post-launch evaluation period. Written updates create a paper trail that keeps the engagement honest in ways that verbal updates do not.

Root cause revision protocol. If the work during the engagement reveals evidence that the committed root cause hypothesis was wrong, the consultant writes a revised hypothesis before pivoting the design direction. This revision is shared with the founder with explicit acknowledgment that the original hypothesis was incorrect and a specific explanation of what evidence changed the analysis. This protocol prevents the engagement from quietly pivoting direction without acknowledging the change.

Post-launch measurement requirement. The engagement formally closes when the measurement data from the committed success metric has been collected and reviewed not when the Figma files are delivered. This single requirement changes the incentive structure of the engagement more than any other clause, because it keeps the consultant invested in the measurement outcome rather than the delivery outcome.

The UX Audit as the Foundation of the Written Commitment

The most accurate pre-engagement written commitments come from consultants who have access to a structured product audit before writing them. A UX audit conducted before the engagement begins gives the consultant the evidence they need to write a specific diagnosis, a validated root cause hypothesis, and a realistic success metric estimate.

Without the audit, the pre-engagement commitment is based on the consultant's initial impression of the product which is more accurate than pure intuition but less reliable than a systematic analysis of funnel data, session recordings, and user feedback.

For founders who want the written commitment to be maximally accurate, the engagement structure is: audit first, written commitment second, design execution third. This adds one week to the process and dramatically improves the accuracy of every written commitment element.

Conversion through design is the most achievable when the written commitment correctly identifies the conversion problem and correctly hypothesizes the design intervention. The written commitment is what makes this connection explicit and verifiable rather than implied and unmeasurable.

For AI-powered SaaS products, the pre-engagement written commitment should include a specific element: the AI interaction moments being targeted and the trust signals the design intervention will address Generic UX consultants who write AI product commitments without specifying trust dynamics are diagnosing AI products with frameworks built for deterministic software.

If you want to experience what a specific, evidence-based pre-engagement written commitment looks like applied to your product, Foundey's free session produces exactly this document during the call.