Show all posts
2 years ago

Minimal Action Energy Principle in User Interface Design

In physics, there is an interesting fundamental principle: a system moves from one state to another using the minimal path, i.e. the path that demands the least energy.

Three_paths_from_A_to_B

When I read this, I immediately think about user interface design. Can we apply this principle to UI? It seems yes, since it is quite fundamental. I have never heard of attempts to use energy to evaluate the efficiency of UI. This is the first try.

Let's say we have several interfaces that can transfer a user from state A to state B. Which one is the best? The Minimal Action Energy Principle in User Interface states:

From all available interfaces that transfer a user from state A to state B we should select the one with the minimum action energy.

So what is energy? That is a very tricky question, even in physics. Luckily, humans are more simple, so we can define all the processes where we lose energy: clicking, taping, scrolling, looking/thinking, moving the mouse cursor, waiting, typing, asking for help, screaming, etc. A more complex thing is to unify these actions and have the same units for them to come up with a single energy number. After that, we can compare the energy of user interfaces and find the one with the least amount of energy required to complete some action.

We can start with a simple model that will be good enough for the tests. We should introduce a unit to measure User Interface Action Energy. It can be yellow frogs, but let's call it Action Units (au). All actions can be expressed via this unit:

1 click / tap = 1 au
1 scroll movement / wheel rotation = 2 au
1 second of thinking / looking = 3 au (thinking is hard)
1 second of cursor movement = 1 au
1 second of waiting = 0.5 au
1 second of typing = 2 au
1 second of asking for help = we fucked up

If I missed some interaction patterns let me know. Now we have a model to measure User Interface Action Energy. Note that energy is not equal to time. This means the user can actually spend more time with a system, but apply less energy to complete the tasks.

Let's calculate User Interface Action Energy for a simple login action:

login_energyLooking at the form: 1
Click the email input field: 1
Recall your email: 1
Type the email: 3
Press Tab: 0.5
Recall the password: 2
Type the password: 3
Press Tab: 0.5
Realize it doesn't highlight the login button: 6
Click the login button: 1
Wait 20 seconds to log in: 10
Total: 29 au

This decomposition makes it clear where we have energy leaks! Let't fix it to spend less energy:

Looking at the form: 1
Click the email input field: 1 (This field should have the focus by default).
Recall your email: 1
Type the email: 3 (autocompletion can save some au)
Press Tab: 0.5
Recall the password: 2
Type the password: 3
Press Tab: 0.5
Realize it doesn't highlight the login button: 6 (Tab navigation should work and highlight the button. Note that confusion causes a significant increase in the energy required to complete the scenario).
Push Enter to log in: 0.5
Wait 20 seconds to actually log in: 10 (Warm-up the application to reduce this time to 6 seconds that equals to 3 au)
Total: 13.5 au

This design is two times more efficient since it takes two times less energy to complete the task. Can we do even better? Yes: implement the Login scenario using the Facebook auto-fill button. This solution eliminates thinking completely.

1_login_500px_miniLooking at the form: 1
Click the Facebook button: 1
Wait: 3
Total 5 au

The absolute nirvana of UI is zero energy. You do nothing and authenticate. Is it possible? Yes, but it will compromise security. Is it possible to do that securely? For example, you navigate to an application, the device takes your picture, recognizes your live face (the photo should not work) and logs you in. You do nothing, but still wait for a few seconds most likely. So total the Action Energy will be around 2 au.

Time != Energy

Usability testing is not new and counting clicks is not new. Usually, we just measure the time to complete a task, observe bottlenecks, and try to fix them. However, time should not be the ultimate measure of a user interface. Most likely, thinking is the most energy-heavy activity, so the best thing a designer can do is to remove thinking from the user interface as much as possible. Steve Krug was right. Some extra clicks might be OK if they reduce thinking about UI.

Moreover, a usability test doesn't give you a breakthrough. You can find some leaks, confusions, etc., but to radically improve a solution you should think hard. When testing a basic login form you will not find a solution with the Facebook button. This solution evolves from other activities, like brainstorming, taking a shower, walking, etc.

The designer's job is to think. The user's job is to use the tool with ease.

Ideally, the designer should create several solutions, select the ones with a lower action energy and test them with real users to find the solution with the minimum action energy.

Automation

I think we can automate action energy measurements. These days, we have quite advanced equipment to measure the eye movement, the heart rate, clicks, cursor movements, etc. In theory, it is possible to create a software that will calculate User Interface Action Energy for every scenario automatically during live usability tests.

For remote usability tests where we have limited access to a real person's data, we can measure action energy with a good approximation. Still it will be a more objective metric than just empirical observation.

TL; DR

  1. Estimate UI efficiency with User Interface Action Energy, not time or some empirical observations.
  2. Action energy includes all processes where the user looses energy like clicking, taping, scrolling, looking/thinking, moving the mouse cursor, waiting, typing, asking for help, screaming, etc.
  3. Create several solutions and test the most promising ones to calculate Action Energy. Find the solution with the minimal UIAE and it will be the most efficient one.
  4. Confusion, thinking and dead end routes are the main causes of energy leaks in UI.
  • mikemsq

    Great post. A few points:
    1. I think the weight of
    the cognitive effort in the user interaction with the software (the
    “thinking/looking” part) is a tricky thing. On one hand it’s probably
    the costliest element for the user (we tend to minimize our thinking).
    On the other hand, as we learn the software our cognitive effort
    decreases. “Adaptive UI” (https://en.wikipedia.org/wiki/… is an interesting concept in this respect.

    2.
    Can you automatically estimate the complexity of a screen/feature by
    looking at the complexity/length of your test suite for the given
    screen/feature? The premise is the more UI elements the screen has the
    more tests it requires. The number of test in a suite (or maybe even
    the number of lines of code) can give you a quantitative value for the
    screen complexity.

  • Victor Homyakov

    Get rid of login/email field as Jef Raskin proposed (read e.g. http://blog.codinghorror.com/w… and totals will decrease even more:
    Look at form: 1
    Recall password: 2
    Type password: 3
    Push enter to login: 0.5
    Total: 6.5 au

Get started for free

How many people would be using Targetprocess?
  • Myself
  • 2–20
  • 21–100
  • 101–1000
  • 1000+
By clicking Continue you agree to our Terms of service and Privacy policy