Fluency, cognitive choreography and designing better workflows
If you’ve read part 1, you’ll know all about what Fluency is and how understanding it subtly, but importantly, changes the way you think about usability. Now I’d like to take this one step further by introducing a couple of other concepts from Kahneman’s book on the fascinating world of modern cognitive psychology, as well as one that i’ve made up all on my own: ‘Cognitive Choreography’.
Let’s start by briefly explaining what I mean by the term cognitive choreography. The workflows that we are called to design can place varied and diverse demands on our darling users. It’s often about going through the motions; form fillin’ payment details, skimming content, navigating. But people are often also being asked to make critical decisions and perform complex tasks. These different types of engagements require very different types of cognition (as we’ll see later). And in this article I’ll go through some relatively new research that points towards ways in which designers can encourage the right type of cognition for the right moment; what i’ve called Cognitive Choreography.
Kahneman’s book centres on what he calls the ‘two systems’; two modes of thinking, one fast, System 1, and the other slow, System 2. These have very different capabilities and constraints, and as a result some important implications for design.
System 2 is what does the conscious reasoning; it is the deliberate, rational voice in your head that you like to think is in control. System 1 is the automatic, largely unconscious, part of your mind where most of the work actually get’s done. Although the reality is inevitably rather more complicated, it’s helpful to adopt Kahneman’s conceit of these systems as two distinct characters.
System 1: The associative machine
- Automatic and involuntary
- Can do countless things in parallel
- Slow learning
- Generates our intuitions
- Driven by the associations of our memories and emotions
- Uses heuristics (rules of thumb), that are often right, but sometimes very wrong
System 2: The lazy controller
- Selective (lazy) and limited in capacity
- Does things in serial
- Uses reason, logic and rationalisation
System 1 effortlessly generates impressions and feelings (“xyz link looks most relevant”) that are the main sources of explicit beliefs and deliberate choices of System 2 (“I’ll click on xyz link”). The problem here is that System 1 is error prone and System 2 is lazy. System 2 can overcome System 1’s shortcomings, by critically examining the intuitions System 1 generates, but will often not. I think that as designers we should think about how we can help System 2 spring into action when the moment is right.
Before looking at how we can help the right system spring into action, let’s look at how System 1 can sometimes lead users astray.
System 1 has evolved to be quick and get things mostly right, most of the time, for your average hunter gatherer in the long gone Pleistocene (i.e. before we got all civilized, started farming and building urban jungles). As a result it doesn’t adhere to the tenets of logical and statistical reasoning that underpin what we think of as ‘rational’ thought; it uses heuristics, rough rules of thumb, that are easily computed and generally work. And that leads to errors, which, in our new fangled not-too-much-hunting-or-gathering-needs-doing kind of world, are more problematic than they used to be.
Here is a brief listing of some of the things that can go wrong. If you want to really learn the slightly scary truth about how rubbish we (and yes that includes you) are at making judgements and choices then I refer you toKahneman’s book or perhaps take a look at this scary wikipedia list of cognitive biases.
System 1 is biased to believe and confirm what it has previously seen, or is initially presented (luckily for the advertising industry). So it tends to be
- Overconfident in beliefs based on small amounts of evidence (“The site would be better if it was purple. My wife said so.”).
- Very vulnerable to framing effects (“90% fat free” vs “10% fat)
- Doesn’t factor in base-rates (i.e. a things general prevalence). Insurance sales and the tabloid press play off of this all the time; it is the gravity of the event that matters, the fact that it’s very very unlikely, doesn’t have nearly as much impact as it should. So for example, you may be tempted to insure your brand new fridge, against breakdown in it’s first year, because you’re so dependent having it work, even though it’s extremely unlikely that anything will go wrong.
This is because System 1:
- Focuses on the evidence presented and ignores what isn’t
- Neglects ambiguity and suppresses doubt
- Exaggerates the emotional consistency of what’s new with what’s already known
System 1 infers and invents causes, even when something was just down to chance. So, for example, in The Black Swan Nassim Taleb relates that when bond prices initially rose the day Saddam Hussein was captured, Bloomberg ran with “Treasuries rise: Hussein capture may not curb terrorism”. Then, half an hour later the prices fell, and the headline changed: “Treasuries fall: Hussein capture boosts allure of risky assets”. The same event can’t explain bond prices going both up and down; but because it was the major event of the day, System 1 automatically creates a causal narrative; satisfying our need for coherence.
System 1 will dodge a difficult question and instead substitutes in the answer for an easier one. So for example in predicting the future performance of a firm, one instinctively relies on its past performance. When assessing the strength of a candidate, one instinctively relies on whether we liked them or not.
System 1 does badly with sums, because it only deals with typical exemplars, or averages. So for example, when researchers asked how much people would be willing to pay to save either 2,000, 20,000 or 200,000 birds after an oil disaster, people suggested very similar sums of money. It wasn’t the number of birds that was driving them, but the exemplar was; the image of a bird soaked in oil. Similarly with visual displays people can very easily tell you the average length of a bunch of visual elements, but not the sum of their lengths.
Let’s not forget though, that while it has its failings, System 1, does a pretty impressive job of things most of the time, for most people. In fact System 1 is crucial to the kind of deep creativity that us designers pride ourselves on. It’s what helps you get things done fast, and well. It’s what results from practice and is the basis of most forms of expertise; you wouldn’t want to drive your car without it!
As a result, lot of the time it’s appropriate, and indeed better, for System 2 to put it’s lazy feet up and give System 1 the reins.
So what’s the overall takeaway for designers? Well, one is that, if users are at a point where it’s important that they critically inspect the facts, and overcome their pre-conceptions and first impressions; then System 2 needs to be on the job. Otherwise, we can leave System 1 in the driving seat.
So how can designers engage in Cognitive Choreography, and help ensure users have the right System in the driving seat, at the right time? Well one approach is to use Fluidity.
I would guess that there are many things designers can do to knowingly encourage users to engage the right cognitive faculties for the task at hand; but one interesting and counterintuitive approach is to use Fluency. That’s what I’m going to focus on here.
To recap from my previous post on the subject, Fluency is the brain’s intuitive sense of how hard your poor brain is being asked to work on something. Lots of things will impact your sense of fluency as illustrated in the graphic below.
As well as being the key to really understanding what is going on behind users perceptions of usability and beauty, it just so happens that we can use the Fluency of our designs to engage system 2. From an evolutionary perspective, the reason we have this intuitive sense of Fluency, is to have an alarm bell that will wake System 2 up when things aren’t going smoothly and we need more careful, bespoke, thought. When an experience is Disfluent and creates what Kahneman calls “Cognitive Strain”, System 2 is mobilised. Thus we, as designers, can actively engage, and disengage, System 2, by controlling the many levers we have at our disposal to change the Fluency of a UI.
So, in case you’re not convinced, here’s one of the experiments that demonstrate this sort of effect in action. A bunch of Princeton students were given a set of 3 short brain twisting problems to solve. These problems were designed to have an answer that would seem obvious to System 1, but was infact wrong. To get the right answer, you’d need to have gotten System 2 in the game. Here’s an example:
If it takes 5 machines, 5 minutes to make 5 widgets, how long would it take 100 machines to make 100 widgets?
100 minutes OR 5 minutes
When students were shown the problems presented in an ordinary, legible, font, 90% of them got at least one problem wrong. When the problems were presented using a small, poorly contrasted font, only 35% of them did. Yep, that’s right, making the font less legible, resulted in an almost 200% uplift in performance. (btw, the answer was ‘5’)
Low Fluency creates cognitive strain, which encourages the user to activate System 2, which thinks things through, and get’s to the right answer. High fluency does the opposite, encouraging the user to leave System 1 in control.
So the design implication here is, that when you come to designing a portion of your flow where it’s critical that System 2 be fully engaged, it may be the time to purposely create a low fluency experience, using the array of tools at your disposal (e.g. font legibility, contrast, layout, motion, copy etc).
So we have a bunch of ways we can make an experience more, or less, Fluent, now we need to understand when to use this to encourage users to apply the right kind of cognition to the task at hand.
Perhaps the first, and most important, thing to say is that you will need to be sparing and purposeful with low Fluency UIs. Low Fluency is by it’s nature unpleasant, and on top of that using System 2 takes effort, so, it’s no fun.
However the science of System 1’s failings give us some clear pointers as to where we should consider putting the brakes on Fluency.
You should consider engaging System 2, with a low Fluency UI when:
- Critical, high risk, decisions are being made
- The user is being engaged in a task that you know has features which will lead System 1 astray. So the user will be asked to:
- Draw inferences based on very small sample sizes
- Draw inferences based on incomplete information; e.g. they are given a small part of the story, or no information about base rates (i.e. general prevalence of a thing)
- Make decisions based on potentially framed and biased messages from an interested party
- Mentally work with sums, rather than averages or prototypes
Most of the time you will want to maximise Fluency and thus usability, encouraging users to coast along primarily using rapid, intuitive outputs of tireless System 1. But your can reduce critical errors, and increase the quality of significant decisions and judgements if you selectively lower the Fluency of your UI, to make sure the lazy, but smart System 2 is fully engaged.
Of course, there is a balance to be struck here, as designers we will be hard pressed to make the experience as disfluent as psychologists can when doing experiments. In fact it would be super valuable if people in the HCI community would take a closer look at this, and measure the effectiveness of lowering Fluency to within the bounds of commercial acceptability.
Another interesting tension here, is that many of us designers, are working on systems primarily aimed at realising and increasing sales. So even if users are making critical, and expensive, decisions, based on incomplete information, it’s in your client’s interest that System 2 stays as lazy and disengaged, as possible. However, there are countless digital experiences that support productive and often critical processes or decision making. That’s what we focus on here at RMA, and that’s where doing a little Cognitive Choreography could come in handy.