Designing Experience Design

A tangential take on experience design principles

13 min readNov 25, 2013

(…) our unbelievably complicated civilizations will be able to prosper only if we design them in such a way that they do not clash with or tend to suppress our basic animal demands.
Why have we become like gods as technologists and like devils in moral beings, supermen in science and idiots in aesthetics — idiots above all in the Greek sense of absolutely isolated individuals, incapable of communicating among themselves or understand one another?
By designing without any stylistic or formal preconceived notions, and tending towards the natural formation of things, one gets the essence of a product.
In theory there is no difference between theory and practice. In practice there is.

I design experiences, and this is the way I design.

Concepts: Limit, Reuse, Recycle

Concepts are cheap to spend, expensive to cash.

Too often new products base all their being ‘new’ just on introducing a new concept.

Too often renewed product are all based on featuring a new concept.
Sometimes, even within the same product, every (new) feature is based on a (new) concept.

As designers, it’s easy to throw in new concepts; it is actually the easiest shortcut to design a solution: one’s struggle in applying design rules to a specific context/challenge, or more simply one’s not knowing the rules, and implementing a new, made up on the spot, concept just seems the quick win. Very bad designers use this approach constantly, extremely bad interaction designers actually make their trademark out of it. They sell it as creativity.

Users, on the other hand, rely on familiarity (with the concept) when interacting with a particular product’s feature. Familiarity is derived by a repeated, constant, close exposure; if you introduce a new concept, by definition, it won’t be something the user is familiar with.

New concept = extra cognitive effort.

A new concept has to be deciphered (de-coded), to be understood; and then its interaction in a particular context has to be deciphered, and the way it works with other concepts has to be understood too. Only once it’s been grasped, a concept can be put into use.

But even once understood, a newly introduced concept won’t gain a familiarity status in one go; depending on various factors (complexity, frequency of use, etc.), it will take several encounters before that concept becomes familiar. Multiply the above process, and cognitive effort, for every single new concept you are thinking to introduce. And, the more complex the feature/task, and the less familiar with that feature the user is, the deeper the understanding of the concept has to be.

Careful with that concept, Eugene.

Unless I have a controlled group of users I’m designing for (e.g. a business application used by a small team, sharing common objectives with a clearly defined process broken up into a set of tasks) and whose I have access to, I can‘t say how familiar a concept can be, or how uniformly spread that familiarity is.

Lots of factors may contribute in making a particular concept more or less (or not all) familiar: cultural (language, nationality, etc), demographic (age, sex, social status, etc.), and so on.
For that reason, limiting the number of concepts used it’s a good idea: it simplifies the interpretation load, reducing the risk that something is not understood, or requires too much effort in understanding it.

I personally try to limit as much as possible the number of concepts, I ask myself do I need a new concept to illustrate this feature? Can I re-use a concept I already introduced? Can I recycle some concept that’s been used somewhere else (i.e. another product)?

Schemata are your friends.

A less than perfect implementation of a well established, familiar, concept, may prove a better design solution than introducing a completely new concept.

People use a schema, that is a mental structure, a framework of previously experienced concepts, to recognise and successfully read (and interact with) new information. Users will find it easier to use a feature designed on top of a concept that fits into a schema of theirs.
The stronger the resemblance of a particular concept with a user’s schema, the more the user will act on ‘autopilot’, therefore the less the need for the design (this time intended as the graphic layer) to stress the mechanics of the concept.

