the complexity curve: designing for simplicity

Brief

Interfaces and devices are providing more and more power and functionality to people, and in many cases this additional power is accompanied by increasing complexity. Although people have more experience and are more sophisticated, it still takes time to learn new interfaces, information, and interactions. Although we are able to learn and use these often difficult interfaces, we increasingly seek and appreciate simplicity.

Notes

@davidhogue
#sxsimplerux

Complexity is easy; simplicity—not so much.

wristwatch: we only interact with it when we need to change the date or time; herein lies the added complexity.

define complexity: we know it when we see it.

design complexity

visual designers: appearance, aesthetics, style (clean, simple); sufficient negative space, avoid visual noise, typography = concern with hierarchy to extract information from chunks
ux/interaction designers: functionality, contexts, flow; how does it work/how does it need to work (interactivity), “Dark Pattern”; goals (user goals, corp goals); structure (organization, connections) helps us move through the interaction experiences (flow);

user complexity

relevance; clutter (“i can’t find what I need”). users base interpretation of complexity on relevance (clutter gets in the way, but so does irrelevance). confusion leads to people calling things complex;
don’t conflate complexity with difficulty; things are difficult only because we don’t have the knowledge of skills to complete the task with efficiency. “cognitive load”: understanding/memory, problem-solving/decision-making, associations/connections. users deal with this by developing expertise: declarative knowledge (things we repeat to ourselves/instructions), procedural knowledge (translated into motor memory), automaticity (habitualized; “i just know how to do it”)
novices v. experts: once we learn something the instructions are no longer necessary and products that are complex are considered “simple”.

scientific complexity

chaos. (weather was first well-studied aspect of chaos theory). “lorenz attractor” (system that has structure, bounds; but chaos makes it unpredictable: dynamical systems (ever-changing), deterministic (we can describe it), unpredictable (but not random). out of chaos comes self-organizing systems, emergent structures from the properties of the system itself (no outside force), that are sensitive to perturbation (“butterfly effect”: small changes can produce large changes).

“some things are naturally complex; intrinsic in the system”. Complex systems that appear to have an impossibly large number of variables can actually be described and understood (not predicted) with remarkably few variables.

technology has limitations but moves inexorably forward.

Complexity Curve

Beginning of a project, we understand it completely. Then we begin (and quickly realize that it is more complex than we initially thought, we add features, we hit constraints). We get to a “feature complete” state (top of bell curve): a product is maximally complex and feature complete but not really finished.

If you don’t design something, don’t be surprised if you have a crappy product.

models: expectations v. reality

mental models: user (expectations)
conceptual model: designer (interface)
system model: device (actually how it works in reality)

when these three models are coherent and consistent throughout, there is good ux flow.

when there is a mismatch, progress is impeded, focus is interrupted (“why does it work this way?”), direction is incorrect (“mistakes, mislocation”)

patterns: “right pattern for right situation”

“new and different is not always better”: make sure new pattern is a better solution, appropriate to the situation

copying: we might borrow a pattern that doesn’t really solve the problem we are faced with.
anti-patterns: commonly recurring solutions to common problems (familiar) but they are non-optimized; “mouseover” as a recurring pattern may create wasted time “cursor surfing”
dark patterns: malicious intent, leading you to do things you would otherwise not choose to do.

scope creep: rate at which the scope increases

forgotten features
absent stakeholders with feedback late in the process
vendor system requirements
“executive bungee-jump”: executive “checks in” and adds to scope

constraints/requirements

technical
legal
business unit (competing needs)
system model constraints (why can’t I do this? because the system has requirements that may not be exposed to the user)

How do we address complexity?

Not everything should be simple; when there is a possibility for an irreversible mistake, complexity is good
iterate: refine the design for clarity (reduce confusion and ambiguity), structure (better organization), then flow (opportunities for efficiency and accuracy).
take advantage of technological advances; have patience with technology, it might take time to make things happen; the desire for quality and efficiency can influence technological advances
know your users (“a sufficiently motivated person will tolerate a lot of crap”: complexity, difficulty, confusion), teach your users (some things are just complex): transfer knowledge/skills (instruction, demonstration, analogy “i know how to do A, so i’ll try that on B”)
use design: leverage your ignorance (back at the beginning, before you know how complex things are, you have ideas that eventually get shackled so write them down before you know that you can’t do them; when constraints arrive, go back to the original ideas and ask “how else can i do this?”; put people first (design for motivation, design for behavior, design for emotion, design with creativity “we like to make”).
use models and make sure they match (mental + conceptual), hide system models; acknowledge that people’s mental models and designer’s conceptual models both evolve over time
focus attention, flow (keep on task); reduce* effort, time, errors. simplicity is not just about reduction (“make everything as simple as possible, but not simpler.”). complexity moves/shifts. e.g.: so shift complexity away from the user to the interface developer (luke w.’s dynamic credit card form that grows as I enter data): “we should be doing the work”. we don’t ever really get rid of complexity, we just shift or hide it (“law of conservation of complexity”?)
iterate: continue to work on your product; incubate the idea (take a break, do something else, come back with fresh perspective); cross-pollinate your ideas from unlikely sources; observe what people use (desire paths)
think critically: persistent effort to examine any belief, idea, or fact in terms of the available evidence. recognize when we make assumptions, assess relationships/connections among things, and consider consequences of design options looking for optimal solutions.

Designing for simplicity is not about checklists or rules, but it’s about thinking and reasoning.

Opportunities for Simplicity: make your design better by reducing complexity

If you hear “messy” and “confusing”: there is irrelevance, disorganization, ambiguity.
If you use indirect action (do something here to make something happen over there), you have abstracted/disconnected action from outcome.
If you are trying to be everything to everyone in a single product, too many variables, too little focus
If you are designing by consensus, you will have scope creep.
If you hear “it would be nice to have”, this often introduces noise, clutter, and excess.
If you are copying patterns, you may have misapplied the design pattern.
If structure is mapped to the organization or the technology, you’ve exposed the system model.
If you are leading with the technology (e.g., mobile), you may be solving the wrong or non-existent problem OR taking advantage of an opportunity: “a solution that’s looking for a problem or a tremendous opportunity?”
if you are designing for yourself… (missed this one)
if you are accepting assumptions, you aren’t collecting data to evaluate what your options are and you have an absence of critical thinking