Planning an app redesign? Find the friction in real customer tasks first

Start with a customer task, not a new set of screens. Before redesigning an existing app, establish whether intended users can reach the right outcome without assistance, how long it takes, and where they get stuck. The answer may call for a clearer interface, a different workflow or better coordination with the service team. A visual refresh alone cannot demonstrate that customers can book, order or request support more effectively.

When this approach is useful

This guide is for business owners and product leads whose apps already have users but whose redesign brief is driven mainly by opinion. Sales may report that customers struggle, support may see repeated questions, and management may feel that the product looks dated. Those are useful starting signals, but they do not identify the right investment.

Choose a specific question: who is trying to do what, under which conditions, and what prevents the outcome? Brand design can still deserve investment. Give it its own objectives rather than treating updated screenshots as proof of operational improvement.

Nielsen Norman Group describes usability testing as observing representative people performing realistic tasks. Google Research's user-experience measurement work connects product goals to metrics. Together, these support a task-led diagnosis; neither supplies a universal business case or a promised uplift for an individual app. The workflow below applies that reasoning to a service app, including the handoffs common in equipment support and appointment businesses.

Define the outcome before measuring it

Consider an illustrative equipment-support task: report a fault on a purchased device and confirm that the request has reached the service team. This is a planning example, not a finding about a particular product.

A useful task brief identifies the user, their starting point, the information available to them, permitted assistance and the exact end state. For this example, success means a request attached to the correct device, visible to the service team, with a reference and an understandable next step for the customer. Tapping Submit is not enough. Completing the repair belongs to a later service stage and needs a separate measure.

Apply the same distinction elsewhere. Requesting an appointment is not necessarily a confirmed booking; opening a payment page is not payment success; submitting an enquiry is not accepting a quotation. Decide which part of the journey the redesign owns and which outcomes depend on staff or another system.

Build a baseline the whole team can interpret

For each task, record independent completion, completion with help, abandonment, incorrect outcomes and time. Explain what counts as a valid attempt before testing. Preserve failures rather than removing inconvenient cases after the fact.

Keep the unit consistent: a person, an attempt and a business transaction are not interchangeable. Link retries where appropriate. For work saved and resumed later, define an observation window and distinguish pending work from final failure.

The GOV.UK completion-rate guidance provides a useful reference for counting completions against starts and defining transaction boundaries. Its public-service reporting rules are not obligations for a private business operating in China. The transferable principle is a clear measurement contract, not a benchmark percentage.

Time also needs interpretation. Separate active interaction from upload processing, system response and waiting for a staff decision. Report the number of observations and representative slow cases alongside a median. A quick abandonment must not make the app appear more efficient. Record assisted attempts separately so a higher completion figure does not conceal additional support work.

Small exploratory studies help find problems; they do not establish population-level conversion rates. If participants explain their thinking while working, document that condition and avoid direct timing comparisons with silent, unobserved production use.

Observe the work without turning the session into a demo

Recruit around actual contexts. An equipment app may serve both a first-time buyer requesting support and an experienced technician. Testing only with employees who know the company's terminology can hide problems that customers encounter.

Give an outcome-based scenario such as “This device will not start; contact support and establish that your request was received.” Do not dictate the buttons or menus. Prepare test accounts and suitable device records so the session cannot trigger a real payment, dispatch or customer notification. Obtain consent for recordings, collect only what is needed, and agree who can access the material and for how long.

Keep three things distinct in the findings:

• Observation: a participant repeatedly switches between similarly named devices and asks which one to select.
• Hypothesis: installation location and a recognisable image may make the choice clearer.
• Next test: repeat a comparable task with the revised design and check device accuracy and requests for help.

One hesitation does not establish a backend defect. Equally, a positive comment does not prove successful use. Production events can locate a concentration of drop-offs; task observation can help explain it. Where tracking is unreliable, reconcile events with business records before using the funnel to justify expenditure.

Assign the problem to the right scope

Different obstacles require different owners. A hidden entry point calls for navigation work. Ambiguous equipment details may require better source data. An upload with no feedback needs progress and recovery behaviour. A request that arrives correctly but remains unassigned requires operational ownership and a working service queue.

The last issue cannot be resolved solely by changing the mobile interface. Include the relevant backend or staff workflow in the proposal, or explicitly identify it as a dependency outside the redesign.

Prioritise using business consequence, strength of evidence, implementation effort and dependencies. Wrong transactions or lost requests deserve risk assessment before cosmetic preferences. An expensive architectural proposal supported by little evidence should become a focused investigation, not an automatic line item in the redesign budget.

Each proposed change should name its evidence, affected users and tasks, frontend and operational scope, dependencies, acceptance scenario and exclusions. That is a stronger basis for a quote than a screen count.

Buy the work in decision-ready stages

Diagnosis should produce task definitions, a baseline, participant and environment information, findings and priorities. It need not conclude that every problem is a design problem.

Solution validation should produce a focused prototype, necessary service handoffs and a follow-up test. Cover waiting, failed submissions, recovery and returning to edit—not just the happy path.

Implementation and release should deliver the agreed changes, business and technical tests, and controlled observation in real use. Compare like with like where possible: task wording, user mix, devices and timing conditions. If participants repeat a task, acknowledge learning effects rather than attributing the entire improvement to the design.

Specify whether recruitment, analytics work, backend changes and post-release observation are included. Costs depend on the number of journeys, role differences, device coverage, system constraints and the work required to collect trustworthy evidence. Avoid promising a fixed revenue effect without a credible baseline and an appropriate evaluation design.

What acceptance should demonstrate

The business owner should be able to inspect a traceable chain from an observed problem to a delivered change and its verification. Record the release version and test environment. Give each key task a repeatable success condition. Reconcile user-facing confirmation with the underlying business state. Demonstrate relevant failure and support paths, not only successful submissions.

Agree numerical targets after reviewing the baseline. With limited users or data, acceptance can initially focus on reproducible fixes, correct critical journeys and complete evidence. Broader outcome claims may require observation after launch. Unresolved problems should retain an owner, an explanation and a next step.

Establish an observation period, escalation owner, conditions for pausing the rollout and a recovery plan. A redesign is ready for handover when the agreed changes have been verified and remaining issues are managed—not merely when a new interface is available.

Keep the measurement useful after launch

Longer visits are not automatically positive: reading and filing a repair request have different goals. Fewer complaints may reflect fewer attempts. Shorter flows can also remove valuable confirmation steps. Interpret each measure against the task and the business consequence.

Review task failures, requests for help and the relevant operational handoffs after changes to services, pricing, login or connected systems. Business owners set priorities, product and design teams propose changes, engineering and testing teams validate implementation, and service staff confirm that downstream work can continue.

For teams that still need a shared scope, the product discovery and planning guide provides related context before commissioning implementation.

Sources

• Nielsen Norman Group: Usability Testing 101 — observational testing and the distinction between qualitative findings and quantitative measures. Accessed September 11, 2026.
• Google Research: Measuring the User Experience on a Large Scale — connecting product goals with user-centred measures, not evidence of results for the illustrative app. Accessed September 11, 2026.
• GOV.UK Service Manual: Measuring completion rate — transaction boundaries and completion measurement. Accessed September 11, 2026.