By the Phenomenon Studio product team

Why it matters

  • Any change to a live interface forces people to relearn something, and the support desk usually feels that cost before the designer does.
  • An established user base offers what a brand-new product never can: genuine behaviour to study and real customers to test with.
  • How a change reaches users deserves a place in the brief, because identical designs can thrive or flop depending on the release.

Briefing designers for a product that people already rely on is a different job from briefing them before launch. On paper the layouts can seem alike, yet the pressures behind them differ entirely. A team reworking a booking screen used by thousands of clinics faces far higher stakes than a start-up sketching its first prototype.

Before launch, design is a guess about future behaviour. After launch, it becomes a conversation with habits people lean on every single day.

That conversation is where most of the effort goes. Bringing in the right UI design firm for a product with existing users means investing in strategic design judgement, user research, and controlled improvements rather than simply visual changes.

What changes in the brief once users exist

Evidence replaces guesswork. Usage analytics, help-desk tickets and recorded sessions reveal how the product is really used rather than how it was planned. An experienced UI design firm recognizes that established products require a different design approach, where preserving familiar workflows can be just as important as improving usability.

Live products also carry unwritten promises. Customers have saved filters, memorised shortcuts and built routines around quirks the team regards as bugs, which makes project boundaries far harder to fix. Designers who mostly work on fresh builds often miss how much a single page touches. An accountant who runs the same export every Friday will notice the moment its button moves.

Small edits ripple outward.

Tweaking a single page can brush against a contractual commitment, a third-party integration or a training manual owned by another department.

Release timing shifts as well. Mature products ship in small steps, so the brief has to say which changes can go live on their own and which must arrive together.

Take an inventory before anyone draws anything

Older products hide far more surface area than their owners recall, as preference panels, exports, notification emails and admin pages build up unnoticed. A manager who believes the app has forty screens may find closer to two hundred states.

A full catalogue of every page and state comes first, each with a note on how often it's used. Building it is dull, yet it changes every quote that follows. Pages nobody visits can be trimmed or retired, and that call frequently delivers more than a redesign would.

It's also worth marking which areas sit outside the core codebase. Marketing sites, knowledge bases and payment portals often live elsewhere, and suppliers usually quote for them separately.

Settling early whether those areas are included prevents confusion, as marketing-site work and product design need different yardsticks.

The catalogue belongs in the same email as the brief. A partner quoting without it is estimating the product's size blind, and blind estimates almost always come in too low.

The relearning cost nobody puts in the estimate

A redesigned interface takes time from people before it gives any back. That cost often shows up as extra support requests, yet proposals seldom mention it. Long-standing users carry most of the burden. They rely heavily on muscle memory, so a relocated control slows them far more than it slows a newcomer. A warehouse supervisor handling two hundred orders a shift feels every extra click.

According to a Gartner survey of more than 2,850 employees conducted in April 2025, 79% of employees reported low trust in change.

That research looks at organisational change in general rather than software. It still matters, since a new interface in a business tool is one of the most visible changes staff meet. Gartner didn't study interface changes directly, so the connection is an interpretation, not a finding.

Planning for a short-term slump is sensible. Many product teams notice task completion or speed slipping for a while after a major redesign as people adapt, although how deep and how long that slump runs varies greatly with the product, its audience and how often it's opened. Drawing conclusions mid-adjustment can mislead.

Surfaces worth declaring off limits

Surfaces worth declaring off limits

A written list of areas the supplier must leave alone is worth drafting early. It shields the product and keeps the project moving.

Billing and account settings usually top that list. Edits there spill into finance teams and contracts, not just everyday use.

Admin and permissions pages frequently join them, since the few people who open them have little patience for relearning, and restructuring them can snap integrations. Anything containing regulatory wording earns a place automatically. Designers can suggest better consent and disclosure screens, but nothing in that territory ought to go live without legal sign-off.

The list does most good when it exists before the kickoff meeting. A supplier who stumbles on these limits in week five has already spent days heading the wrong way.

What to hand over on day one

A quarter's worth of help-desk tickets, ideally labelled by page.

Few research sources cost less, and hardly any companies think to share them.

Conversion data for each flow being reworked, plus a plain explanation of what every tracked event means. Figures without that context get misinterpreted, and the error often surfaces late.

Recordings of the flow's weakest step, where the analytics tool stores them. A few short clips are often more revealing than a full-day workshop. A note of customers likely to react badly to change also helps. Every established product has some, and account managers can usually list them within an hour.

Last of all, the engineering team's log of known issues, which explains odd behaviour that might otherwise look like poor design.

Testing with users you already have

This is where a live product shines, and plenty of teams squander it. Volunteers can be found among existing customers within days instead of being bought from a research panel.

Recruiting across different lengths of membership beats random selection. Veteran customers expose the cost of relearning, while newcomers reveal where the product confuses people.

