You are here : Home > Blog > Defensive Design Framework

Defensive Design Framework

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:

  • Users will drop-off or fail in achieving their goal
  • They will succeed, but with (great) difficulty, and hence end up frustrated.

Defensive-Design-Crisis

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

  • Systematically identify the possible crisis points, and do what you possibly can to prevent them.
  • Prepare your users and let them know what to expect.
  • Hand-hold your users when they need it, and direct them in the right direction.
  • When things go wrong, help your users recover and correct their course.

Defensive-Design-Delight

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.

Hardware

  • Blocked
  • Resolution
  • Precision

Network

  • Internet
  • Server
  • Traffic

Environment

  • Light
  • Noise
  • Crowd
  • Disaster
  • Season

Access

  • Rights
  • People
  • Resource
  • OS
  • Plugin

Knowledge

  • Domain
  • Tech
  • Workflow

Ability

  • Physical
  • Mental
  • Emotional

Usage

  • Behavior
  • Emotion
  • Need
  • Use Case

Action

  • Accident
  • Error
  • Monkey

The crisis points above are elaborated below:

Hardware
Blocked Hardware used by user might be blocked
Resolution Resolution might not be supported
Precision Precision of user device might be low
Network
Internet Internet might be slow or dodgy
Server Server might fail or crash
Traffic Traffic might be too high or too low or highly variable
Environment
Light Ambient brightness might be too high or too low or highly variable
Noise It might be too noisy or user might need silence
Crowd It might be too crowded
Disaster A natural disaster
Season A seasonal change or spike
Access
Rights Users may have different kinds of access rights (role-based)
People All the people may not have access to everything
Resource Access to resources might be limited
OS OS based restrictions might apply
Plugin Plugins might or might not be supported
Knowledge
Domain Users might not have the required domain expertise
Tech Users might not have the required tech expertise
Workflow Users might not be aware of the workflow (real world scenario)
Ability
Physical People are differently abled
Mental Mental capability of people do vary
Emotional People are emotional beings
Usage
Behavior Behavior is idiosyncratic
Emotion Behavior might be impacted by his emotions
Need Usage varies widely based on user needs
Use Case Usage varies widely based on business use case
Action
Accident Accidental interactions might happen
Error Users or system my commit errors
Monkey Users might just be fooling around

Defensive Design Tactics

Correction

  • Accepting
    • Allow for multiple correct input formats
  • Correcting
    • Provide smart defaults that reflect the best practice or aid the current task
    • Error messages should be explicit, precise, and human
    • Error messages should be constructive, not accusing, and offer a solution.
  • Validating
    • Auto check for errors in a timely manner

    Direction

  • Messaging
    • Use language as expected by the user and stay away from jargons
  • Hinting
    • Make suggestions to help user navigate in the right direction
    • Make required fields or tasks clear
    • Provide appropriate guidance to the user to ensure he or she moves through desired path

    Navigation

  • Back
    • Allows forward and backward navigation, while keeping the progress saved
  • Exit
    • Provide and explicit exit option at all workflow stages
  • Next
    • Provides clear calls to action
    • Allows forward and backward navigation, while keeping the progress saved
    • Do not lead users to a dead-end
  • Orienting
    • Help user understand where they are

    Preparation

  • Telling
    • Notify user of the wait time, progress and part remaining for the processes
    • Ensure that your users are equipped with knowledge to make the right choices in the process
    • Use the context and don’t force the user to start from scratch
  • Matching
    • User actions should result in expected outcome

    Prevention

  • Prevalidating
    • When user chooses between options, ensure that the content presented is a per expectation
    • Remove all that is not required to accomplish the user goal
    • Limit the choices for the user, in context to current task
  • Limiting
    • Limits available choices in context to the current task
  • Masking
    • Ensure that the interactive controls or elements follow expected interaction behaviour
    • Allow for multiple correct input formats, with proper constraints to avoid errors
  • Doing
    • Automate work when required
  • Asking
    • Provides a review state before the final step
    • Ask for confirmation before potentially destructive actions
  • Telling
    • Provides feedback when an action is complete
    • Display user’s selected choices, in current context
    • Communicates wait time and progress for processes
  • Saving
    • 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

    • Resolution: There is no mobile version
    • Server: Server is poorly equipped to handle peak traffic
    • Traffic: Traffic is highly varied
    • Season: During holiday season, the site simply fails to load or doesn’t take care of special user needs
    • OS: The site behaves differently on different OS
    • Domain: Not all the users are aware of internal terminology (e.g. Tatkal or Train Number)
    • Emotion: User booking for tatkal or holiday are highly stressed
    • Use Case: Multiple or Round trip journey use cases a poorly handled
    • Accident: Accidental interactions (hover) result in server calls
    • 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.

    DROP A COMMENT

    Your email address will not be published.

    Udit Khandelwal