UX audit before redesign: scope, cost and decisions

Short answer: the Prolabs estimate for a UX audit is PLN 8,000 to 35,000 net. A useful audit combines quantitative data, interviews, task analysis, technical defects and business constraints. Its outcome is not a list of tiny comments. It decides whether the company needs redesign, repair of several paths, or better offer and measurement.

Redesign often starts with an aesthetic diagnosis: the site looks old. The user may actually leave because price is missing, delivery is unclear, a form is slow or nobody responds after submission. A new interface hides the problem when nobody examines the process.

Do not design the new version until you can name the current failure and the way to measure it.

Which UX audit scope fits the problem?

These net figures are Prolabs estimates. A small audit can cover one path but cannot replace research for a complex product.

Scenario	Budget or threshold	Decision
Expert review	PLN 8k to 15k	fast diagnosis of one path
Data and recording audit	PLN 12k to 25k	combines analytics with observed behaviour
Audit with research	PLN 20k to 35k	interviews and key-task tests
Discovery before redesign	PLN 30k to 60k	multiple groups, processes and constraints

These ranges start a conversation; they are not an automatic rate card. Data quality, integrations, ownership and the cost of failure change the scope. A useful proposal makes those dependencies explicit and says what it deliberately excludes.

Write down the current state before asking for a quote. Capture case volume, team time, tool cost, error count and the business outcome. The data does not need to be perfect. It needs to support a like-for-like comparison after the pilot. Without a baseline, discussion returns to opinion and an impressive demonstration can be mistaken for a better result.

Which signs show that the problem is already expensive?

1. The team asks for wireframes first. Nobody defined the problem or metric.
2. Data ends with page views. The complete path and errors are invisible.
3. Support knows problems, design does not. Customer evidence never reaches the backlog.
4. Stakeholders hold conflicting opinions. There is no shared evidence base.
5. Redesign must repair sales. Offer, price and follow-up remain untested.

One sign rarely justifies a large project. Several signs together usually mean that the company already pays for workarounds through manual effort, lost leads, unreliable reporting or slow decisions. An audit should then set the repair order instead of listing every feature that could be built.

Include the people who perform the work every day. They know exceptions hidden from the formal process and can point to places where a customer waits or data loses context. Their role should continue beyond one interview. Give them a test version, a short feedback path and an explanation of decisions made from their evidence.

What should be audited before the first wireframe?

Review user tasks, value proposition, navigation, copy, forms, performance, accessibility and the next operational step. The interface boundary is not always the problem boundary.

Test this area on real data and one complete path before rollout. A document or mock-up will not expose exceptions, delays and manual workarounds. A short test with the process owner separates an actual constraint from a team preference.

Record the decision with its assumption, metric and review date. A later change then becomes a response to evidence rather than a failure. The record also helps the next person understand why the current scope exists.

How should data and research be combined?

Analytics shows where, recordings reveal behaviour and interviews explain motive. No single source produces a complete cause.

Test this area on real data and one complete path before rollout. A document or mock-up will not expose exceptions, delays and manual workarounds. A short test with the process owner separates an actual constraint from a team preference.

Record the decision with its assumption, metric and review date. A later change then becomes a response to evidence rather than a failure. The record also helps the next person understand why the current scope exists.

When is redesign too large an answer?

When the issue is one path, missing information, a technical defect or sales follow-up. A focused repair produces faster evidence.

Test this area on real data and one complete path before rollout. A document or mock-up will not expose exceptions, delays and manual workarounds. A short test with the process owner separates an actual constraint from a team preference.

Record the decision with its assumption, metric and review date. A later change then becomes a response to evidence rather than a failure. The record also helps the next person understand why the current scope exists.

What should an audit deliver?

A problem list with evidence, severity, owner and recommended test, plus a measurement map and a decision on what can remain.

Test this area on real data and one complete path before rollout. A document or mock-up will not expose exceptions, delays and manual workarounds. A short test with the process owner separates an actual constraint from a team preference.

