A request to redesign a dashboard already contains a proposed solution. It says little about why the current dashboard is failing. The work becomes strategic when the team can explain which behavior needs to change and why redesigning this surface deserves attention now.
View full image
For example, a retailer may want fewer calls about order status. A more attractive dashboard could help, but missing shipment data or unclear delivery estimates could be the real obstacle. Designing the wrong layer well would still leave the calls coming in.
1. Choose an outcome that can be observed
“Improve engagement” is too open-ended to guide a layout. “Help store staff identify delayed orders without contacting support” is more useful. It identifies the audience, the task and an alternative behavior the product should make less necessary.
Choose a measure that reflects that task, such as successful status checks or order-status contacts relative to order volume. Total visits alone would be ambiguous: people may return because the tool is useful or because they cannot find an answer.
This does not require inventing a target before a baseline exists. It requires agreeing on what would count as progress.
2. Find the obstacle before choosing the artifact
Follow one realistic order through the current experience. Can staff find it? Do the labels match the information they receive elsewhere? Does “shipped” mean the whole order or one package? Is the latest update reliable?
Those questions can lead to different interventions: better search, clearer status definitions, package-level detail or a data integration change. A screen redesign is one candidate among them.
The designer's contribution is partly deciding what should remain untouched. If search already works and shipment status is unreliable, rebuilding search consumes time without addressing the reason people call support.
3. Agree on a test and a stopping point
A prototype can test whether staff interpret a status correctly. It cannot establish that live updates arrive on time or that support volume will fall. Match the test to the uncertainty instead of asking one method to prove everything.
After release, compare the relevant behavior against a baseline and watch for other changes in order volume, delivery performance or support practices. A before-and-after improvement is useful evidence, but does not isolate the interface as the cause.
Also check the cost. Fewer calls would be a poor result if customers simply gave up while orders remained unresolved. Pair the main measure with a check on successful resolution.
Strategy often appears in these small choices: which problem gets attention, which uncertainty gets tested and which attractive improvement waits. The final screen should make those choices visible through what it prioritizes.