The Shackles of Simplicity
Simplicity has been at the core of the web's philosophy of design for the last five years. Whether it's a major part of the visual approach, with large amounts of negative space, simple color palettes, and a focus on strong typography; the interface approach, with fewer things on a given page; or the product approach, with products that do "one thing well"; nearly everyone has carried the banner of simplicity at one point or another.
But while this approach has indeed helped us make products on the web that can appeal to a mass audience, it is starting to show its limitations. After a few months (weeks?) of using a simplicity-centric product like Basecamp, you start to run up against its limitations: it may facilitate the way that the creators work best, but you're not quite like the creators. Maybe you've outgrown the simple feature set and need more for your modestly-growing needs. Maybe you no longer have a few months' worth of content in the system, but now have years of content, and managing it all has become a bear. Simplicity is beginning to fail.
Part of the problem is that simplicity is the solution to a problem poorly-identified. Life is complex, and tools to conquer life's complexity need to instead embrace it, rather than ignore it.
A former student of philosophy, I can't get away from a conversation about simplicity without bringing up Occam's Razor. This principle, commonly referred to as the *simplicity principle*, is core to all logical and philosophical argument, and really ends up being at the core of the contemporary drive for simplicity in design.
The idea is that the best solution to any problem is that which has the fewest assumptions or factors, eliminating anything from the equation that doesn't matter enough to impact the outcome.
This sounds pretty straight-forward, and is a great tool for evaluating your own progress toward the solution to a problem. However, the devil, as always, is in the details. It's easy to eliminate a factor -- it's much more difficult to know that it doesn't matter enough.
Some concepts just aren't simple, no matter how they're framed. A few weeks ago, I was talking with Ali about her work on a guerilla redesign of the Supreme Court's website. As we were talking, we kept coming back to the fact that stakeholders involved were chasing after simplicity, and Supreme Court decisions aren't simple. A legal decision at that level can't be boiled down to a score like a baseball game, and even the most succinct summaries require a bit of background.
Complexity isn't confined solely to the fields of law and medicine. In fact, common, everyday tools often need explanation and clarification to be adequately understood. Other times, many simple tools need to come together in a way that creates complexity.
By trying to simplify the inherently complex, you're likely to run into one of two outcomes:
- You may find yourself beating your head against a wall, searching for the simpler representation that doesn't actually exist. Time is wasted, frustration ensues, and bad decisions get made.
- You over-simplify the problem. This is a frequent problem with everything from project management software to explanations of Supreme Court decisions. It's the result of ignoring the importance of certain parts of the problem that, in the end, cannot be ignored.
In the end, Ali's redesign was an overall success, but there are specific parts of the interface that are over-simplified and actually end up being misleading rather than helpful. They're small factors, but they detract and distract from the otherwise-overwhelming success of the project.
Instead of valuing simplicity, consider valuing focus. If your design focuses on specific goals or tasks, like being able to manage domain names, you're able to embrace simplicity or complexity as it makes sense.
You may make the process for renewing a domain name incredibly simple, where the process for managing DNS entries could vary in complexity depending on the task -- adding a subdomain may be simple at first, but complexity could be allowed for changing a subdomain's TTL. If you've ever had to transition a website from one server to another, you know how important the ability to manage a TTL can be to a smooth transition, but many domain name providers don't provide an interface to make that adjustment, seemingly with the goal of simplifying the interface.
Focus allows you to create features for more advanced or experienced users, who often allow and in fact desire complexity. Focus also allows you to ensure that new users are able to complete tasks as easily as possible, without oversimplifying the problem. Focus provides liberation from the bonds of simplicity while still providing the constraint that aids successful design.
When you come across complexity within the scope of a focused design, the question moves to how that complexity can best be managed. While this is the topic for at least a book or two, there are a few strategies worth sharing that can help move a design toward success.
- Realize that managing complexity can be hard. Devising a good solution to a complex often problem takes really smart, talented, creative people a significant amount of time. Expecting to address a complexity challenge in a couple of hours is relying on luck.
- Address complexity visually. If the most complex parts of the process are secondary actions, treat them that way visually, allowing users to focus on the core. If they're primary, make sure that all possible clarity is given to the interface, so as not to muddy the already-confusing waters even further.
- Consider chunking tasks based on complexity. If a problem has multiple parts, separating the more complex ones from the simple ones can help aid usability. This can be as simple as having a view that turns on the "advanced features" or it can allow multiple paths through a process, depending on the needs and desired outcome.
- Take the entire system into account when looking for efficiencies. If you've got laser-like focus solely on your design, you may be missing opportunities to leverage other parts of the system. A mobile phone's GPS chip may be a piece of the system you can leverage if location is a significant factor in your design. For internal corporate products, for instance, other internal systems (like payroll, user directories, or scheduling systems) can be used to make the product you're designing "smarter," thereby helping a user through a particular task.
- How would a good teacher help a user through this process? Teaching helps newcomers understand complex ideas long before and after we're in school. Consider how you might best teach users confronted with this task, and enable the system to do that teaching -- or better yet, get a good teacher's opinion. Whether it's a little extra explanation around a form field, a clearer path to the finish line, a modular form that adjusts to user input, or even a video walk-through, teaching can help a user get a hold of her wits and achieve the desired outcome.
All of this management of complexity is assuredly complex in itself, but it's not something we can eliminate from the problem with Occam's razor. It's part of our jobs as designers and architects to tackle the hard work along with the easy work, and that means solving the whole problem.
Hopefully the next five years will be those where web designers learn to focus, rather than simplify. If so, we'll be making new tools that not only work well, but help us conquer some of life's more complicated problems.