I’ve seen many smart developers and entrepreneurs think of design as something beyond their reach, something magical that only unicorns can do. But there’s a more systematic, more concrete, and more rigorous way to think about design. Once we understand how design “works”, we can approach it as an engineering problem.
What is simplicity anyway? And how do we actually build it? We’ll dip our toes into computer science, economics, and psychology — a rationalized approach to simplicity in product design.
Nature is Lazy
Everything in the universe has a goal, and everything drives toward that goal in the laziest way possible. Lightning follows the path of least resistance. Water conforms to the shape of its container. Bees build hexagons to store the most honey with the least amount of wax. Why expend any more effort than necessary? Users are no different.
To be clear, I’m not saying our users are dumb or incapable. It’s exactly the opposite — our users are brilliant in their respective fields. And we want to support them, so they shouldn’t be wasting their time and energy on chores outside their areas of expertise, like getting a website up. They just want to get it done. Simplicity in design is helping them get there. So what’s stopping them?
Cognitive Load
Software takes effort to use. (Just read any Excel tutorial.) But it’s not just complex software that has this problem — even the most trivial actions must be mentally processed, consciously or not. When you see a button on a screen, you have to read and parse the text, you have to imagine what it’ll do, what part of the app it’ll affect, if it matches what you’re looking for, if it offers something you didn’t know about, if you should click on it, and if not, if you need to remember it for later. Your brain goes through all of this in a split second, mostly subconsciously.
A single button doesn’t sound so bad. But your app might have dozens of screens, hundreds of buttons, thousands of words. All those little packets of brainpower add up. It’s not that users can’t figure out how to use a button, it’s that they don’t want to. And why should they?
The brain is an incredible computer. And just as software developers write code for computers, product designers “write code” for human brains. But brains are far more fickle than computers, because they can get impatient, frustrated, or just decide to leave. Designers have to be nice to the brain. And the brain might not be willing to give you all of its power.
Software developers had this exact problem when computing power was scarce. In 1969, how did NASA squeeze the entire Apollo 11 guidance software to run on a 2MHz processor and 2048 words of RAM? They optimized like crazy. Every bit of memory and every CPU cycle was insanely costly (in time, money, and opportunity cost), so whatever they’re being used for better be worth it.
Nowadays, developers have access to orders of magnitude more computation power, so they don’t need to optimize down to the bytecode level. Designers aren’t so lucky. Brains today are just as finicky as brains in 1969.
“Simplicity” is a problem of optimizing for limited brainpower. In fact, we should be able to identify and even quantify brainpower “costs.” This is the economic approach to product design. Let’s see a few examples of brainpower costs, and the design lessons behind them.
1. Eliminate Hard Decisions
We make all kinds of decisions in life. Hard decisions: Which career to pursue, who to marry, how to deal with grief or depression. Easy decisions: What to drink at lunch, whether I need my umbrella. Non-decisions: Breathing, pooping. Software applications have the same hierarchy. Designing for simplicity means minimizing those hard decisions that require the most mental effort.
If you’re not tech-savvy and you want a website, there are a ton of hard decisions. Some are technical: What kind of hosting do I need? How do I make updates? Some are design-related: Which template do I choose? How should I lay out my text and images? How many pages should I have? Our users are not professional designers or developers. No one wants to crack open a technical manual or sift through web design tutorials. If the decisions are too intimidating, fear and dread take hold.
Here’s how we’ve addressed a few of the hard decisions our users face:
A. Which hosting do I pick? This technical question is a non-issue for Strikingly users. Hosting is built-in, and users can log in and quickly edit any site. It’s easy to take this for granted, since it seems obvious for a website builder, but it’s not obvious to tech newbies who might never have heard of servers or FTP.
B. Which template should I use? This is a design decision where users need some freedom to choose. We present a handful of choices — between 10 and 20 — not too much where it overwhelms, not too few where it feels restrictive. We categorize templates into use-cases (business, personal, blog, etc), which narrows the choices. We make sure each template is visually distinct enough so that users can recognize the use-case and whether they like the aesthetic.
C. How should I lay out my text and images? Drag-and-drop is a familiar pattern, but it can be difficult because there are too many degrees of freedom, and each one requires a decision from the user. Instead, Strikingly offers pre-built “sections” by default, e.g. for team members or a contact form. If you want to change layouts, there’s a single “Layout” button that will rotate through several presets. And finally, if you really want detailed layout control in the style of drag-and-drop, there’s a “Make Your Own Section” option at the bottom of the section selector.
D. How should I organize pages? Strikingly sites start as a single page by default, since it’s easiest to get started with. Multiple pages are an optional upgrade, and that opt-in comes with many more required decisions the user must make: What pages do I need? How many? In which order? How will I link to them? There’s no need to burden the user with these questions at the beginning. Instead, they can familiarize themselves with the core editing interface first.
Common wisdom says optionality is good — it lets the user customize their experience. But this only works if the user knows what each option means, the consequences it carries, and if there aren’t too many to pick from. Each time you present your user with choices, you’re forcing them to use some brainpower. “Pepperoni or sausage” is an easy decision, but “shared or dedicated server” is notably tougher.
Sometimes, the best solution is to remove the decision entirely by selecting a common default. If optionality is needed, make sure the options are few, easily understood, and easily differentiated. Don’t present options until the user actively needs them or is already thinking of them. And if possible, make the decision easy to undo.
2. Reuse Systems
A second type of costly action for the user is learning new systems. A system is just the set of rules for how something works. Learning a new language means understanding huge new systems like grammar, vocabulary, and pronunciation, each of which has hundreds of rules and quirks.
Software applications have a grammar and vocabulary of their own. In Strikingly, for example, “sections” are a system. A website is made of sections, and the user must learn what a section is and how it works.
The key property of systems is that they can be reused and extended. One system can support many functions, as long as those functions “work the same way.”
In Strikingly, once you understand how sections work, each additional section works similarly: All sections appear one after the other, you can add and remove them, and you can navigate to each one from the main menu. Each section may have unique functions, but those functions are contained and don’t spill out into other sections. In Strikingly, even the e-commerce and blog features are built into special sections — these special sections have even more functions within. The section system is an anchor of familiarity. It helps the user think “I can do this!”, and serves as the entry point for more advanced features.
A system can be anything that describes how something works — a feature, a UI framework, or even a copywriting pattern. It’s even better to use systems that the user already learned somewhere else. Google’s Material Design, for example, is a visual system, a set of rules that maps visual cues to functionality. There is some fixed learning cost, but once it’s learned, it can be reapplied, even across applications and devices.
A common mistake designers make is introducing too many systems needlessly,whipping up all sorts of widgets and components without considering learning cost. It might look beautiful and it might be fun to design, but it’s not fun for the user.
To minimize the brainpower cost, 1) Use systems the user already knows and 2) When introducing new systems, keep them easy-to-learn and reusable to get the most bang for your buck.
3. Scrub Away Distractions
If there’s a stain on someone’s shirt, you’re going to notice it. You don’t want to think about it, but if you catch a glance, it’ll bug you. Likewise in your product, every unnecessary word, line, or even pixel is a chance to distract your user, something they have to process whether they want to or not. They’re the stains of your application.
Most users won’t be able to identify visual design problems. They’ll just feel it. There are a lot of common practices of good visual design: The interface should emphasize the proper elements. Related elements should be grouped and aligned together. Elements should not have too much or too little spacing. Fonts should be easy on the eyes. Copywriting should be concise and easy to read. Any unnecessary elements should be removed. And so on… All these things will reduce the amount of mental effort required to decode a visual image into useful information.
Empathy
In software development, to make sure an app runs well, you might have to test it on different platforms. What if you’re using a Mac but need to test on Windows? You can use a program like VirtualBox to run a “simulated” Windows within OS X and test your app there.
Product designers do the same thing. Just as VirtualBox loads up a virtual copy of Windows with its own simulated CPU, RAM, and hard drive space, a designer should load up a user’s mind into their own, with all the simulated feelings, desires, and memories of that user. Just as a developer runs a profiler on the virtual Windows to see how much CPU and RAM your app uses, the designer should run a profiler on the virtual user’s mind to see how much processing power and memory they’d need.
This is a quantitative definition of “empathy”. It’s the process of simulating a user’s path through your product and analyzing the result. Design errors come from the disconnect between how the user thinks and how you think the user thinks. If you know exactly what makes your users tick, you can create products that they’ll immediately understand, will barely need to think about, and will be a joy to use. Simplicity is the result of using empathy to decrease cognitive burden.
Hidden Costs
How does all this fit into your workflow? If you want a new feature for your app (say, drag-and-drop), you’ll have to pay up. Here’s what a bill might look like:
1 | YOUR ORDER: |
Seems straightforward, right? But given what we know now, we’re missing some costs. Here’s what it really looks like:
1 | YOUR ORDER: |
This is your typical cost-benefit analysis, with a twist: We also quantify the mental effort the user needs to spend at every step. Think of it as a explicit cost of the feature, just like development time. You’ll need to simulate your user’s mind to make some intuitive guesses about how much brainpower is required.
It might seem strange to directly compare an abstract concept like brainpower with a concrete number like development time, but that’s actually how we make decisions every day — we happily trade our concrete hours and dollars for vague sensations of joy and purpose. The problem is not with the cost-benefit framework, but rather that it’s so easy to misjudge the exact costs and benefits. If we can better quantify the values, the framework becomes much more appealing.
It’s okay if your estimates are fuzzy. The actual numbers and units don’t matter as much as being able to compare totals. If a new product feature has a few possible design options, we can usually rank them by estimated total brainpower cost, even if we don’t list hard numbers for every detail. That ranking underpins any intuitive observation that “A seems more complex than B.”
And as we learn more about our users, the line items in the chart become more accurate. If, while observing a user use your app, a user takes a long time to figure out a certain screen, that’s valuable information about some brainpower cost.
Some interesting lessons will emerge:
- If a feature is only used by 10% of your audience, the remaining 90% still needs to understand what it does and decide if they need it. You can’t just add optionality everywhere.
- Development cost is fixed, but brainpower cost is per-user. If you have (or will have) lots of users, the total brainpower cost of your app will dominate and development cost may seem cheap by comparison.
- Different users have different tolerances for brainpower use. A power feature might be great for a power user, but might be a huge turn-off for a casual user. You can use barriers to funnel your users down to different features. Barriers can be “advanced” menus, unlockables, or even a paywall.
Of course, it’s not quite this simple — you might need to compare dozens of different possible implementations of a single feature, and see where you can save brainpower cost and where it’s worth investing. You can think of brainpower as a budget — you only have so much to spend across your entire app. On the flip side, there’s also the concept of brainpower “benefit”, which is akin to the mental delight or joy of using the product (but that’s another discussion).
Understanding these hidden costs is a powerful check against feature creep. It tilts the scales in favor of the most crucial and widely-used features, and the most seamless user experience. Over time, as you get better at quantifying the costs and benefits and weighing them against each other, you’ll have a handy guide for keeping your product simple.
Simplicity Everywhere
This whole process isn’t just for product designers — it works for making anything simpler. Simplicity is a way of life. Just step into the user’s shoes and look for mental costs you can cut.
- Inviting friends to a dinner party? Make the time and address obvious — they shouldn’t have to search for it.
- Stressed out about your messy room? Maybe you’re underestimating the mental burden of owning junk you never use.
- Writing an informative essay? Use clear language and punchy metaphors so the reader won’t get confused or doze off or forget everything they just read.
Economics and computer science offers an enticingly quantitative view of the world. This is how we’ve approached the problem of simplicity in design. Don’t be afraid to quantify the seemingly unquantifiable. It’s another tool in your toolbox, and in the end, this way of thinking can help bridge that uneasy gap between producer and consumer.