Understanding Complexity, Designing for Simplicity
presentation by Dave Hogue at D2WC
Dave began his presentation by stating that complexity is easy. To make something simple, we need to understand complexity
Complexity is based on the latin word complexus, which means entwined or twisted together. As designers, we know complexity when we see it. He then broke complexity down into three different perspectives: Designers, End-Users, and Scientists. Designers see complexity, and try to control it using appearance, aesthetics, and space. Designers avoid unnecessary noise, and manipulate content hierarchy. We design the flow using patterns and structure to minimize the clutter. Some even use these patterns for nefarious means via dark patterns to trick users into doing things they wouldn’t normally do.
End Users see complexity differently. Designers focus on clutter as adding to complexity, but users are more concerned with relevancy. Dave cited a project documented by UIE. In this project, the team was tasked with redesigning a firm’s intranet home page. They ran through their research steps, interviewing users, and reviewing what users where trying to do. When they where done they had a page that looked substantially more complex and cluttered than the one the firm had before. What surprised them is that when they showed it to the end users, it was almost universally praised. Users loved it, because even though the page had more ‘clutter’, it had relevant content that actually mattered to the end users. The page was full of stuff — mostly things the firm’s marketing group wanted everyone to know — but very little of what was on the page helped the employees do their jobs. Everything they needed was on the intranet, and they knew it, but the home page didn’t lead them to it. [1] End users see complexity from confusion, and difficulty.
Scientists partially define complexity using chaos. Dave used weather prediction and chaos theory to explain his point. He then stated, some things are naturally complex, however these massively complex systems with massive amounts of variables can be explained with remarkably few.
The Complexity Curve or “Feature Complete”
With a stronger understanding of how people view complexity, Dave then carried this over to the project life cycle using a bell curve he dubbed The Complexity Curve. He stated that when projects begin, they are typically simple ideas that generate a lot of excitement. What happens though, is that over development, as the time increases, so does the complexity, to a point. Scope creep, technical limitations, and additional factors all contribute to increased complexity, pushing the complexity higher, until the project peeks at Feature Complete.
Where Does Complexity Come From?
Dave diverged from the curve, and started to explore the source of complexity. He started by reviewing how designers introduce complexity. The first is the mental model mismatch, or when expectations clash with reality. This can be from mismatching and inconsistent patterns within the same location, anti-patterns (when a function isn’t shown until an action takes place), or the previously mentioned dark patterns. Complexity can also be increased from new patterns. Dave gave us one rule at this point, if its going to be new, it must be better. If you insert a new pattern into a users work flow and its equal to what is already available, it increases complexity because it forces users to learn it. Scope creep can also increase complexity. Finally, designers can increase complexity via system model exposure. System model exposure occurs when constraints, technical requirements, and legal considerations leak their way into the interface.
Users also introduce complexity which occurs from difficulty and expertise. Dave made a point to state that we should not conflate complexity with difficulty. Difficult tasks often appear complex only until we have learned the necessary knowledge and skills. Large amounts of mental load can feel difficult to a user. Users counter various levels of difficulty and complexity with expertise. Expertise can be broken into three stages. The first, declarative knowledge is the initial knowledge, and can be compared to a users first exposure. Procedural knowledge, the second form, is learned from multiple uses of the system. The final, automaticity, is habit developed after prolonged exposure and use of a system. Simply put, users in the declarative phase have a hard time while users in the final stage have a relatively easy time. We commonly refer to these categories of users as novices and experts.
Technology can also contribute to complexity. Limitations are the primary cause, and this can come from a lack of materials, manufacturing, and capabilities. Dave contrasted the various forms of mp3 players and memory, or storage space.
Law of Parsimony
Dave began this section by citing the law of parsimony which states, All things being equal, simpler solutions are generally better than complex ones. It was at this point that Dave returned to the complexity curve. The last time we looked at the complexity curve, we where at the peak of complexity when we hit the feature complete part of the development process. The following is my favorite line from his presentation:
Do not stop at feature complete.
To complete the bell curve, we need to iterate clarity, structure, and flow, not just features.
Dave stated that a sufficiently motivated person will tolerate a lot of crap (although here he was specifically referring to complexity, difficulty and confusion). As designers we need to leverage our ignorance. What Dave meant by this is that often we have our best ideas and concepts before we get told why they won’t work. He suggested that we write all of these down before we learn why we can’t, and come back to them. Designers can also use mental models that match end users conceptual models. System models should also be hidden from the user. Users do not need to be burdened with our restraints.
“Make everything as simple as possible, but not simpler”
He then made a point to state that simplicity is not just subtraction. Often complexity moves, it doesn’t go away. Dave cited watching movies as an example, from an old film projector to the latest Roku box. The complexity shifted from the interface to the inside of the box. This is where Dave instructed us to shift the complexity away from the person. The law of conservation of complexity states that every application has an inherent amount of irreducible complexity. Feature complete is NOT experience optimized. Dave stated that designing for simplicity is not about checklists, formulas, patterns, or rules. It is about critical thinking, understanding the problem, and analyzing and optimization.
10 Opportunities to Simplify
When things are messy and confusing due to irrelevance, disorganization, or ambiguity, we have an opportunity to simplify. Indirect Actions are also an opportunity as they increase cognitive load. We can stop trying to design solutions that are everything to everyone, as it creates a solution that lacks focus. Design by consensus can introduce scope creep, and likewise increases complexity. Nice to have features start increasing noise and clutter. Copying solutions can introduce misapplied patterns. Mapping a solutions structure to a business organization or technology exposes the system model. Leading with technology is solving the wrong, or non-existent problem. When we design for ourselves, we ignore the mental models. We also should not accept assumptions rather than collecting data.
This was easily my favorite presentation from the conference, and it was a pleasure to review it here. You can see Dave’s slides from the presentation online here:
http://www.slideshare.net/DaveHogue/the-complexity-curve-how-to-design-for-simplicity-sxsw-march-2012
You can follow him on twitter at twitter.com/DaveHogue.
