Decision-Making in UX two-system-concept part 2

Decision-Making in UX: The Two-System-Concept (Part 2)

Decision-Making in UX two-system-concept part 2
Share on facebook
Share on twitter
Share on linkedin
Share on email

In Part 1 of this series, we explored Daniel Kahneman’s two-system decision-making concept at a high level — while also adding a little color to System 1. I encourage you to check out Part 1 for full context. However, we’ll briefly recap as we start to explore methods involving identifying and minimizing System 2.

The two-system concept outlines two decision-making processes that we, as people, go through every day. System 1 happens automatically and without effort — developing through repetition. System 2 is more effortful and slow, taxing our faculties in one way or another. A System 1 process would be one’s ability to steer a car on a highway. It occurs automatically and without effort because through repetition we’ve hard-coded that decision-making process. A System 2 process can be compared to asking someone to do complex math in their head. It’s slow, mentally taxing, and requires effort — unless of course you’re very talented at that sort of thing.

Understanding and applying these concepts to how we design applications for people yields fantastic results. We can more closely identify where intuition plays a part — and where we might be creating pitfalls in the experience. A large portion of pitfalls occur as a part of System 2 — an issue we’ll explore a bit more below.

Understanding and Designing for System 2

As mentioned in Part 1, System 1 is a decision-making process we want to focus on when considering intuition. We want people to recognize an experience automatically so we’re minimizing their cognitive load to make things easy. This begs the question, “How do we get there?”, “How do we evaluate a proposed or existing design and identify its specific level of ease or complexity?”

We’ve found that testing a particular experience for task efficiency helps categorize specific interactions into System 1 or System 2. In this respect, measuring speed lends to identifying how quickly individuals know what to do next when trying to complete a goal. When we’re analyzing this data output, instances of task inefficiency will begin to surface as you see goal completion times increase.

Tools and Methods to Measure Task Efficiency

Your current processes or technical system will likely influence how you measure task efficiency. With that said, the following methods and tools should help you get started:

Goal Structure

If you were to look at a user goal from a birds-eye-view, it can be structured and measured in two different ways:

  1. Full Measurement: This method measures the time it takes the user to complete the goal from beginning to end.
  2. Segmented Measurement: This method breaks the goal up into segments as the user hits different interaction points (i.e. the user selects their country in a form)

The overall goal here is to shrink the time of the full goal measurement. However, we accomplish that by focusing on different segments of the goal and seeing how we can reduce their time individually. Subsequently, we must measure each of those segments as well.

Manual Measurement Method

Quite simply, you can shadow the user and hold out a stopwatch. This is the most difficult method because as interaction segments occur, you may not have enough time to record them. Finding a way to record the user’s session is highly recommended so you can consume their interactions at a comfortable pace.

Tool Analysis Method

There are several tools available that allow you to set goals within your application and identify metrics to measure. Google, Optimizely, and quite a few others. These tools give you the raw data but unfortunately, they don’t provide you with the visual evidence of why something is happening.

We recommend finding a tool that allows you to record sessions so you can analyze the interaction segments. This tells you the “why” and not just the “what”. We’ve used tools such as Inspectlet and HotJar, and they work quite well.

Custom Component Method

If you have the flexibility and opportunity to build a session reporting component as part of your solution, it will be highly beneficial. You could do something as simple as building a backend service to collect event stream data and bake it into your app globally. Having immediate access at a system-level will allow you to re-render sessions in its purest state.

Final Efforts

Once we’ve identified what measurement method we want to use, the goal is quite clear. We want to measure task efficiency on the goal and segment level – then identify tasks with large time-sinks and work to make improvements. In most cases, the instances where task times take longer clues us in to what interactions may be slower and more effortful. Sometimes these System 2 decisions are unavoidable, or even unintentional. However, the general goal is to commit as much of the experience to System 1 as possible.

Improvements, no matter how small, can have a big impact. Every individual interaction you optimize makes things quick, effortless, and overall intuitive. Recognition is key.

Stay Up-To-Date