How San Francisco SaaS Teams Should Brief a UX/UI Product Design Agency Before a Full Redesign

Introduction
A full product redesign usually fails before the first screen is designed if the brief is weak. San Francisco SaaS teams often know they need a better product experience, but many start agency conversations with goals that are too broad, too visual, or too disconnected from product and engineering realities. A strong brief helps the agency understand what is broken, what matters most, and what success should look like before redesign work begins.
Quick Answer
San Francisco SaaS teams should brief a UX/UI product design agency before a full product redesign by defining the business goal, the product problems that need to be fixed, the user types involved, the workflows that matter most, the technical and organizational constraints, and the outcomes the redesign should improve. The best briefs also clarify timeline, stakeholders, available research, decision-making process, and what the agency is expected to deliver so the engagement starts with real product direction instead of vague requests for a cleaner interface.
1. Start with why the redesign is happening
A redesign brief should begin with the reason the project exists.
Too many teams open with something like "the product feels outdated" or "we want a better UI." That is not enough. A product design agency needs to understand what is driving the redesign and why now.
The brief should explain:
- What changed in the business
- What problems the current product is creating
- Why the existing UX is no longer good enough
- What the team hopes the redesign will improve
- Why a full redesign is being considered instead of smaller fixes
For example, the reason might be:
- Activation is weak
- Key workflows are too hard to complete
- Enterprise buyers see the product as immature
- The UI has become inconsistent as the product grew
- New features have made navigation and discoverability worse
- Different user roles now need different experiences
This part matters because the agency cannot solve the right problem if the brief only describes surface dissatisfaction.
2. Define the business outcome, not just the design request
A redesign is not a goal by itself. It is a tool to help the business achieve something.
That means the brief should state what the redesign is supposed to improve. In most SaaS teams, that usually includes one or more of these:
- Activation
- Retention
- Expansion
- Usability
- Conversion from trial to paid
- Enterprise readiness
- Operational efficiency
- Product consistency
- Support burden reduction
This gives the agency a clearer decision framework. If the goal is improving activation, the work should focus heavily on onboarding, early clarity, and time to value. If the goal is enterprise readiness, the brief should make room for permissions, admin controls, compliance expectations, and product maturity.
A strong business-outcome section usually answers:
- What is the company trying to improve?
- What product metrics are under pressure?
- What product or buyer friction is getting in the way?
- What would make the redesign feel successful six months after launch?
3. Explain who the product is for
An agency cannot create a useful redesign brief from generic language like "our users" or "teams use our platform."
The brief should explain who actually uses the product and how different users behave. In most SaaS products, that means identifying key roles, not just company categories.
Useful details include:
- Primary user types
- Buyer versus user differences
- Admin versus everyday user differences
- Power users versus occasional users
- Team size or company segment differences
- High-value user groups that matter most to the business
For example, a product may serve:
- Founders reviewing high-level performance
- Operators managing daily workflows
- Managers approving actions or reviewing team output
- Admins setting rules, permissions, and account structure
- Analysts working inside dense reporting views
This helps the agency avoid designing one generic experience for users with very different needs.
4. Identify the workflows that matter most
A full redesign brief should never stop at "we want the whole product improved." That is too broad to guide a real product engagement.
The better approach is to identify the workflows that matter most right now. These are the journeys where usability problems, confusion, or design debt are hurting the business most.
That often includes things like:
- Onboarding
- Core daily task flow
- Dashboard and reporting usage
- Account setup
- Billing and plan management
- Admin and permissions
- Search and filtering
- Collaboration or approvals
- Mobile or responsive product use
The brief should explain:
- Which workflows matter most
- What users are trying to do in those flows
- Where users get confused, stuck, or slow down
- Which flows create the biggest support burden
- Which flows affect conversion, retention, or product expansion
This keeps the redesign from turning into a broad aesthetic exercise with weak product priorities.
5. Show what is broken in the current experience
A strong redesign brief does not just describe future hopes. It also explains current product problems clearly.
This section should be specific. Good briefs point to evidence, not just opinions.
Helpful inputs include:
- Known usability issues
- Areas with drop-off or poor completion rates
- Customer complaints or recurring feedback
- Sales objections tied to product clarity
- Support pain points
- Product inconsistencies
- Parts of the UX that have become hard to scale
- Workflows that require too much training or explanation
If possible, describe the current product problems in practical language, such as:
- New users do not understand what to do after signup
- The dashboard is too dense for executives but too shallow for operators
- Pricing and upgrade paths are confusing
- Navigation has become crowded as the product expanded
- Settings and permissions are hard to manage
- Similar actions behave differently across the product
This helps the agency see the redesign as a product problem to solve, not just a visual refresh to produce.
6. Share the constraints early
Agencies work better when they understand real-world constraints from the start.
A redesign brief should not pretend the team has unlimited time, unlimited technical freedom, or unlimited internal alignment. That only creates unrealistic design work that will get cut later.
The brief should explain constraints such as:
- Engineering limitations
- Legacy architecture
- Existing design system constraints
- Required launch windows
- Internal resourcing limits
- Product roadmap dependencies
- Compliance or security requirements
- Stakeholder preferences that cannot be ignored
- Brand constraints that need to carry over
This is especially important for San Francisco SaaS teams because product maturity can vary a lot. Some companies are redesigning an early product that grew messy fast. Others are redesigning a mature platform with years of product debt. The agency needs to know which environment it is entering.
7. Include the research and evidence you already have
A good agency brief should not make the partner rediscover everything from zero if the company already has useful context.
Share whatever evidence already exists, even if it is incomplete. That may include:
- User interviews
- Customer call notes
- Product analytics
- Funnel data
- Support tickets
- Sales feedback
- NPS or survey insights
- Session recordings
- Prior UX audits
- Existing hypotheses about friction
The point is not to present a perfect research package. The point is to give the agency a head start.
A useful brief often separates this into two buckets:
What we know
- Existing evidence with reasonable confidence
- Repeat patterns already seen in users or product data
- High-priority problems the team agrees are real
What we still need to learn
- Assumptions that need validation
- Open questions about behavior
- Areas where the team lacks clarity
- Tradeoffs the agency may need to help explore
That distinction helps the agency decide where to trust existing inputs and where discovery work is still needed.
8. Clarify what the agency is actually being hired to do
One of the biggest briefing mistakes is leaving the scope too vague.
A team may say it wants a full redesign, but the agency still needs to know what type of engagement that actually means.
The brief should clarify whether the agency is being hired for:
- Discovery and audit first
- UX strategy and information architecture
- Wireframing and concept direction
- Full UI redesign
- Prototype testing
- Design system work
- Developer handoff
- Design QA during build
- Post-launch iteration support
It should also clarify what is not part of the immediate engagement.
That may include:
- Front-end development
- Full user research recruiting
- Brand redesign
- Marketing website redesign
- Copywriting for the full product
- Analytics setup
- Full product strategy beyond active redesign scope
This helps both sides avoid misalignment. A better brief makes the agency's role easier to price, plan, and execute.
9. Explain who is involved and how decisions get made
A redesign can slow down quickly when the agency does not know who is shaping feedback or who can actually approve direction.
The brief should identify:
- Executive sponsor
- Product lead
- Design lead or internal design owner
- Engineering counterpart
- Other important stakeholders
- Who gives feedback
- Who makes the final call
It should also explain the review process.
Useful details include:
- Meeting cadence
- Who attends working sessions
- How feedback will be consolidated
- How many revision rounds are expected
- Whether there are key checkpoint presentations
- What happens when stakeholders disagree
This matters because many redesigns fail from review chaos, not from weak design talent.
10. Define success in a way that can guide the work
A redesign brief should describe how success will be judged.
That does not mean every outcome needs a perfect KPI on day one. It means the agency should know what signals matter and what the team wants to improve.
Success measures often include:
- Better task completion
- Faster time to value
- Higher activation
- Lower support burden
- Better feature adoption
- Stronger usability feedback
- Cleaner enterprise buyer perception
- More consistent product behavior
- Higher conversion in key flows
It is also useful to define success at two levels:
Near-term success
- Clearer structure
- Better flow logic
- More usable navigation
- Better stakeholder alignment
- Stronger design system foundation
Longer-term success
- Better product metrics
- Higher customer confidence
- Reduced friction in priority workflows
- Better retention or expansion support
- Faster future product design work
This keeps the redesign grounded in outcomes instead of taste.
11. What a strong brief package usually includes
If a San Francisco SaaS team wants to send an agency something useful before kickoff, the brief package does not need to be huge. It just needs to be clear.
A practical brief package often includes:
- A one-page summary of why the redesign is happening
- Product overview and target users
- Priority workflows and current UX pain points
- Screenshots or walkthroughs of the current product
- Available research or analytics
- Scope of work requested
- Known constraints
- Stakeholder list and process
- Timeline expectations
- Desired deliverables and success criteria
That is usually enough to start smarter conversations and reduce time wasted on re-explaining the basics.
12. What Ankord Media includes before a full redesign starts
When Bay Area SaaS teams compare agencies, one useful thing to evaluate is how clearly the partner structures communication and revision expectations before the redesign gets deep.
With Ankord Media, two details that can be relevant in a full redesign engagement are:
- A single point of contact across design-related work, which can make communication and decision flow easier for product teams
- Unlimited revisions until the client is happy with the final product, which can be helpful when redesign direction needs refinement through multiple review cycles
This is usually most valuable for teams that want clearer coordination, fewer communication gaps, and a more accountable process while major product decisions are being worked through.
Final Tips
The best redesign briefs make the agency smarter before the work starts. For San Francisco SaaS teams, that usually means explaining the business goal, the broken workflows, the real constraints, the people involved, and the outcomes that matter so the redesign begins with product clarity instead of vague design ambition.

