Designers, developers, marketers, stakeholders tend to have some crucial blindspots when working on a project. Specifically, we tend to forget about disasters, failures, or even missing pieces.
As a designer, I tended to think about the best-case scenarios, and designed for that.
This page will look so good once we have all the content and we display at least 4 PDFs.
But what about when the page goes live and you only have 1 PDF? What if the content is missing altogether? As a developer, I’ve become a worst-case designer.
Most projects start with no content, so I see where the design breaks down when things are missing. Do I hide just this section if there are no images or other content? What happens when someone filters so much that there are no longer any results that match? What if the API breaks and doesn’t return any content?
Taking careful inventory of these failure points can help you make a better product, website, campaign, project, etc. You won’t be able to predict all the failures or bugs, but ignoring the possibility of those occurring is a poor strategy no matter what you’re working on.
How do we kill it?
You can see this in your own work: what are the things people forget about when they come to you? What do you have to fix in the process of your work? What are the common mistakes that you make?
A lot of tech companies think it’s cool to do a “post-mortem” meeting, where they pull everyone in and the leaders complain about what went wrong. It’s supposed to help the team get ready for the next projects and learn from the mistakes of the most recent project.
This might work well at some companies, but I haven’t seen it make much of a change on the teams I’ve worked with.
A better option might be—as Annie Duke suggests in her book, “Quit”—to run a “pre-mortem” meeting. We start the project with: “What would be disastrous with this project? What might kill it?” This puts us in a problem-solving state of mind before we have skin in the game.
Looking ahead for the danger has yielded more results than using hindsight to poke holes in a completed project.
Track the failure points
Zooming into the individual level, it is worth taking notes around common mistakes, oversights, and roadblocks.
I’m trying a new method where I’m compiling different types of checklists for different types of projects. There are certain things I tend to forget to do when wrapping up a project, and it results in lots of Slack messages from users asking for help. Here’s an example:
- [ ] Assign permissions to the correct group
- [ ] Create a walkthrough
- [ ] Announce the change and the new walkthrough in Slack
Checklists are an extension of our memory. They help offload cognitive burden in trying to constantly retain these steps (which doesn’t work well in my experience anyway).
These lists also help us find and track our failure points—every time we discover something, we can add that to the checklist. For the times when a checklist item doesn’t make sense, taking notes of the failure and the solution is another helpful tactic.
Notes and boards
I’ve been using Obsidian at work to keep track of unique error messages and their solutions. I also keep track of prior solutions to the “missing content” problem. That way, I can look up what I’ve done before and if the solution works in my current use-case, I copy and paste the relevant code.
Designers could use inspiration boards to track solutions to UI failure points (how did Company X solve the cookie banner problem? What are potential solutions to a filter with no results?)
Marketers can take note of their a/b test results and build a portfolio of ideas that have solved tough campaigns or that didn’t perform well. Did we send an email that had a broken token, so it greeted all of our subscribers with “Hi, < first name ”? What did we forget in our conversion tracking paths in Google Analytics?
Build up your own version of Stackoverflow (a technical forum for questions and answers), and you’ll start solving these issues more quickly.
Cyborg level
Integrating this practice of designing for disaster can help us at work, but also other aspects of our lives.
Driving somewhere is a simple one. Are you leaving in order to be right on time? Or are you giving yourself some buffer time in case of slow traffic?
If you designed your trip with disaster in mind, this does a few things for you:
- Reduces stress because it removes the rush.
- Makes for a safer trip for everyone: Drivers in a hurry take more risks, get more impatient and frustrated. Impatience while driving increases the danger for everyone around you.
Sometimes technology gives us the illusion that we live in a fast, convenient, easy world. Then something breaks and it causes frustration, sometimes disproportionate to the issue.
The cyborg recognizes this and tries—just tries—to remember that all systems have points of failure.
Systems can be exceptionally helpful and streamlined, but they all touch the real world in some way, which means they aren’t fool-proof, permanent, nor infallible.
Designing for disaster is our best bet against the unknowns—and it encourages a learning mindset where we learn from our experience and build from our mistakes.