The existing product deserves testing first, before any new concepts exist. Those early sessions separate genuine pain points from problems that only exist in internal opinion. The new design can then face exactly the same tasks, so the team reports measurable differences instead of impressions.

Mobile apps can recruit the same way, from people who already have the app installed, and short, frequent sessions generally work best. Jakob Nielsen of the Nielsen Norman Group has long argued that several small rounds of testing, often with about five participants each, uncover more problems than one large study, as set out in his well-known article on testing with five users. The ideal rhythm depends on the release cycle, but insights that land while the design is still flexible are worth far more.

Rollout belongs in the design brief

Delivery shapes reception. A redesign introduced gradually behind a feature flag can win people over, while the identical design sprung on everyone first thing on a Monday can backfire badly.

Agreeing the release approach with engineering before design starts helps, since cohort releases, previews and temporary switches each demand different things.

Optional previews win goodwill but double the upkeep, since two interfaces run in parallel for a while, and that expense deserves a line in the quote. Feature-flag work also needs its own price. A staged release takes genuine engineering hours, not a free tick-box, and it tends to disappear from quotes unless someone spells it out.

Gartner's July 2025 research adds another warning: only 32% of mid-to-senior level business leaders reported that the most recent change they led achieved healthy adoption among employees.

That number is better read as a caution about execution than a verdict on design. Gartner examined organisational change broadly, yet the lesson travels well: a sound change can still stumble on arrival.

Working alongside the team that keeps the product running

Every live product comes with engineers juggling a crowded backlog. New design work doesn't run in its own lane. It competes for those same hours.

Agreeing a fixed share of each sprint for design tasks avoids frustration, or finished designs queue up and the project looks slower than it is.

Engineers can check designs for build effort before sign-off.

They'll quickly flag the component that would eat up weeks rather than days.

Bug fixes and redesign tasks are easier to manage when planned separately, since blending them hides progress and squeezes the fixes. Any development partner arriving partway through the product's life also needs the catalogue. Knowing why a page behaves strangely is worth more than any welcome pack.

Communicating the change to people who did not ask for it

Communicating the change to people who did not ask for it

Hardly anyone requests a redesign. Customers asked for three particular fixes, and an entirely new interface appeared instead.

Announcements land better when they open with the problems solved. Notes that mention the original complaint read very differently from notes that merely celebrate a new look.

Support teams benefit from early briefing material, with a week's notice a common rule of thumb rather than a proven standard. Screenshots, a short guide to relocated controls and a ready answer to the most likely question can handle much of the first day's volume.

Leaving the old route open briefly, where it's practical, can ease the switch. A short overlap, perhaps a week, gives frustrated customers a fallback while they adjust, though the ideal length depends on the product and how often people use it.

How our teams approach a live HealthTech product

On HealthTech projects, Phenomenon Studio's designers treat the clinical workflow as the fixed constraint rather than a blank canvas. They observe how staff currently move through each task first, because shaving time off every patient encounter often matters more to clinicians than any cosmetic upgrade. Updates to these products are typically released in stages, starting with one department that has volunteered. Nurses and administrators can then flag problems before the update spreads across a whole hospital.

The release plan is written jointly with the client, since the client's trainers live with the results.

This describes a way of working rather than a promise of results, and outcomes always depend on each organisation's systems, staff and timelines.

Oleksandr Kostiuchenko, Marketing Manager at Phenomenon Studio, says his opening question to any live-product team concerns notice. He asks who would spot an alteration to a particular page within an hour, and the answer helps shape the release method.

Do product design companies near me matter for this work?

Geography counts for far less than a track record with live products, since judgement about change has little to do with a map.

Shortlisted studios are best judged on finished projects for products that already had customers, which no location search can filter for. Helpful questions cover what they altered, how it was released and how support requests moved afterwards.

Local studios do hold one small advantage on established products. Spending a day beside the support team is far simpler face to face, and that day often proves the most valuable research of the entire project.

Being nearby is a convenience and nothing more. A studio on another continent can still run a brilliant workshop over video. Proven work on live products deserves far more weight than a postcode.

From there, evidence decides. A studio with three fresh launches and no work on established products is a very different choice from one with the opposite history.

The same check applies to engineering partners, as developers who have only built new products may treat a migration as an afterthought.

Reading a proposal for live-product awareness

Good proposals for established products discuss states, such as empty, error and restricted-access views, rather than just pages. Strong bids also list the data they'll need. Any supplier requesting event definitions and ticket exports has clearly done this before.

How a bid describes the current product says a lot.

A team that labels everything dated before opening the analytics is pitching a rebuild, not a diagnosis.

A separate section on rollout is another encouraging sign. When it's missing, the supplier is probably quoting for a brand-new build with the existing product's name pasted on top.

Regression testing is worth checking too. A sound proposal names who will test the untouched areas after each design change, because that job is real and frequently falls between the cracks.

What a first engagement should cost you in internal time

