and what of
practical futurism
The manifesto of Practical Futurism is intentionally short, since the practical futurist knows that most readers will encounter their manifesto while on the toilet.
What follows is a manifesto for a design philosophy I call practical futurism.
Practical futurism is designing for life as it is — not as one imagines it to be or wishes it was.
To understand the world better, the practical futurist turns to the only human they can hope to fully comprehend — their self.
Make Something You Want
"And these... people... are they in the room with us right now?"
Practical futurists start by responding to every problem with a question to themselves: “Do I like this?” “Would I use this?” “How would I use this?” “When would I use this?”
This little trick works because we are, first and foremost, humans designing for other humans.
A practical futurist would never design something they had no interest in using. This might sound selfish — and there is, of course, a risk of over-fitting your own tastes. But if you don’t love what you build, no one else will either.
When designing, think deeply and clearly about your own experiences. How your habits, not your wants, often shape your decisions. Think back to what you have downloaded and never used, and unpredictable objects you have fallen in love with and cannot stand to live without.
Most people don’t know themselves anyway, so don’t bother asking them what they want.
An even greater number of people are terrible designers (and this is fine; there are far more important jobs to do!)
Design for yourself. Let your selfishness fuel your work. All good work comes from love. So love yourself.
This answer isn’t always practical depending on the domain or size of your company. There are alternatives. Experts can play an important role in understanding new domains. Experts are those closest to the problem you’re solving — people who understand a given problem better than just about anyone in the world.
Side Note: On Interviewing Experts
And whatever you do, do not survey these experts — you’re wasting their time and yours. Just talk to them. Surveys are built on assumptions and, at best, can only confirm or reject your assumptions.
Think ahead about what you’d like to ask — but don’t become attached to your presumptions.
Jot down important quotes and experiences — lived experiences are far more powerful than imagined empathy.
A case for designing the future iteratively
There are fundamentally two ways to solve a problem.
- Start with what exists, and change only what is necessary.
- Start from scratch. Throwout the old, take a wild guess.
Good designers usually start with what exists and change as little as possible.
Why?
Everything that exists is an amalgamation of tradeoffs, compromises, and lessons learned — accumulated over years, decades, and centuries. This axiom plays out in every field, but perhaps none so often as software development.
Joel Spolsky famously wrote about this in the context of a disastrous refactor for Netscape 5.0.
We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.
But old code has been used. It has been tested.
(my manager at SpaceX originally shared this article with me, in order to convince me to leave things alone!)
Like code, every design that exists today has been used, often by billions of people. It has been fixed where needed.
This does not mean we shouldn't change things. It also does not preclude radical change.
It just means: let every change have a purpose — a problem solved, a story to tell. Let your design be a log of lessons learned.