Death to Process Machines!
You hear a ton of different advice on the right and wrong way to go about designing an app or website.
“You should be using Figma.”
“Design Systems or GTFO.”
“Real Designers design 100% in code.”
“Wireframes are a waste of time.”
“If you’re not making prototypes, you’re not doing it right.”
“You need to start on paper.”
You’d think there’s no agreement whatsoever about the right way to design, but there’s one point that’s largely free of controversy — that your process should be linear.
The classic linear approach looks something like this: research → sketch → wireframe → static comps → prototype → code
It’s kind of like those Rube Goldberg-esque manufacturing machines they use to make Doritos and Ding-Dongs. Drop an idea into the process machine, and after getting mashed and molded into shape as it winds through the steps a finished product pops out the other side! Predictable! Efficient!
Process machines work, but only when they work. They don’t adapt, and that makes them fragile. All it takes is one little Sabot to grind your process machine to a halt.
Hank, a.k.a. “the Sabot”
I’ve been watching Finding Dory with my kid lately, and part of the “making of” footage keeps jumping out at me.
In the movie, there’s this octopus named Hank. Septopus, technically. His character model was so onerous to work with, they lopped off a tentacle to make animating him doable. Still, with 4,000 separate controls he was incredibly challenging to work with.
At this point in the process, they’re well past sketches and renderings and animatics — those lower fidelity stages that help you vet a bunch of ideas quickly and cheaply. They already Got Real too. The character rig was built, technical details worked out, fundamental questions answered.
They’re in the final animation stage — 3D models in 3D environments. They could have soldiered on at the expense of the production schedule and budget. Instead, they did something really interesting — they went back to sketching.
By sketching out the complex movement of Hank’s tentacles on paper, they could nail down the perfect, fluid animation they were looking for in a fraction of the time. Once they were happy with the sequence, they’d animate in 3D to match. They got a better product in less time because they chose to value process principles instead of a process prescription.
The cure for a prescriptive process
The Finding Dory team made a better product faster by making decisions that prioritized speed and quality instead of sticking to a fixed process.
You might choose other things to value, but if you’re working in a commercial setting, focusing on the sweet spot between speed and quality should be at the top of your list. Turning around great work quickly is kind of a big deal for professional designers and artists after all.
If you value speed, start a project by figuring out what the biggest, most fundamental questions are. In Getting Real, this is called “epicenter design”:
Start from the core of the page and build outward
Epicenter design focuses on the true essence of the page — the epicenter — and then builds outward. This means that, at the start, you ignore the extremities: the navigation/tabs, footer, colors, sidebar, logo, etc. Instead, you start at the epicenter and design the most important piece of content first.
Whatever the page absolutely can’t live without is the epicen- ter. For example, if you’re designing a page that displays a blog post, the blog post itself is the epicenter. Not the categories in the sidebar, not the header at the top, not the comment form at the bottom, but the actual blog post unit. Without the blog post unit, the page isn’t a blog post.
Only when that unit is complete would you begin to think about the second most critical element on the page. Then after the second most critical element, you’d move on to the third, and so on. That’s epicenter design.
Epicenter design eschews the tradtional “let’s build the frame then drop the content in” model. In that process, the page shape is built, then the nav is included, then the marketing “stuff” is inserted, and then, finally, the core functionality, the actual purpose of the page, is poured in to whatever space remains. It’s a backwards process that takes what should be the top priority and saves it for the end.
Here’s an example of why this is crucial. I was working on a little side project iOS app that used a unique, possibly unworkable audio interface. If I didn’t value speed, I could have spent countless hours designing the myriad details that rested on the foundation of this one oddball idea. Design comes before code in the classic linear process, after all.
Instead, I started in code to figure out whether or not this idea was viable. It wasn’t! So I adjusted my plans, and saved myself an enormous amount of time and energy.
Once you know the questions that need answers first, ask yourself: “Which medium gives me the clearest answer to my questions in the least amount of time?” A venn diagram of ‘clearest answers’ and ‘fastest to make’.
In the case of my side project, the answer was code. For a page on Basecamp.com, the answer is often text or a rough sketch. For you, it might be something else entirely.
Knowing when to change gears
That gives you a place to start, but how do you know when it’s time to switch to a different medium? When you hit resistance.
Think about driving a car. You’re cruising down the highway — engine purring away like a contented kitten. But then you start driving up a hill. The gear you’re in was great for cruising, but not for hill climbing. In order to keep up your speed, you shift into a new gear.
Same thing here. But unlike cars, there’s no rock solid indicator that you’ve hit too much resistance in your medium of choice. Luckily, most designers and artists have a solid handle on when you need to switch to a medium that offers more fidelity. This is the part that lines up with the classic low fidelity → high fidelity linear process after all. You know you’re ready to move on from sketching when sketching stops giving you useful insight.
Once you’ve hit this point, figure out the next most important set of questions and ask yourself again: “which medium gives me the clearest answer to my questions in the least amount of time?”
The second case — shifting back to a lower fidelity — is tougher. Both because people are less practiced at it, and also because it’s tricky. Take working in code. You’re working at 100% fidelity, so there’s no limit to the medium’s ability to answer questions. But there is a limit to its ability to answer questions fast.
When you feel yourself not pursuing paths because it feels like too much work, that’s a really good sign that you need to back out. When things feel like they just aren’t clicking like they should, it’s time to reassess. Be mindful, and you’ll start to develop a feel for it.
Using a medium to your advantage
There’s a third case for switching to — or sticking with — a medium. This one doesn’t care about resistance, it only cares about a fundamental truth; process influences outcome. Just like drawing something with a pencil is going to look different than drawing it with a marker, designing in browser is going to produce an different outcome than designing in Sketch.
The more you understand how a medium affects your work — the kind of tool marks it leaves — the more you can use it to your advantage. Want your design to be expressive? Probably better to work with a visual tool like Sketch, Illustrator, or even gasp Photoshop. Want a minimal, lightweight design? Stick to designing in code.
Hopefully this gives you some insight into how you can use principles to guide your process on case-by-case without feeling like you’re constantly reinventing the wheel.
Think about your process and the kind of work that you do. Define the principles that are important to you, focus on the big stuff first, and keep questioning if the medium you’re working in is the right one for the moment.