A redesign can be the right investment. But it is a poor first decision when the team cannot yet name the journey that is failing, the evidence behind that concern, or the question a new design must answer.
Before changing screens, decide what you need to learn. That keeps a redesign brief from becoming a collection of opinions, screenshots and feature requests.
Start with the decision, not the deliverable
Write one sentence: “After this work, we need to decide whether to ___.” Examples: fix a specific onboarding step; test whether new users understand a pricing or setup choice; or redesign a known journey around an agreed outcome. If the sentence is only “make the product feel more modern,” the next step is discovery, not a broad UI refresh.
The evidence ladder
1. Product signals tell you where to look
Support themes, reviews, funnel changes and sales-call questions can reveal a journey worth investigating. Keep the record bounded: the task, the audience, the location in the product and the date range. A signal is a prompt to investigate; it is not a diagnosis of cause.
2. An expert review helps when the cause is unclear
Use a UX audit when a live product has repeated signs of friction but the team needs an outside, structured view before deciding what to change. A useful audit makes the reasoning inspectable: the task reviewed, likely friction, affected flow, severity and recommended next action. This is different from proving how representative people behave. It is an expert-led diagnosis that narrows the risk and gives the team a priority order.
3. User research answers behaviour questions
When the key unknown is what people understand, expect or do in a real task, plan usability testing or another appropriate research method. GOV.UK describes user research as a way to understand needs across discovery, alpha, beta and live work, and separates methods such as interviews, observation and moderated usability testing. GOV.UK: User research
An audit can improve the research plan. It can surface the moments worth testing and assumptions that need challenge. It cannot replace observation with representative users.
4. Accessibility needs deliberate evidence
Treat accessibility concerns as part of the product decision, not visual polish. W3C recommends evaluating accessibility early and throughout design and development, and notes that tools help but cannot by themselves determine whether a site meets accessibility standards; knowledgeable human evaluation is needed. W3C WAI: Evaluating Web Accessibility
A five-question redesign brief
- Which user and task matter most? Name the journey, not a page template.
- What has been observed? Separate direct evidence from team interpretation.
- What do we not know? List the hypotheses that need review or research.
- What must the new design make easier? Define a task outcome, not an aesthetic preference.
- How will we decide? Agree who chooses the next step and what evidence will be sufficient.
Choose the smallest useful next step
- UX audit: repeated friction with no shared explanation.
- Usability testing / research: the team disagrees about what users understand or need.
- Focused redesign: the problem and desired change are already understood.
- Strategy / discovery: broader product direction is unsettled.
The sequence can be audit, then research, then redesign. It can also be a focused redesign when the evidence is already strong. The point is to match the work to the decision—not force every problem through the same service.
What to bring to the first conversation
Bring one critical flow, anonymized recurring signals, product context, constraints and the decision the team must make. A bounded question is more valuable than a long list of screens.
Pengreen helps startup and SaaS teams turn unclear product friction into a practical next step: an expert UX audit, focused research, or product design work. Explore Pengreen’s UX audit approach or the startup and SaaS service.
EN-US
PT-BR