Designing with ‘eh’
Eh is one of the most powerful tools in a designer’s toolbox. Here are some examples:
- “Eh, we’ll figure it out later.”
- “Eh, that doesn’t matter right now.”
- “Eh, no one’s going to notice that anyway.”
Eh is your personal Spidey sense. It tingles when you get close to building the actual thing and tells you to back off. It helps you manage how much and what to polish. It keeps you focused on the big picture.
So how does it work?
The art of approximation
When you’re a designer-engineer hybrid and you spend a lot of your time prototyping, you learn to approximate. You become proficient at creating the appearance of something else. It’s an important feature of prototypes: they look and work like the real thing, but they aren’t. That they aren’t isn’t important to whomever you’re testing the prototype with. What’s important is that they can’t tell the difference.
If effective prototypes are illusions, you’re the illusionist.
Steve Jobs once said to paint the back of the fence white “because you’ll know”. You explicitly choose not to, because you know they won’t know. And in order to prevent them from knowing, you need to figure out and develop a sense of intuition around what’s important. Architecting the database for scalability is not important. But perfecting the page transition animation so that it’s smooth, responsive and delightful might just be.
One of the most valuable metrics of prototyping is iteration speed. You need to be able to make something, get feedback, make adjustments, get more feedback, repeat — until you figure out whatever it is you’re supposed to figure out. But you can’t iterate quickly if you can’t prioritise. That’s where the intuition comes into play, which is chiefly a function of experience. The more stuff you’ve made, the more you’ve internalised about what will work and what won’t.
Prototyping also relies on being capable at both design and engineering: you can’t move fast if you have roundtrips to the designer or the engineer each time. You must collaborate with both, sure, but the better you are at each, the less you need to bug them.
Sketching with code
When I’m prototyping, I’m continually approximating. Is this feature done enough? Will this roughly convey affordance to the user? What are our top three accessibility goals? Is this visual design element really that important right now? Are we even going to have that many elements that we need to optimise performance in this area? Do we need to test in that browser? What does this look like on that screen?
Is it enough? Is it passable? Is it a rough approximation?
You ask these questions when building or designing things, too. The key difference is that the answer to those questions, for production, usually needs to be relatively solid (not always, because deadlines happen). But when prototyping, you can kind of “eh, we’ll figure it out later” your way through many of these decisions.
Eh is a powerful gesture that lets you get away with a lot in service of a better experience, pushing harder to find the thing you were looking for. Eh stands for 95% done, not 100%. It’s trading idealism for pragmatism. Embracing laziness rather than being a perfectionist. Eh is pushing back against fidelity: as soon as you stop sketching with code and try to switch out to a more detailed representation, eh is there to wag its finger at you.
Eh, I’ll finish this post later.