Key takeaways
- Define the problems the redesign must solve before choosing a visual style.
- Review complete user journeys, including content, forms and error states.
- Agree the scope, success measures and release plan before production begins.
1. Define the reason for the redesign
A redesign can begin with a simple observation: the website feels dated, the app is difficult to use, or the brand no longer reflects the business. Those observations are useful, but they do not yet describe what the project needs to achieve.
Translate them into specific problems. Perhaps visitors cannot tell which service fits their needs. Customers may abandon a long form, struggle to find an order, or repeatedly contact support about the same task. Identify who experiences the problem, where it happens and what a better outcome would look like.
Choose a small set of priorities. A project focused on clearer enquiries needs different decisions from one focused on faster repeat purchases. Define the primary goal, supporting goals and anything that must continue working throughout the change.
2. Review the journeys people actually use
List the main tasks your audience comes to complete, then walk through them on the current product. Start from realistic entry points: a search result, a shared link, a notification or a returning customer's bookmark. The homepage is only one possible starting point.
Combine available analytics with conversations, support questions and direct observation. Numbers can show where people leave; watching someone attempt a task can help explain why. Treat a small research sample as useful evidence rather than a complete picture of every user.
- Where does the visitor need to make a decision?
- Is the information needed for that decision available?
- What happens if an input is wrong or a request fails?
- Can a returning user complete the task without unnecessary repetition?
Record the issues alongside screenshots so the design team can work from concrete examples.
3. Audit content before arranging the screens
Content is part of the interface. An attractive page still leaves visitors uncertain if the service description is vague, the pricing explanation is incomplete or the next action is unclear. Review what each important screen needs to communicate before deciding how much space it should occupy.
Create an inventory of existing pages, screens, documents and reusable assets. Mark each item for retention, revision, consolidation or removal. Check ownership: someone needs to verify product details, approve company claims and supply missing images or descriptions.
For a website, record existing addresses and valuable entry pages before changing the structure. Plan how visitors will reach replacement content if addresses change. For an app, review menu labels, onboarding instructions, notifications and transactional messages as part of the same experience.
4. Make usability part of the visual brief
Review the design at the sizes and conditions your audience is likely to use. Text should remain readable, controls should be easy to identify, and important information should not depend on a hover interaction. A desktop composition that looks balanced may need a different order on a small screen.
Include accessibility in the brief from the start. Consider keyboard navigation, visible focus, text alternatives, clear field labels and understandable feedback. Use colour alongside another cue when communicating an error or status. Give people a way to pause persistent motion and respect reduced-motion preferences.
Also review image weight, loading behaviour and slow connections. Agree which visual effects genuinely help explain the product. Evaluate accessibility and performance alongside the design, then verify the implemented experience rather than judging screenshots alone.
5. Separate visual changes from functional changes
A request for a new interface can conceal a much larger development project. A redesigned checkout might require payment changes. A new dashboard may depend on data the current backend does not provide. A simpler enquiry form may need new CRM routing and notifications.
List these dependencies before estimating the work. Identify the screens, reusable components, integrations and content types involved. Include loading, empty, error and success states in the design scope, together with responsive behaviour and any migration requirements.
Agree how decisions will be approved. A useful sequence is to review the structure first, test key flows in a prototype, and then refine the visual system. This helps stakeholders resolve fundamental questions before detailed production spreads the same assumptions across many screens.
6. Decide how you will judge the result
Record a baseline before release and choose measures that match the original problem. These could include successful task completion, qualified enquiries, checkout completion or the number of support requests about a particular journey. Define each measure consistently so the comparison is meaningful.
Plan the release checks, content review, analytics verification and rollback approach. Where practical, introduce changes in stages and review what happens. Consider other influences, such as campaign changes or seasonal demand, before attributing every movement to the redesign.
Your brief should now contain a clear purpose, priority journeys, content requirements, technical dependencies, review stages and success measures. That gives the design team a practical foundation: a better-looking product with a clear reason behind the changes.