Live-product work demands more client time than a fresh build, since someone has to gather data, organise sessions and brief the help desk. A sensible starting estimate is roughly one day per week of a product lead's time in the first month, tapering once the big questions are settled. Every company differs, so the figure works as a planning guide, not a rule.

Support and account teams also need time set aside during release weeks. An external studio can't brief a company's own customers, so that task stays in-house.

Engineering review time is needed for each round of designs. Early checks on feasibility prevent costly rework once building begins.

Every one of these hours belongs in the comparison, since two studios can price identical work yet claim very different slices of a client's week.

Measuring a change on a live product

Established products offer a tool new builds lack. A holdback group can stay on the old version while everyone else receives the update, and both groups can then be compared on the same task. Holdbacks cost little but often prove unpopular, and the inevitable argument about fairness is worth settling once rather than weekly.

Support requests deserve tracking next to the usage figures. A rising completion rate paired with a surge in tickets suggests the effort has shifted rather than disappeared.

The final judgement works best once customers have settled in, not while they're still learning. No universal waiting period exists. Many teams allow several weeks for a weekly-use product and considerably longer for something opened monthly, but the right window depends on usage frequency and how much the change asks people to relearn. For a better understanding of how thoughtful design influences the customer experience, phenomenonstudio offers relevant insights.

What the engagement should leave behind

A component library that mirrors the live product rather than just the design files. Products drift over time, and a library that captures that drift is more useful than a polished ideal.

A written note of everything intentionally left alone. Future suppliers need to know which oddities were deliberate choices. Agreed rules for the awkward states nobody enjoys designing, recorded once. Designers and developers both move faster with those rules to hand.

Blank, loading and error views are usually where consistency slips first on older products.

Finally, a brief measurement summary for every change. Design work handed over without one leaves the team unable to justify it six months later.

Common mistakes

  • Ordering a cosmetic refresh when the real complaint is about one particular workflow.
  • Designing from gut feeling while analytics and labelled tickets go unread.
  • Releasing a complete redesign in one go to hit a launch date, so the support burden and the praise arrive together.
  • Leaving admin and billing pages half-updated, which shows two visual styles in a single session.
  • Assuming mobile and web specialists are interchangeable when it comes to native platform conventions.

When the problem is not the interface

Sometimes the screens are fine and the product underneath isn't.

Sluggish servers, poor defaults and missing permissions can all masquerade as design complaints.

Checking load times before ordering new screens is wise. Performance improvements sometimes lift the experience more than any redesign could. Onboarding material deserves scrutiny as well. Customers who never understood how the product works will struggle with any layout, and that's a content issue wearing a design costume.

A trustworthy supplier says so plainly, because selling design against a problem it can't solve harms trust on both sides.

Sequencing the work across a quarter

The weakest step in the busiest flow makes an ideal opening move. It's easy to measure, simple to justify internally and builds support for everything after it.

The error and empty states behind most help-desk tickets come next. They rarely need a careful rollout, since nobody builds habits around an error message.

Major navigation changes are best saved for the end. Seasoned web and mobile teams tend to suggest the same order, because navigation changes wipe out paths people have already learned. Sequence matters more than pace here. Navigation is the change that demands cohorts, advance warning and a support rehearsal.

Each change ideally stays measurable in isolation, since bundling three into one release makes the results impossible to separate.

Keeping the product consistent while it changes

Half-finished redesigns leave visible joins, and joins are exactly what customers spot.

Two visual styles within one product look like neglect rather than progress.

A handful of product-wide updates can go first. Fonts, spacing and main buttons can be refreshed across the whole product in a single pass without altering any layouts.

That pass buys breathing room for the slower work. Individual flows can then evolve one by one while the product as a whole already looks unified. A quick local search won't reveal which studios manage this well. A better test is asking for a product they updated gradually and what the joins looked like at the halfway point.

Marketing pages need to keep pace with the product itself. A website refreshed months late shows prospects one product while customers use another.

Making the hire

When evaluating a UI design firm, businesses should focus on how its designers approach existing customers rather than relying exclusively on the visual quality of their portfolios. Questions about research, release planning, and usability improvements reveal much more about the team's suitability.

A telling request is one example of something they chose to leave unchanged. A capable mobile team answers that as comfortably as a capable web team.

Restraint is the quality worth paying for, and on a live product it's rarer than ambition. Starting small and measuring the outcome is the safest route. Any supplier, web or mobile, earns the bigger project by delivering one change that sticks.

Conclusion

Ultimately, hiring a UI design firm for an established product is about finding a partner that understands the relationship between interface improvements and existing customer behaviour. By leveraging the right UI design tools, design teams can evaluate existing interfaces, identify usability gaps, and implement thoughtful improvements without disrupting familiar workflows. The strongest partnerships prioritize evidence, meaningful changes, and measurable outcomes over unnecessary redesigns.

Frequently Asked Questions