Murphy’s Law is the cheerful little reminder that “anything that can go wrong, will go wrong”.

In UX and product design, Murphy’s Law captures the grim inevitability that if there’s a way for something to fail – no matter how unlikely – it eventually will.

A feature will break at the worst possible moment. A user will try the one interaction no one tested. A stakeholder’s favorite edge case turns out to be a real-world requirement. Murphy’s Law isn’t pessimism – it’s about preparation.

ORIGIN

While the concept itself had been known for a long time, the phrase “Murphy’s Law” is attributed to Capt. Edward A. Murphy Jr., an engineer working on U.S. Air Force projects in the late 1940s. During testing, sensors were reportedly wired incorrectly, prompting Murphy to make a remark along the lines of: if there is any way to do something wrong, someone will do it.

From there, the saying evolved into a broader principle: Anything that can go wrong, will go wrong – often at the worst possible time. Over decades, Murphy’s Law spread from engineering into business, risk analysis, and eventually UX/product design.

In design, Murphy’s Law reminds us that no matter how confident we are in a workflow, users will test its limits – and technology will surprise us.

WHEN

You can feel Murphy’s Law in the following situations:

• The edge case becomes the real case
  Nobody thought anyone would enter that combination of values. Someone did.

• Two perfectly good features meet each other
  They work beautifully apart. Together, they have irreconcilable differences.

• The demo fails during the demo
  It worked fourteen consecutive times beforehand. Murphy appreciates an audience.

• A tiny change breaks something completely unrelated
  The button moved three pixels. Authentication has stopped working in Belgium.

• Reality refuses to follow the happy path
  Sessions expire. Permissions change. Users double-click unexpected things.

• The “impossible” scenario happens in production
  Apparently unlikely and impossible are different words for a reason.

• You hear: “We tested everything.”
  Murphy has entered the chat.

WHY

Murphy’s Law isn’t mystical – it’s a natural consequence of complexity and uncertainty. The more complex the system becomes, the larger the space between what we’ve tested and what can actually happen.

• Assumptions are imperfect
  We design around what we expect users to do. Users remain stubbornly unaware of the plan.

• Dependencies fail
  Products rely on APIs, networks, browsers, operating systems, devices, permissions, and other products that have their own Murphy’s Laws.

• Combinations multiply
  A feature might work across five browsers, six locales, four account types, three permission levels, and ten data states. Test all combinations and we’ll see you next year.

• Timing matters
  Latency, asynchronous updates, caches, retries, and simultaneous actions can create states that never appeared during the beautifully controlled prototype.

• Users are inventive
  People paste strange values, open multiple tabs, press Back at inconvenient moments, and lose connectivity halfway through actions.

HOW

Murphy’s Law doesn’t mean designing for every imaginable catastrophe. It means designing products that remain resilient when reality deviates from the plan.

• Question the happy path
  Ask what happens when information is missing, duplicated, delayed, incorrect, unusually large, or arrives in the wrong order.

• Design defensively
  Use sensible defaults, validation, constraints, guardrails, and clear system states to prevent avoidable failures.

• Make failure recoverable
  Provide undo, retry, autosave, version history, useful error messages, and ways back from mistakes.

• Test beyond the obvious
  Include unusual devices, locales, accessibility settings, permissions, data volumes, network conditions, and combinations of features.

• Watch real users
  People will interact with your product in ways no test plan predicted.

• Monitor what testing misses
  Logs, analytics, support reports, crash monitoring, and user feedback reveal the scenarios that escaped before launch.

PRO TIP

The goal isn’t to predict everything that can go wrong. It’s to make sure the product knows what to do when something does. Plan for resilience and design so that users can survive failure.

EXAMPLES

Places where you can observe Murphy’s Law in action include the following:

• A form works perfectly until a customer enters an unusually long name or unexpected character.
• Two filters work independently but produce an error when used together.
• A checkout submits the same order twice because the network is slow and the user presses Pay again.
• A dashboard performs beautifully until a customer’s dataset becomes ten times larger than the test data.
• An upload fails halfway through when the network connection disappears, taking all the user’s progress with it.
• A feature works everywhere except one combination of browser, locale, accessibility setting, and account permissions.
• A release fixes one workflow while causing a regression somewhere apparently unrelated.
• The flawless live demo encounters the one error nobody has seen before, approximately six seconds after the presentation begins.

CONCLUSION

Murphy’s Law isn’t a curse – it’s a reality-check that leads to more resilient design.

We can’t anticipate every user action, device state, network failure, strange dataset, third-party outage, feature interaction, or perfectly timed production bug. Trying to eliminate every possible failure would prevent us from shipping anything at all.

But, good products anticipate mistakes, detect problems, communicate what happened, preserve users’ work, and provide a way forward. They assume that eventually something unexpected will happen – and prepare accordingly.

And just in case you didn’t know, Murphy’s Law applies to Murphy’s Law, meaning that even the law’s own explanations, citations, or attempts to prove it will somehow get messed up or misquoted. Have a good night.