A company’s website is a vital part of their business, so they will want to make sure it provides the best tools and features for their users. However, one issue that can occur is Complexity Creep, in which as more features are added to a site over time, it becomes overly complicated and harder to understand for new users. As Diagram's Design Director, Dennis has a great deal of experience in addressing the issue of complexity creep, so Matt Brady, our Content Specialist, asked him about his thoughts on the subject, including how it can happen through good intentions and what designers can do to avoid it.
Hi Dennis! I recently learned about the issue of complexity creep in, of all places, an article about the Magic: The Gathering collectible card game. It got me thinking about how this problem might apply to web design. So let me ask you: have you found that complexity creep is an issue when designing websites or intranets? Is it something that you encounter very often when doing a redesign of an existing site? How do you address it?
Actually, yeah, we see it all the time, especially in redesigns. I think it’s a phenomenon that naturally occurs in every design process. The reason they call it “creep” is that it sneaks up on you. You do all this work at the beginning to simplify. Everyone wants their site to be simple and easy to use, you know? But then what happens is that over the course of the project, bit by bit things incrementally make their way back in. In those small doses, each bit seems pretty harmless. This makes it easy, and tempting to create some rationale for why a particular user is going desperately need that feature or content. If you don’t watch out, by the end of the project, you’ll end up right back where you started.
When you’re creating a new site, can you build it in a way that minimizes the issue of complexity creep? Is there a way to “future-proof” a site?
The article you referenced nailed it:
“The role of a designer is to only use what you absolutely have to. If a creation can exist without something, a good designer will take it away.”
The biggest challenge is having the mental discipline to stick to your guns. If you cull content or features, you need to bury them and move on. It’s helpful to recognize that it’s inherent human nature to want to keep the things you added. It’s loss aversion. I mean, think of it this way: somewhere along the line all this stuff was added. Calling them “features” just makes matters worse—it’s makes them sound really important. I mean, who wants fewer features in a new release of a site or application? It sounds like a step backward, right? Even though it’s counterintuitive, it’s often for the best. There’s a concept called interaction cost, which is the sum of the physical and cognitive effort required to complete an interaction. Everything in the interface—all the options you present to the user, it all needs to be processed. Each item that requires processing or figuring out increases the friction between your user and what they came to your site to find or do. Complexity can become an obstacle to usability.
Even to designers, the process of cutting features and stripping away details is painful. It’s because deep down we are all hoarders. It’s just like that show, have you seen it? Hoarders? It’s like that, except instead of cats, it’s content and features. But good designers often have a masochistic side, so they get accustomed to the pain of discarding things. Some even learn to relish it. Those guys are really sick! But it’s true: sometimes for the good of the project, you need to let go of a really great idea, a pet feature, or some delightful content. We call it “killing your darlings”.
For larger sites or intranets, it seems like increasing complexity is almost always going to be an issue.
It’s a very real and unavoidable issue. Here’s a good example. If you’re in software manufacturing, you might initially launch your product with a few core features. Then in each subsequent release, you introduce new features until you’ve picked all the low hanging fruit. At this point, you’ve probably addressed the primary use cases for what people want from your software. But you don’t want to remain stagnant, so you ask your users what to do to improve. They suggest new features, and you add them. As you go down this path, the features you add begin to cost more to implement because they’re more technically more complex. They also begin to appeal to smaller and smaller audiences. Remember, you already addressed the low hanging fruit, so these newer features might cater only to power users or edge cases. Your software can no longer scale cost effectively.
In that scenario, the problem is one of mindset—the idea that in order to improve the quality of an application, it must do more things. And so, with each release, you add more features, and the degree of complexity increases. But I think even the terms “simple” and “complex” are loaded. Most of what we must deal with is complex, sometimes incredibly so. The trick is in making something that feels simple to use. So really, it’s not complexity we need to avoid so much as complication. Complication occurs when there are too many things competing for attention, and not enough focus on the things that matter. On the other hand, if you can eliminate all the distractions and really focus on the core interactions you want to support, you’ll end up with a much better website or application. And when you get the itch to change things, don’t start scrounging for new features. Instead, do some testing. Validate that your core features are the ones people really want and need. Continually hone what you have until you’ve got something that performs well and produces the response you are looking for.
Have you found that there are any design techniques that intuitively direct people toward what they need to do or encourage users to keep things simple? Are there any global techniques that apply to everyone, or do you have to take it on a case by case basis?
It’s mostly process. I mentioned before about sticking to your guns. But in order to pull that off, you need to create a shared understanding of what you’re building and why. A lot of that needs to be determined before you start designing and building—it’s why discovery is so important. You’ve got to capture the vision for your project in a way that’s easy for everyone on your team to be able to access and refer to easily. This requires you to hash things out with your team and come to a consensus about what you’re going to focus on. Which objectives are most important? What are the core tasks you want to support? What fundamental design principles can you identify, to ensure that you don’t lose sight of the type of experience you want to deliver, even across future releases? Having all of those things documented is really powerful. It gives you a structured criteria for deciding what to add, and more importantly what to cut. If gives you a non-arbitrary way to know when to say, “no”.
These are some fascinating insights, Dennis, and it’s good to know that designers consider these ideas on a level that most of us don’t even think of. Do you have any other thoughts on complexity/complication vs. simplicity? Any resources on the subject that you want to share?
Generally speaking, the most successful apps aren’t successful because they do a hundred things, it’s because they do one or two things really well. They deliberately avoid introducing additional features. So I guess, whatever you are building, try to boil it down to its core. Once you’ve identified the core tasks are interactions, really refine those until you’ve got them nailed. If it’s simplicity you’re struggling with, here are a few fantastic books:
“The Laws of Simplicity” John Maeda
“Designing the Obvious” Robert Hoekman
“Simple and Usable” Giles Colborne
Thanks for your time, Dennis!
Do you have any thoughts of your own on complexity creep and how it can be avoided? Do you have any questions for Dennis about simplifying your site’s design? Please share them in the comments below, or contact us if you have any other questions that we can answer for you.
