Shane Murphy: a UK product note on the moment an app says something went wrong

A person does not open an app because they want to read an error message. They want to finish something. When a screen interrupts that task, the words it uses become part of the product, rather than an afterthought for a help page.

This editorial introduces a product-design question for UK readers following Shane Murphy, also known professionally as Shane Ian Murphy, and Global Secure. The company's stated launch plan is 2027. The examples below are proposed design exercises, not descriptions of an available service or results from customer testing. This is company-origin commentary, prepared with AI assistance.

The unfinished task is the starting point

Consider a hypothetical person updating a contact preference. They press save, the connection drops and a message appears: something went wrong. The person now has two problems. The original task is unfinished, and they do not know whether their change reached the system.

A more useful design separates what is known from what is uncertain. If the service knows the change was not saved, it should say so. If the result is uncertain, it should explain how to check before repeating the action. A confident message is not useful when it confidently states the wrong outcome.

That distinction changes the work required behind the screen. Designers need to ask which outcomes the application can reliably identify. Writers then need access to those answers. Otherwise, even carefully edited wording can become a polite cover for an unresolved technical question.

Three pieces of information

For this exercise, a recovery message has three jobs: explain the current situation, identify the consequence for the task and offer the next safe step. These are proposed editorial criteria, not a claim that every problem can be solved with three sentences.

The situation might be a temporary connection problem. The consequence might be that an update has not been saved. The next step could be checking the connection and trying again. Each statement should be supported by the actual behaviour of the service.

Notice what is absent from that description: internal component names, unexplained codes and instructions that assume the person understands the application's architecture. An internal code may help a support team, but it should not be the entire explanation offered to someone trying to complete an ordinary task.

A UK reference worth reading

The GOV.UK Service Manual's guidance on writing for user interfaces recommends clear, inclusive wording and recognises that people may not read everything on a screen. Its guidance is written for public services; the practical application to a commercial app here is our own editorial interpretation, not government endorsement of Global Secure.

Applied to this example, the implication is modest. Put the consequential information where the person will encounter it. Do not hide the fact that a change failed beneath a long account of why the company values reliability. Empathy helps when it accompanies useful information.

Test the second attempt

A recovery flow should be reviewed beyond the first message. What happens if the person tries again and meets the same problem? Is their earlier input retained? Can they return to the previous screen without losing context? Does the support route explain what information is useful without inviting unnecessary personal disclosures?

A practical workshop could walk through those questions using sample details and a deliberately interrupted connection. The observer would record the person's decisions rather than simply ask whether the screen looked reassuring. No such workshop results are being claimed in this article.

For Shane Murphy's Global Secure product discussion, this is a useful pre-launch discipline: give the awkward moments as much attention as the welcome screen. A future product earns clarity through the whole journey, including the point where the expected journey stops.

The proposed review ends with a small evidence record: the task attempted, the state the system recognised, the message shown and the next action available. That record makes it easier to correct a specific weakness instead of rewriting every message at once.

Reference: GOV.UK, Writing for user interfaces — https://www.gov.uk/service-manual/design/writing-for-user-interfaces

Professional information: https://shanemurphy.co.uk/

LinkedIn: https://www.linkedin.com/in/shanemurphy101