“People aren’t looking for the interface to be exciting. They’re looking to it to be fast, reliable, and easy to use.” — Craigslist.org CEO, Jim Buckmaster [ http://goo.gl/otUWPW ]

Know the basics

Design is discipline. If you want to break something, you can always be an artist.

Gestalt Theory of Visual Perception

The gestalt theory suggest that we naturally tend towards organising (apparently?) chaotic information into structures. The main point of the theory is built around the concept of grouping: we tend to find patterns and relations between elements/components/objects.

Closure
The tendency to perceive complete figures (particularly shapes), even when part of the image is missing.

Continuity
The tendency to perpetuate a series of previously introduced elements.

Proximity
The relationship of elements based on their physical proximity (close elements are seen as a unit).

Similarity
The relationship of elements based on their physical similarity (especially in shape).

Prägnanz
The tendency to reduce complex information into simple forms.

Common fate
Elements moving in the same direction are perceived as a unit.

Area
The smaller of two overlapping figures is perceived as foreground, the larger as background.

Symmetry
The tendency to see the whole of a figure as opposed to its composing parts.

Pareto Principle (80/20 rule)

In large systems, most of the effects are generated by a low percentage of variables.

Affordances

The verb to afford is found in the dictionary, but the noun affordance is not. I have made it up. I mean by it something that refers both the environment and the animal in a way that no existing term does. It implies the complimentarity of the animal and the environment.
You do not have to classify and label things in order to perceive what they afford.
To quote from the Principles of Gestalt Psychology (Koffka, 1935), “Each thing says what it is… a fruit says ‘Eat me’; water says ‘Drink me’ (…)”

Two laws, two patterns, a diagram, and a razor

You should think of these as interaction design common sense.

Fitts’ law

(…) the information capacity of the human motor system in controlling the amplitude of movement having a particular average amplitude plus or minus a specified tolerance (variable error) is proportional to the logarithm of the ratio of the tolerance to the possible amplitude range is arbitrary and has been set at twice the average amplitude.

Practical oversimplification: The more common the task, the bigger the interaction element required to identify that particular task.

Hick’s law

Reaction time is an increasing linear function of transmitted information for equally likely alternatives.

Practical oversimplification: The more (information) choices are given, the longer it will take to access the (‘right’) information.

Gutenberg diagram

The Gutenberg diagram is used to describe the most common reading pattern as found among Western culture readers.

The starting point usually corresponds to the so called primary optical area, on the top left corner of a page, moving then to the right (top right corner) end of the page, called the strong fallow area.

While the eyes movement is supposed to follow a Z pattern (see below) the bottom left corner of the page is mostly transitionary, with the reader’s attention aimed almost entirely to the terminal area.

FACEBOOK HOME
(anonymous user view)
Gutenberg diagram
analysis
Graphics: @Kurrn

While the Gutenberg diagram is commonly used to describe reading patterns in text-heavy pages (or screens), the origin of the diagram is attributed to Edmund Arnold and originates from the newspapers design discipline, the approach it’s flexible enough to fit various scenarios.

FACEBOOK HOME
(anonymous user view)
Reading gravity
Graphics: @Kurre

Z pattern

F pattern

Eyetracking visualizations show that users often read Web pages in an F-shaped pattern: two horizontal stripes followed by a vertical stripe.

The F pattern described by Nielsen is mostly associated with end pages (articles, SERPs, lists) — that is those pages that usually resides at the end of a user’s journey, and are the result of an explicit — navigational or search triggered — user query.

Possibly the only point out of the F-pattern analysis that can be used with little or no further analysis, is that the far right column of a screen is the most likely area to go unnoticed by users scanning a web page.

Ockham’s razor

One should not increase, beyond what is necessary, the number of entities required to explain anything.

Design solutions should be simple; complex challenges are not solved with complicated systems.

Colour

Start designing in monochrome, the interface should be readable even if only tones of grey are used.

Add colour once the base is solid, add them conservatively. Colour is information and more colour means more information to process.

Colour can be used as a code language, don’t break conventions (red = loss / green = gain); also, once a language is established, it should be used consistently.

Use desaturated colours in UIs, they require less focusing effort from the user; use saturated colours to highlight, or pop out important (exceptional) information.

When using colours for data-visualisation or geospatial information, I take extreme care and look for reference and tools to make my life simpler (see note).

When designing products for a global audience, I pay attention to cultural differences, ideally localise colour as part of the localisation effort.

Careful when using language to refer to colour elements of the UI (eg. “click on the blue button”).

Typography

This is a mine field, as most of the non chrome (and part of the chrome) information of a digital product (except obviously for video/image heavy products) is composed of text.

My typography choices are defined by:

Legibility
Text should be as easy to read as possible.
Content/User type
The typeface should fit the context of both the content and the (main) intended user type — or of as many user types as possible.
Physical context
The text should be accessible within the physical limitations of where/when it’s mainly consumed (eg: outdoor/indoor; daylight/artificial light; etc.)
Distribution channel
The typeface should easily adapt to the peculiarities of the distribution channel used, or to adapt to the multiple channels it may be distributed to (eg: mobile, TV, public displays, etc.)

The topic is vast, you can find an excellent starting point here:
Butterick’s practical typography — http://practicaltypography.com/

Keep the flow alive (don’t interrupt)

I tend to design for uninterrupted use, that is I plan the design not to be on the way of the user. To achieve this I try as much as possible to stick to the following:

Ask question only when essential
Define what’s essential prior to start designing — eg. business requirements.
Feedback lightly
Feedback doesn’t mean interrupting the task.
Provide an easy way back
It should be easy to understand how to go back (this implies that it should be clear where you are).
Describe the journey ahead
Stages of a multi steps task/process should be revealed before the start.
Make recovery possible
Contemplate the possibility of a mistake.
Support (seamless) cross-channels journeys
Users should be allowed to complete their tasks, or journeys, on a channel different from the one they started with (eg. start on desktop, end on mobile).
Support (seamless) time delayed journeys
Users should be allowed to complete their tasks, or journeys, at different times (without the need to restart from scratch).
Account for real life touch points
Your users are likely to be real people, your product should be ready to deal with real life (eg. collect an order, contact support, etc.) and sync accordingly.
Provide sharing features
Users should be able to share the result of their tasks, or their journeys with themselves (eg. save, export, bookmark, etc.) or with others (eg. social network, email, print, etc.)
Remember the user
Users should not find themselves reminding the system who they are, and what they want, every time they re-engage with it.

Take the lead

As a designer my responsibility is to make most of the decisions for the user (including deciding when is the user’s turn to make a decision).

Delight is rare

Usable doesn’t mean boring; engagement is an essential component of designing a product for human consumption.

Not all things are created to delight, or surprise. If everything is a surprise, nothing’s surprising.

Think of fireworks, if you have fireworks every single day, they become an annoyance, as opposed to a moment of celebration.

Consistency is clarity is frugality

Clarity is easier obtained through consistency; the less stuff you throw in ,the less worried you have to be about maintaining consistency.

Golden rule: if it doesn’t add value, don’t add it.

Storytelling & Narration

I use storytelling to understand the user, to communicate with my team, to pitch my design.

I design narratives to facilitate users’s engagement with the product.

I believe in the visibility of the interface

Sometimes the interface is the information, sometimes the interface contextualise the information, most of the times the interface supports the information.

Almost all the times, the absence of an interface is a symptom of bad design.

Promote depth, progressively

I try to expose what’s necessary, while providing easy access to what might be useful.The possibility of scratching deeper than the surface should be evident, without being obtrusive.

Responsiveness is not about screen fit

I design responsive experiences, they adapt to the context, the platform, the user. Sometimes, it means you have to design different products based on the user, the platform, or the context.

Then you have the other responsive design, you just need some media queries for that.

You should know how to name things

There are only two hard things in Computer Science: cache invalidation and naming things

The main rule I follow here is: name things as your users call them, not as your client (business, stakeholder, boss, etc.) wants them to be named. And it’s not easy.

There’s life offline (people don’t live in labs)

Most people don’t live in labs, I try to understand the way they work, or more generally interact with a product, through field research.

Field research means that you have to look at your (existing, potential, or target) user in their living grounds, or the place where they work, and in all possible places in between (eg. commute).

Ideally, you should integrate the observation part with an impersonation exercise: try to do their job (or some of their job’s tasks), wake up with them (that is at the same time, not in the same bed). Live their life.

If all your knowledge of your users is based on lab testing, user groups, eye tracking (let me guess, is a F pattern?), or analytics (A/B testing bonanza, everybody), what you know of your users is of little value (and probably mostly wrong).

Modularise everything

Attention is limited, distractions are everywhere, context is unknown, (future) features are uncertain.

Design from the most atomic element up, then combine those atomic elements into blocks, blocks into modules.

Blocks should be independent, modules should be able to interact.

Micro-interactions are the only interactions you can physically design. Deal with it.

The above is my personal elaboration of the following fundamentals, as well as the result of my own professional experience.

Fundamentals

Tim Brown’s Design Thinking

Design thinking can be described as a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.

How to make Design Thinking part of the innovation drill
1. Involve design thinkers at the very start of the innovation process
2. Take a human-centered approach
3. Try early and often
4. Seek outside help
5. Blend big and small projects
6. Budget to the pace of innovation
7. Find talent any way you can
8. Design for the cycle

Dieter Rams’ 10 Principles of Good Design

1. Good design is innovative
2. Good design makes a product useful
3. Good design is aesthetic
4. Good design makes a product understandable
5. Good design is unobtrusive
6. Good design is honest
7. Good design is long-lasting
8. Good design is thorough down to the last detail
9. Good design is environmentally-friendly
10. Good design is as little design as possible

Ben Shneiderman’s Eight Golden Rules of Interface Design

1. Strive for consistency.
2. Enable frequent users to use shortcuts.
3. Offer informative feedback.
4. Design dialog to yield closure.
5. Offer simple error handling.
6. Permit easy reversal of actions.
7. Support internal locus of control.
8. Reduce short-term memory load.

Donald Norman’s Interaction Framework

Execution
1. Goal
2. Intention
3. Sequencing
4. Execute Action

Evaluation
5. Perceive
6. Interpret
7. Evaluate

Donald Norman’s Principles of Good Design

1. State and action alternatives should be visible
2. Conceptual model with a consistent system image
3. Interface should include good mappings that reveal the relationship between stages.
4. User should receive continuous feedback.

Donald Norman’s Principles of Design

1. Use both knowledge in the world and knowledge in the head.
2. Simplify the structure of tasks.
3. Make things visible: bridge the gulfs of Execution and Evaluation.
4. Get the mappings right
5. Exploit the power of constraints, both natural and artificial.
6. Design for error.
7. When all else fails, standardise.

Jakob Nielsen’s Usability Heuristics for UI design

1.Visibility of system status.
2. Match between system and the real world.
3. User control and freedom.
4. Consistency and standards.
5. Error prevention.
6. Recognition rather than recall.
7. Flexibility and efficiency of use.
8. Aesthetic and minimalist design.
9. Help users recognise, diagnose, and recover from errors.
10. Help and documentation.

Bruce ‘Tog’ Tognazzini’s First Principles of Interaction Design

1. Anticipation
2. Autonomy
3. Colour Blindness
4. Consistency
5. Defaults
6. Efficiency of the Users
7. Explorable Interfaces
8. Fitts’ law
9. Human Interface Objects
10. Latency Reduction
11. Learnability
12. Use of Metaphors
13. Protect Users’ Work
14. Readability
15. Track State
16. Visible Navigation
______________________________________________________________

Thank you.