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.
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:
 | Looking 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.
 | Looking 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
- Estimate UI efficiency with User Interface Action Energy, not time or some empirical observations.
- 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.
- 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.
- Confusion, thinking and dead end routes are the main causes of energy leaks in UI.
Targetprocess v.2 was released in 2006. 10 years is a huge timeframe in SaaS world, so we are going to completely remove Targetprocess v.2 soon.
Most of you already work with v.3 user interface and you'll hardly notice any difference. This post answers some questions that may trouble you. Please, don't hesitate to ask more in comments.
Why do you want to remove v.2?
Basically, it affects our development speed. We have to run all old tests, try to not break old things and fix if they break. Less and less people use v.2, so we think we reached a safe moment to cut it completely.
There are some features I use in v.2, since there are no good replacements in v.3
We are going to match almost all features. At least it will be possible to do almost all the things in v.3 as well, like Split, Merge, etc. This is a prerequisite to remove v.2 for us. You can mention any particular case in comments and we will take it into consideration.
I love v.2 and we have On-Site installation
It means you will not be able to upgrade to newer version from Jan 2016. Most likely nothing changes for you, since we didn't improve v.2 last two years.
I love v.2 and we have On-Demand account
In this case we will move your account to a separate server and will not upgrade this account anymore.
If you have more questions, please feel free to ask them.
