Selling UX work means helping a client understand which problem is worth addressing, what evidence is missing and what a useful engagement would deliver. The conversation should connect the client's business concern with the people who use the service. A clear UX story can organize that explanation, but it should not turn uncertain outcomes into promises. These ten tips focus on earning an informed decision about scope and next steps.
Original client-agreement illustration, retained as a metaphor rather than evidence of a transaction or result.1. Start with the problem the client needs to solve
Ask what prompted the conversation and what happens when the problem occurs. A request for a redesigned homepage may conceal a difficulty finding a service, completing a form or understanding eligibility. Distinguish the paying client's concern from the end user's task, then investigate how they connect. The GOV.UK discovery guidance recommends reframing a proposed solution as a problem and agreeing what is outside it. Use that discipline in a proposal: state the reported problem, the assumptions and what you need to learn before recommending a solution.
2. Build trust through relevant work and transparent boundaries
A portfolio is most useful when it shows work relevant to the client's situation. Explain your role, the constraints, the decisions and the evidence available at the time. Separate an observed outcome from a hoped-for benefit, and do not imply that you personally produced a whole team's result. Be equally clear about what you cannot yet know. A client can make a better decision when the proposal describes access needs, dependencies and review points. Trust grows through those specific commitments and how you handle them, rather than through broad claims that your process always produces a better product.
3. Use testimonials and references accurately
References can help a client understand what it was like to work with you, but they are not the only evidence of capability. Use testimonials with permission, preserve their meaning and identify the work they concern. A positive comment about communication does not establish a measurable increase in conversion. If a client asks for a reference, agree the introduction and the information that may be shared. Where confidentiality limits what you can show, explain that boundary and use an appropriately anonymized account of the process. Do not manufacture quotes, customer logos or results to make a portfolio appear more complete.
4. Tailor the presentation to a decision
Focus a UX presentation on one decision: approve a discovery phase, agree access to users, or select a proposed scope. Organize the material around that decision and the audience's responsibilities. A sponsor may need to understand the business concern and cost of delay; a product lead may need to see dependencies and deliverables. Keep the presentation concise enough for discussion and provide detail that people can review afterward. There is no universal attention-span rule that makes a presentation effective. Plan breaks and format changes around the actual meeting, and leave time for questions that could change the scope.
For a membership service, a concise proposal might say: Reported concern—members struggle to renew. Evidence needed—observe the renewal task and review support questions. Proposed scope—a renewal prototype review. Decision—approve a bounded discovery phase. The reported concern is a hypothesis to investigate, not a proven abandonment rate.
This kind of decision board gives a meeting a concrete purpose. Add the expected deliverable, review owner and exclusions to the written proposal. Keep any budget, schedule and access assumptions explicit rather than allowing an attractive mockup to imply that the entire service will be rebuilt.
5. Listen before prescribing the work
Consultative selling starts with questions and careful listening. Ask the client to describe a recent example, who was affected and what the team has already tried. Repeat your understanding back in plain language so that misunderstandings surface early. Client interviews and user research answer different questions: a stakeholder can explain business constraints, while people using the service can reveal task difficulties the organization has not seen. Treat both as evidence with a context. Do not accept every requested feature as the solution, or dismiss it without first understanding the need it is meant to address.
6. Make the working relationship tangible
Past clients' experiences can provide context, but a new client also needs to understand how the engagement will work. Show an example of a decision record, a review agenda or a suitably anonymized deliverable. Explain who will be involved, how feedback is handled and when the client needs to make a choice. A small, clearly bounded discovery engagement may be appropriate when the problem is still uncertain. It should have its own purpose and useful outcome, not serve as a disguised promise that a larger redesign is inevitable. Be explicit about what happens if the evidence suggests stopping or changing direction.
7. Respect stakeholders’ time without excluding them
Do the preparation that makes participation worthwhile. Send the question to be decided, the evidence to review and the requested input before a meeting. Identify the people who own decisions and the specialists whose knowledge affects the work. Busy stakeholders still need a role: silently deciding their constraints for them can create expensive misunderstandings. Use a concise update that distinguishes completed work, open questions, risks and the next decision. Agree review windows and escalation routes, and record who will provide access to users, content or technical information. These are UX project dependencies, not administrative details to leave until the end.
8. Use conversation to make wireframes meaningful
Wireframes and prototypes can support a conversation when people know what they are looking at. Introduce the user's goal, the relevant state and the decision under review before asking for reactions. A Mockitt prototype can make a proposed task path visible, but the artifact should not stand in for an explanation. Ask whether the sequence addresses the problem and which assumptions remain unresolved. If a client comments only on colors, clarify whether visual styling is part of the current review. Sketches, workshops and written walkthroughs can all be useful depending on the question and the participants.
9. Connect each recommendation to evidence
Use the evidence that is relevant to the claim. Analytics may show where a journey ends without explaining why. An interview can reveal a concern without measuring its frequency. A task observation can reveal a difficulty without proving a population-wide rate. State these limits when presenting a recommendation. If the proposal includes a business outcome, explain how it would be measured and what else could affect it. Avoid attaching a revenue forecast to a prototype just because the interface looks clearer. When evidence is missing, propose a way to reduce the uncertainty and say what decision that work will support.
10. Choose direct discussion that fits the people and context
Face-to-face conversation can help people ask questions and explore an idea together. A well-facilitated remote session can do that too. Choose the format according to access needs, location, the task and the sensitivity of the discussion. Give participants a way to contribute before or after the meeting if live discussion is not enough. For user research, select the method for the question rather than using it as a sales demonstration. For client reviews, end with a clear record of decisions, unresolved concerns and owners. Direct contact is useful when it improves understanding, not simply because everyone appears in the same room.
Conclusion
A useful proposal makes the problem, evidence, scope and next decision clear. The ten tips above can improve how you explain the work and manage expectations, but they do not guarantee a sale or a commercial result. Before sending a proposal, check that a client can tell what they are buying, what they must contribute, what is excluded and how the next decision will be made. Keep the client's concern and the user's task connected throughout the engagement, and revise the plan when new evidence changes your understanding.
