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

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.

Custom Rules

You can highlight cards on the Views using your own rules. It works for all View zoom levels except the smallest level.

Visual Encoding tab looks like this:

To specify rules use the same syntax as for Filters.

If you have several rules applicable to the card, it will be highlighted with the color of the first applicable rule. For example, you have two filters: ?Tags.Contains('Urgent') and ?Iteration is Current.

In this case, cards that contain Tag “Urgent” and are in the current Iterations will be colored with the red color because the Tag rule is set before the Iteration rule.

You can also prioritize rules via drag-n-drop to determine the rules' order of importance.

Examples

You can specify different color saturation to highlight cards by property in order of importance. For example, you can use the following rules for Business Value. The greater the Importance, the more saturated color will be applied.

You can also use color saturation to highlight some intervals of property. For example, for Effort property you can use the following set of rules. And it shows which Feature has User Stories with greater Effort.

Another use case is highlighting by Tags:

You can highlight cards that have too long of a Cycle Time:

People who work a lot, have more than 10 items and have Allocation greater than 100%:

User Stories with a few Bugs and with a lot of Bugs:

You can highlight a specific card by Name or by Id:

Highlight Requests by Email and Phone source types:

And, of course, you can mix all the rules:

It also works at Timelines:

And it works for Lists (only on the cards level, not hierarchy levels yet):

Some theory about Visual Encoding.

(Multicolor support is available since 3.7.0)

We've completed implementation of nice usability improvement that makes workflow setup much easier. It will be released in v.3.4.3 in 1-2 weeks. Let me share this functionality with you.

New process setup is accessible from several places. The most obvious is Settings section:

Left menu replaced by processes list. Here you see all processes that exist in a system. It is nice that you can clearly see whether process is actually used by real projects. If not, you can safely delete the process. For every process you can setup Custom Fields, Terms, Practices and Workflows for all entities.

Central part dedicated to selected entity workflow. In this case you see a workflow for User Story. The good thing is that workflow imitate board columns, so you have great affordance and clearly understand how this workflow will look on a real board.

To add a new state, just put your mouse over some other state and you will see a green button near it. It is very convenient to add new states between existing states in a single click.

To rename a state, just double click on its name. To edit all state details, click on a Settings icon. Here you can very quickly setup all ingoing and outgoing transitions. In previous version when you added a new state, you had to open every other state and add transitions. Now it is right here with a single click.

Re-ordering states is very easy as well, just drag and drop required state.

Check this quick video to grasp all the main ideas of workflow customization:

We believe processes customization becomes much easier with this release and are really excited about usability improvements! As always, your comments are much appreciated!

Targetprocess focuses on visualization. Our ultimate goal is to give you an astonishing visibility into project management. While Targetprocess already provides nice tools like boards, lists and timelines, it lacks some important and obvious functionality: custom graphical reports. Without them it is almost impossible see trends and find patterns in aggregated data. Our first release of Custom Graphical Reports will solve this problem.

The scope of MVF is:

1. Create custom reports from 20-30 most popular templates. We are defining them now. Add these reports into Groups, share them with teams or keep them private.
2. Line, Bar and Scatterplot charts will be supported
3. Aggregated data and Date axis will be supported. For example, it will be possible to see how many bugs were fixed in every project by weeks, or how average Cycle time changes with time for every development team.
4. You will be able to print report or save it as a PDF file.
5. It will be possible to create almost any report using DSL (special language for report creation). We consider this feature as temporary and the goal is to explore various reports while we are working on GUI.

Setup Report from Template

When you create a new report, you will have to provide a source for the report. For example, you want to see something for done User Stories. In this case you select User Story card and specify a filter.

Then you will have a choice from 20+ templates. On the image below there is a chart that shows Cycle Time and Effort, so you can see how effort affects Cycle Time. Size of every circle represents how many bugs each User Story has. So you can see that Cycle Time is very unstable for, let' say, User Stories with 1 pt of Effort and varies from 1 to 30 days.

So many charts

It will be possible to create various charts. Just few more examples:

This chart shows how many User Stories each Feature has. Large Features are clearly visible.

This chart shows how effort and cycle time are different for every development team. It looks like Exploited team has more diverse cycle time that two other teams. All teams don't have large user stories, which is good.

Setup chart from DSL

In the first release it will be possible to setup any chart with a special language. It is not an easy option and we mainly add it to check various reports ourselves, but still there will be a possibility to build some advanced reports:

After MVF

Questions we want to answer after MVF release:

1. How important reports for historical data? Like what stories moved from one iteration to another, what states have more bottlenecks, etc.
2. What interactions people want on reports? Drill down to more details, jump to related boards, etc.
3. How to design a really usable UI for custom reports creation?
4. Did we miss some important report types?