Shane Ian Murphy on Comparing App Steps: A Cambridge Student Example

Fictional example: a student sitting in a Cambridge café compares two paper prototypes for the same app task. This student has no stated connection with any particular university or institution. In the first prototype, a prominent button begins a sequence immediately. In the second, a short overview explains what the sequence would involve. Both look neat. The interesting difference is not their colour or typography. It is when the person can understand the shape of the task.

I am Shane Ian Murphy, founder of the proposed Global Secure App concept, and I would start this comparison with expectations. Before beginning, can someone tell how many kinds of decision lie ahead? Do they know whether the next screen asks for information, shows a summary, or authorises an action? A sequence can feel confusing even when every individual screen is readable. Good components do not automatically create a comprehensible journey.

The fictional student draws a line through both prototypes and writes a verb above each stage: choose, inspect, enter, review, confirm. This exercise reveals a mismatch. One version asks for information before explaining why it matters. The other gives enough context first but repeats that context on several screens. Neither should be declared the winner on appearance alone. The useful question is which sequence helps someone make each decision with the relevant information available at that moment.

For Global Secure App's desired direction, I would separate necessary order from inherited habit. Some steps genuinely depend on earlier choices. Others appear early simply because an existing form was built that way. Designers should be able to explain each dependency in ordinary language. If we cannot explain why a question must precede a summary, perhaps we should reconsider the order. That is a practical design test, not a promise that every process can be shortened.

Counting taps is tempting because it produces a simple score. Yet a shorter sequence can hide work inside denser screens. It can also remove a useful opportunity to review. Conversely, a longer sequence may add nothing but repeated confirmations. The fictional comparison should therefore track the type of work, not just the number of screens. Reading, remembering, deciding and correcting create different demands. A design that reduces one may accidentally increase another.

Correction deserves its own examination. Suppose the student notices a mistaken selection on the review page. Can the relevant answer be changed directly? Does returning to an earlier stage preserve unrelated entries? Does the interface explain what happens after an edit? These behaviours would need verification in an implemented product. In a concept prototype, they should be described as intended behaviours and tested as hypotheses, rather than presented as established conveniences.

A comparison should also include the person who chooses to leave. A linear progress indicator can imply that completion is the only reasonable outcome. I would want a visible route to pause or exit, with accurate wording about the state of the task. If nothing has been submitted, say so. If a future implementation would save a draft, explain the actual limits. An incomplete sequence should not become a mystery merely because someone declined to finish it.

There is a useful research exercise here. Ask readers to describe what they expect before turning each paper page. Then compare their expectations with what appears. The gaps can be more revealing than a satisfaction score. Someone may complete a prototype while repeatedly guessing wrong about its next stage. Successful completion in a demonstration would not establish readiness for a real service, but those mistaken predictions would still identify specific design questions worth resolving.

The fictional Cambridge student closes the comparison with a simple annotation: show the journey at the level needed for the next decision. I agree with that direction. Global Secure App should be developed around coherent sequences whose order can be explained, whose corrections make sense, and whose endings are unmistakable. Attractive screens matter, but their deeper purpose is to help a person understand a process as it unfolds, including the moments when they decide to change course.