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.
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.
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
Network
Environment
| Access
Knowledge
Ability
| Usage
Action
|
The crisis points above are elaborated below:
Hardware
Hardware used by user might be blocked
Resolution might not be supported
Precision of user device might be low
Network
Internet might be slow or dodgy
Server might fail or crash
Traffic might be too high or too low or highly variable
Environment
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
Access
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
Knowledge
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)
Ability
People are differently abled physically
Mental capability of people do vary
People are emotional beings
Usage
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
Action
Accidental interactions might happen
Users or system my commit errors
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:
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.
Comments