What Should You Try Before Approving a Business App Redesign?

Say the new screens look good. Your supplier shows you how to find an order, change it and save. Now you're being asked to approve the redesign so development can move ahead.

Before you agree, let someone who will actually use the app try an important piece of work. Give them the situation and the result they need, then watch what happens. A person following a presentation has the presenter to show the way. Someone handling a customer request has to find it themselves.

Start with work that matters

Choose work people do often, or work where a mistake would cause trouble. If an exception changes what someone needs to do, include that too. The useful scope depends on your app and the decision in front of you.

Here's a hypothetical example. An order clerk receives a customer's request to change a delivery address before dispatch. The clerk needs to find the right order, correct the address and understand whether the change has gone through.

Set up sample orders with invented customer details. Give the clerk a believable customer message and enough information to identify the order. Keep real customer and business information out of a prototype that isn't equipped to protect it.

Then ask them to deal with the request. Avoid instructions such as “open Orders, choose Edit and press Save.” Those steps hand them the answer you're trying to find out.

Marieke McCloskey's January 12, 2014 guidance on task scenarios explains this distinction: give people meaningful context and a goal without revealing the route through the interface.

Let the likely user have a go

Ask someone who does this kind of work, or is likely to do it. If clerks handle order corrections, a manager who already knows the proposed screens can't stand in for them. Include other roles where their work raises different questions.

Use conditions that matter to the job. A clerk spending the day at a desk may rely on a keyboard. Someone checking orders on a phone faces a different screen and input. If people use assistive technology, plan for the relevant setup and check whether the prototype supports it.

The GOV.UK guidance on moderated usability testing describes watching actual or likely users attempt believable tasks. You can apply that principle to the particular work you need to review without copying a whole government research programme.

Watch where the clerk looks, hesitates, takes a wrong turn or misses information. Listen to what they think has happened. If you have to help, write down where and how. A successful finish with directions tells you something different from a successful finish without them.

“I like the layout” is useful feedback on someone's preference. “I thought the address had saved, but I was still in edit mode” gives you a specific problem to investigate.

Now suppose the order has already gone to dispatch

In the same hypothetical example, the customer asks too late for an ordinary correction. Can the clerk understand the order's current state and work out what to do next? Perhaps they need a manager's approval or must contact dispatch.

Agree what that next step should be in your business, then let the person try it. Include the relevant screens and choices if the prototype can support them. Look for a clear outcome: does the clerk know whether the address changed, whether someone else needs to act and whether the customer can be given an answer?

A simulated warning can show whether the wording makes sense. It can't prove that the working app will prevent an unauthorized change or get a message to dispatch. Keep those questions for checks that can actually answer them.

Choose a prototype that can answer your question

A sketch can help you discuss what belongs on a screen and whether the proposed idea makes sense. A clickable prototype can let someone find an order, move between screens and interpret a confirmation, provided those parts have been built into it. Tell everyone which parts work and which parts are being simulated.

If you want to learn whether the clerk can find the correction route, let them try that route. If you're deciding whether a warning is understandable, show it in the situation where it would appear. Asking whether someone thinks they could use a screen gives you their prediction; watching an attempt gives you evidence of what they actually do.

In her August 27, 2014 account of using prototypes at GDS, Katherine Alsop described the difference between a stable stakeholder demonstration and prototypes changed during research. She also noted that research on a live service can reveal response-time and error-handling problems absent from a prototype.

That matters when you approve the work. A clickable “Saved” message can help test whether the clerk understands the result. Checking that the correct data was stored, that repeated requests are handled safely and that connected systems received the change needs suitable implementation checks. Security, enforced permissions and speed also need evidence from the relevant working parts of the app.

People using their usual assistive setup can reveal practical barriers. As W3C's guidance on involving users in accessibility evaluation explains, this belongs alongside evaluation against accessibility standards. Completing these tasks doesn't prove the app meets accessibility standards. If the prototype can't support a needed setup, record that limit and arrange the appropriate later check.

Leave the meeting with a decision you can explain

Write down what you saw while it's still fresh. Keep the record practical:

• Who tried what: the person's role, the task, device and input, and which parts the prototype supported.
• What happened: whether they reached the intended result, where they struggled and any help they needed. Keep observations separate from guesses about the cause.
• What to change and try again: name the confusing label, missing information or unclear next step. After the change, let someone attempt the affected work again.
• What still needs a working app: record open questions, who will check them and when. In our example, that could include who can approve a late correction and how dispatch receives it.

You can then approve the direction the attempts support, request a revision where people struggled, or reserve a particular decision until the right evidence is available. You may do all three for different parts of the redesign. Approving the order screens doesn't have to mean accepting an untested dispatch integration.

If you're preparing a business-app redesign, our design work can be a starting point for a conversation about who uses the app, what they need to do and which decisions you need help making.