Collect the research first, before you redesign anything

A redesign usually starts the same way. Someone opens Figma, draws a cleaner header, and calls it a direction. Nobody has screenshotted the product as it stands. Nobody has looked at what three competitors do about the same screen. Nobody has read the support tickets sitting in the help desk that already explain, in the user's own words, what is actually wrong. The new version ships a few months later looking better and behaving almost exactly like the old one, because the team designed from memory and opinion instead of from evidence.

This is not an argument for research paralysis. It is an argument for a short, disciplined gathering phase, a few days for a small team, before anyone opens a design tool. The three sources worth collecting are the same every time: the product as it exists today, what competitors have already tried, and the complaints your own users have already filed. None of that is hard to get. What is missing is usually just a place to put it.

What goes wrong when a redesign skips this step?

Three things, reliably. The first is repeating an old mistake nobody remembers making, because the reason a workaround exists in the current product was never written down anywhere, so the redesign removes it and the team relearns why it was there the hard way. The second is solving a problem nobody actually has, because the new direction was inspired by a screenshot someone saw on X rather than a pattern that fits this product's own users. The third is losing ground a competitor already covers, because nobody checked before committing to a direction that turned out to be a step backward against the market the product actually competes in.

All three are avoidable with the same fix: look at what is already true before deciding what should change.

Audit what already exists, properly

The instinct is to screenshot the screens that feel broken and skip the rest. That is exactly backwards. The screens that feel fine are the ones quietly setting the pattern language the redesign is about to break, often without anyone deciding to break it. The screens nobody opens, an empty state, an error message, a settings page three levels deep, still have to work on the other side of a redesign, and they cannot be assessed from memory months later.

1. Walk every primary flow end to end, including the states that only show up occasionally: the empty state before anything has been added, the error state when something fails, the loading state on a slow connection. Screenshot each step in order, not just the happy path.
2. Capture the screens nobody remembers exist. Settings, admin views, receipts, confirmation emails if they carry the product's design system. A redesign that only touches the screens people talk about quietly breaks the ones they forgot to mention.
3. Note the workarounds current users have found for tasks the interface makes difficult. A support macro, a spreadsheet nobody asked for, a step users always do in the wrong order. Workarounds are the most honest bug reports a product ever gets, and they rarely show up in a feature request.

Turn competitor research into evidence, not vibes

Opening a competitor's app and forming an impression is not research. It produces a vague sense that a rival "feels cleaner", which is not a brief anyone can design against six weeks later. Research means capturing a specific pattern, a pricing table, an empty state, an onboarding step, as a screenshot, with one sentence attached explaining why it was worth capturing: what job it does, what it might solve here, and what would need testing before copying it.

The Nielsen Norman Group's guidance on competitive usability evaluations makes the same point from a different angle: the value is in comparing how different products solve the same design problem, not in a general impression of which one looks nicer. A screenshot without a reason attached is exactly as useful as no screenshot at all once six weeks have passed and nobody remembers why it was kept.

Collect the complaints you already have

Every product that has shipped for more than a year already has a pile of unread evidence sitting in a help desk, a feedback field, an app store review, or a one-line answer to a survey nobody followed up on. A redesign that skips this pile is designing from opinion when it could be designing from a written record of exactly what people asked for. Screenshot the actual message rather than paraphrasing it into a ticket title. Paraphrasing loses the wording someone chose, and the wording is often the clue: "I can't find the export button" is a usability problem, and "I wish this had dark mode" is a feature request, and the two are easy to conflate if all that survives is a one-line summary written by whoever triaged it.

Where do you actually put all of this so the patterns become visible?

A shared folder or a Figma page works for a small team, and it is worth doing properly rather than treating it as a placeholder until something better arrives. Three top-level groups cover most redesigns: the current product, competitors, and complaints. Inside each, one item per screenshot with a one-line note on why it is there. Keep the structure flat. Nested folders five levels deep defeat the entire purpose, which is a designer scanning fifty items in ten minutes rather than navigating a filing system to find the one they half remember.

Name items by the job they show, not by their source or the date they were captured. A screenshot labelled "pricing-page-hard-tradeoff" is findable later. One labelled "Screenshot 2026-08-03 at 14.02.11" is not, no matter how carefully it was filed at the time. Once everything from every source sits in one place, patterns tend to surface on their own: three competitors solve onboarding the same way, five support tickets complain about the same button, and the current product and two rivals already agree on where a filter belongs. That is the moment synthesis, personas, flows, wireframes, actually starts from evidence instead of from whoever spoke first in the kickoff meeting.

Where a dedicated library takes over

A folder and a Figma page hold up fine for a short research phase on a small team. They start to strain once the pile passes a few hundred items across three different sources, because a filename or a layer name can only carry so much context before someone has to open the file to remember what it actually shows.

Muse, the app we build, is not a research method. It will not decide what to audit or write the sentence explaining why a competitor's pattern matters here, that judgement stays yours. What it removes is the fragmentation: research from every source, screenshots of your own product, screenshots of competitor patterns, screenshots of support tickets and reviews, stays in one searchable place instead of split across a folder, a Figma page and someone's inbox. Every item keeps a note field for the reason it was captured, and one screenshot can sit in more than one collection at once, so a competitor's onboarding screen can live under both Competitors and Onboarding without being duplicated. If a support ticket or review was itself a screenshot, Muse reads the text inside it the way Spotlight does, so it turns up in a search by what the user actually typed, not just by whatever it happened to be filed under.