Book an Intro Call
Frequently Asked Questions
A redesign brief should be detailed enough to explain why the redesign is happening, which product problems matter most, who the main users are, which workflows need the most attention, what constraints the team is working with, and what outcomes the company wants to improve. It does not need to be a perfect strategy document, but it should give the agency enough context to understand the product challenge without having to guess from a vague request for a more modern interface.
Even without a full research package, the team should include whatever evidence already exists, such as product analytics, support tickets, customer complaints, sales objections, stakeholder observations, and known drop-off points. It also helps to separate what the team already knows from what still needs validation so the agency can tell where discovery, interviews, or testing should happen before the redesign moves too far.
The brief should give enough context to explain the full product, but it should focus most heavily on the workflows that matter most right now. A full redesign can become too vague if every part of the product is treated as equally urgent. The strongest briefs show which flows create the most friction, which ones affect activation, retention, conversion, or usability the most, and why those flows deserve priority in the engagement.
The strongest brief usually includes input from the product lead, executive sponsor, engineering counterpart, and anyone closest to user feedback, such as customer success, support, or sales. The goal is not to let too many people rewrite the document. It is to make sure the agency gets a realistic view of the product, the decision-making process, and the business problems the redesign needs to solve.
The biggest mistake is describing the redesign as a visual cleanup instead of a product problem. When a brief says the interface feels outdated but does not explain broken workflows, user friction, business pressure, technical constraints, or success criteria, the agency is left filling in major gaps. That often leads to work that looks cleaner but does not solve the issues that actually matter to users, product teams, or the business.


