We document specifications to describe how individual interactions on a page work. Above that, we document components (some folks call them molecules), so that reusable elements across sites are described and developed consistently. Above that, we have wireframes of pages or sets of pages, showing the combination of interactions and molecules and content. We document entire subsites or sites with these.
And above that? What’s more abstract and at the same time more critical to get right than the wireframes?
I’ve heard them called both “design heuristics” and “design principles” – the principles and trade-offs that we, as a designer, or a group of designers, or an organization, make to accomplish goals. They both define the values of a specific project, and at a higher level define our values as designers. I prefer the term principles.
The set of design principles I use for most of my work are based around the following topics:
- Learnability – make sure that my users can learn how to use the system.
- Efficiency – make sure the user can move through the system as efficiently as possible.
- Managed Complexity – make complex situations clearer, or at least manageable.
- Autonomy – ensure that I’m allowing the user to move freely, control their progress, and not get stopped by process decisions.
- Messaging – ensure that the system communicates everything from error messages to informational situations
- Accessibility – ensure that the widest possible audience can use what I’ve built.
- Semantic Structure – make it written as close the semantic HTML as it can be, it uses progressive enhancement, it follows good coding practices like DRY, etc.
Of all the things I document, these are the most important.
I document them even when I’m not asked to.
It’s not enough to know that I wireframed the purchase process for, say, purchasing stock. I can make wireframes for the purchase process. I can even make personas and scenarios. But if I don’t document that this design is intended to be used by new investors (and therefore needs to be highly learnable) or that this is intended to be used by internal employees who trade stocks all day (and therefore do not need nearly as much instruction but desperately need the system to be efficient for data entry), I haven’t captured the core of the interaction.
When I was a young pup in UX, my mentors required me to document the principles I was using to justify the design decisions I was making. It forced me to communicate the trade-offs I was making, and made them much easier to discuss with my peers. “Is it appropriate to trade off learnability for efficiency in this situation?” we would ask. “This design manages complexity well, but forces the user to follow a specific path. What if we did [suggestion here] to return to them some of their autonomy?”
Times have changed, and I find myself in fewer conversations with my peers about our work. When we are talking, we’re often — like everyone else — easily caught up in the components and layout and behavior of a page. We’re not talking about the principles behind the decisions as much anymore.
When I’m outside the office, and I talk about principles and heuristics, I find many organizations don’t have any documented at all.
I’m worried. I fret that between the push for Agile development and Lean UX and other built-it-faster techniques we’ve neglected to teach and communicate the basics. I fear we too-often count on folks new to our field to implicitly learn the “rules” without explicitly explaining things like Fitt’s Law.
So between rants and raves on other topics, I’m going to dedicate some of my time on The Interconnected talking about the principles and decisions that shape my work, and examples of the same.
If you have questions or topics you want to see me cover, ping me at @kirabug on Twitter. Or if you have great examples you want to share, come write for us.