Record the decision with its assumption, metric and review date. A later change then becomes a response to evidence rather than a failure. The record also helps the next person understand why the current scope exists.

What does this look like in a concrete example?

A company plans a PLN 120,000 portal redesign. The audit finds that most abandonment follows an iOS form error and customers cannot distinguish two plans. Prolabs estimate: a PLN 18,000 repair and messaging test produce evidence before larger spend. Redesign is narrowed to the parts that cannot be fixed locally.

The company starts with a small scope and a measurable result. It increases spend, changes the tool or stops only after evidence. That reduces the cost of learning and keeps control with the process owner.

Design the failure path as well. What does a customer see when an integration fails? Who receives an alert? Can the operation be retried safely? How does the team return to the previous version? These sound like technical questions, but they describe business continuity. A simple manual takeover often provides more safety than complex automation with no observability.

How do you define a safe first scope?

A good first scope proves one thing and leaves evidence for the next decision. It does not need to fix the entire company. It needs an owner, measurable outcome, review date and a clear exit if the hypothesis fails.

• Name the decision and process owner.
• Record the current state and workaround cost.
• Choose one outcome metric.
• Test the full path on real data.
• Define error handling and manual takeover.
• Plan knowledge and access handover.
• Set the date for the next-stage decision.

After the pilot or launch, schedule a results review and a decision about further investment.

After the first month, separate implementation defects from a failed hypothesis. Configuration can be repaired. Missing use or missing business impact requires a different decision. Decide in advance who may stop further spend and which evidence is sufficient. This discipline protects the budget better than a fixed backlog written before contact with real users.

Which data and sources should guide the decision?

Tool prices and platform rules change. These sources were checked in July 2026. Open the current price list and terms before signing. Figures labelled as a Prolabs estimate are planning scenarios, not market statistics.

• Source: web.dev Core Web Vitals. Google thresholds for loading, interaction and layout stability.
• Source: Google Analytics ecommerce. Recommended measurement of product and purchase behaviour.
• Source: Baymard checkout research. Primary usability research on abandonment and checkout complexity.

When comparing suppliers, ask how they manage risk. A technology list says little. Acceptance criteria, demonstration rhythm and decision records matter more. The proposal should separate essential scope, options and maintenance. The company can then reduce the first stage without removing safeguards for data, customers and continuity. Clear exclusions signal maturity rather than inflexibility.

Finally, request a short operating guide and a list of cases that require a specialist. The team should know which changes are safe, where errors appear and how to report an incident with useful context. This preparation reduces downtime and repeated small requests after launch.

Related reading

See the Prolabs service. Ecommerce conversion: 12 changes with measurable impact, GA4 ecommerce analytics: what to measure for decisions. See the Natu.Care case study.

FAQ

How long does a UX audit take?

The Prolabs estimate is 2 to 5 weeks. Timing depends on paths, data quality, user availability and the speed of company decisions. The final scope depends on data, team and risk. A short diagnosis is safer than forcing the company into a ready-made package.

Does a UX audit require high traffic?

No. Traffic supports quantitative confidence, but interviews, task tests, support evidence and technical defects provide value at a smaller scale as well. The final scope depends on data, team and risk. A short diagnosis is safer than forcing the company into a ready-made package.

Must redesign follow an audit?

No. Findings can support focused repairs, copy changes, better measurement or a process change outside the interface. Redesign is one possible outcome. The final scope depends on data, team and risk. A short diagnosis is safer than forcing the company into a ready-made package.

Who should join a UX audit?

Include the business owner, data specialist, product or marketing and people serving customers. The team also needs user and tool access. The final scope depends on data, team and risk. A short diagnosis is safer than forcing the company into a ready-made package.

How do we judge report quality?

Every important recommendation needs evidence, likely impact, cost and a verification method. A loose list of general best practices cannot support an investment decision. The final scope depends on data, team and risk. A short diagnosis is safer than forcing the company into a ready-made package.

Related service: see scope and collaboration model.