top of page

Defensive Design Framework

Updated: Oct 4, 2023

Murphy’s law states that whatever can go wrong, will go wrong. And when things go wrogn, you better have a contingency plan, or your design will fail.

Read on to walk away with a framework that will help you design defensively against the inevitable points of failure.

What is Defensive Design

When we design something, we generally assume that everything is going to be fine, users will go through a smooth journey, and will reach their goals. However, the fact is, without intentionally deploying defensive design, you will be able to avoid only a few crisis points–the points of failure–for your users, and they will inevitably hit crisis points, some big some small.

Internet not working, accidental interaction or key-press, forgotten password or other details, environmental disaster, physical disability etc. are all examples of crisis points, which in one way or another, put throw the users off track and hinder progress towards goal. When these crisis points do occur, one of these two things will happen:

  1. Users will drop-off or fail in achieving their goal

  2. They will succeed, but with (great) difficulty, and hence end up frustrated.


Of course, you don’t want any of this to happen. So here is what can be done to better manage the crisis points:

  1. Systematically identify the possible crisis points, and do what you possibly can to prevent them.

  2. Prepare your users and let them know what to expect.

  3. Hand-hold your users when they need it, and direct them in the right direction.

  4. When things go wrong, help your users recover and correct their course.


Possible Crisis Points

Here is a list of types of crisis points. Now this list is not exhaustive (can never be!), but it is a good starting point to get you started with thinking about the possible crisis points and listing them down systematically.


  1. Blocked

  2. Resolution

  3. Precision


  1. Internet

  2. Server

  3. Traffic


  1. Light

  2. Noise

  3. Crowd

  4. Disaster

  5. Season


  1. Rights

  2. People

  3. Resource

  4. OS

  5. Plugin


  1. Domain

  2. Tech

  3. Workflow


  1. Physical

  2. Mental

  3. Emotional


  1. Behavior

  2. Emotion

  3. Need

  4. Use Case


  1. Accident

  2. Error

  3. Monkey

The crisis points above are elaborated below:


Hardware used by user might be blocked

Resolution might not be supported

Precision of user device might be low


Internet might be slow or dodgy

Server might fail or crash

Traffic might be too high or too low or highly variable


Ambient brightness might be too high or too low or highly variable

It might be too noisy or user might need silence

It might be too crowded

A natural disaster

A seasonal change or spike


Users may have different kinds of access rights (role-based)

All the people may not have access to everything

Access to resources might be limited

OS based restrictions might apply

Plugins might or might not be supported


Users might not have the required domain expertise

Users might not have the required tech expertise

Users might not be aware of the workflow (real world scenario)


People are differently abled physically

Mental capability of people do vary

People are emotional beings


Behavior is idiosyncratic

Behavior might be impacted by their emotions

Usage varies widely based on user needs

Usage varies widely based on business use case


Accidental interactions might happen

Users or system my commit errors

Users might just be fooling around

Defensive Design Tactics


  1. Accepting

  2. Allow for multiple correct input formats

  3. Correcting

  4. Provide smart defaults that reflect the best practice or aid the current task

  5. Error messages should be explicit, precise, and human

  6. Error messages should be constructive, not accusing, and offer a solution.

  7. Validating

  8. Auto check for errors in a timely manner


  1. Messaging

  2. Use language as expected by the user and stay away from jargons

  3. Hinting

  4. Make suggestions to help user navigate in the right direction

  5. Make required fields or tasks clear

  6. Provide appropriate guidance to the user to ensure he or she moves through desired path


  1. Back

  2. Allows forward and backward navigation, while keeping the progress saved

  3. Exit

  4. Provide and explicit exit option at all workflow stages

  5. Next

  6. Provides clear calls to action

  7. Allows forward and backward navigation, while keeping the progress saved

  8. Do not lead users to a dead-end

  9. Orienting

  10. Help user understand where they are


  1. Telling

  2. Notify user of the wait time, progress and part remaining for the processes

  3. Ensure that your users are equipped with knowledge to make the right choices in the process

  4. Use the context and don’t force the user to start from scratch

  5. Matching

  6. User actions should result in expected outcome


  1. Prevalidating

  2. When user chooses between options, ensure that the content presented is a per expectation

  3. Remove all that is not required to accomplish the user goal

  4. Limit the choices for the user, in context to current task

  5. Limiting

  6. Limits available choices in context to the current task

  7. Masking

  8. Ensure that the interactive controls or elements follow expected interaction behaviour

  9. Allow for multiple correct input formats, with proper constraints to avoid errors

  10. Doing

  11. Automate work when required

  12. Asking

  13. Provides a review state before the final step

  14. Ask for confirmation before potentially destructive actions

  15. Telling

  16. Provides feedback when an action is complete

  17. Display user’s selected choices, in current context

  18. Communicates wait time and progress for processes

  19. Saving

  20. Allows forward and backward navigation, while keeping the progress saved

Once you have listed down your crisis points, you can start applying the techniques from the checklist below to help you better tackle these crisis points.

Let’s take an example

Every-time I visit IRCTC to book a railway ticket, I wonder why the website sucks? I always knew that there were a bunch of things going wrong, but I lacked a framework to pin down the issues. While working on defensive design, I tried to apply this framework on the website to diagnose the issues, and to my surprise, the site failed on all the points highlighted in yellow below:

Defensive Design Issues with IRCTC
  1. Resolution: There is no mobile version

  2. Server: Server is poorly equipped to handle peak traffic

  3. Traffic: Traffic is highly varied

  4. Season: During holiday season, the site simply fails to load or doesn’t take care of special user needs

  5. OS: The site behaves differently on different OS

  6. Domain: Not all the users are aware of internal terminology (e.g. Tatkal or Train Number)

  7. Emotion: User booking for tatkal or holiday are highly stressed

  8. Use Case: Multiple or Round trip journey use cases a poorly handled

  9. Accident: Accidental interactions (hover) result in server calls

  10. Error: Site throws unfriendly and technical error messages

I now exactly know if were to fix 10 things with IRCTC website, what those are.

I have tried my best to keep the list and framework exhaustive, but as I said earlier, you should use this as a starting point. Use my list to identify your crisis points and the framework above to tackle those. Feel free to add to it, and most importantly, to tell me about it.

I hope this will help you in looking at your designs with a defensive lens and making them more error proof.

Recent Posts

See All


bottom of page