How to measure the interface. Quantitative criterion

I periodically have a natural desire to find out which software is more convenient, or to prove the advantage of a product with the help of some adequate, numerical arguments (and not as usual).

Having become seriously interested in this topic, I searched for solutions for a long time, and even a year ago I wrote and defended my thesis “Determining a quantitative assessment of the quality of human-computer interaction”. I’ll talk about it in the article.

There are several ways to determine the usability of an interface.

Working methods

User surveys

There are many internationally approved questionnaires (SUMI, SUS, SEQ, etc.), which are lists from 1 to infinity with questions like “Did you find this system complicated for yourself”. In the text of the thesis you can see an overview of several of the most popular systems.

Live user experiments

You can conduct a series of experiments with some numerical parameters (for example, the speed of the task, the number of errors or the average level of task completion).

Expert

You can invite some authoritative uncle and hope that in his 5/10/20 years of experience he learned something like that.

But these methods require hiring an expensive usability specialist (or even several), and catching users on the street.
Therefore, many developers, terrified of the prospect of interacting with end users, came up with ways to formally evaluate the complexity of the system.

Techniques that do not require the participation of a specialist or users

* if it’s interesting to learn more about some methodology, a review with links to literature is in the text of the diploma

Determination of the average time required by the user according to the GOMS, KLM technique

Based on the average values, they simply calculate how much time the average user would spend on basic tasks. True, it is unclear who determines which user scripts to calculate.

Entropy RGB Profile

The visual complexity of the system is evaluated. Obviously, a program with ten panels and twenty buttons is more complicated than the Google start page. Naturally, the method is very relative, but simple and fast.

Information Productivity

The ratio of the minimum amount of information needed to complete a task to the amount of information that a user must enter. For example, if an informational modal window with a single “OK” button is displayed, then the information entered by the user (clicking on the button) is absolutely useless, which reduces the indicator of information performance.
It is not very clear how to determine whether information is necessary or not for increasingly complex cases. Most likely, an expert is indispensable.

XML tree parsing

The more complex the code that describes the interface, the more likely the program is more difficult for the user.
A very controversial statement, most likely it works only for a very rough assessment (Photoshop is more complicated than the notpad, since there is more code).

The number of classes into which interface objects can be divided

On this last, so clumsily called method, I stopped.
Before describing the essence of the method, I immediately make a reservation that its scope is quite limited. When I only found out about him, he shone with a fabulous light, but in the process of working on a diploma, he somehow haggled a little and was blown away. Most likely, this method can be used for small application widgets, in which you can more or less highlight the main tasks and constant sequences of actions. It is not suitable for creative applications with supercontrol and unformalized results (Photoshop, AutoCAD, etc.).

I was based on the method of assessing the complexity of the Tim Comber and John Maltby system described in Comber T., Maltby JR Investigating Layout Complexity; in Proc. CADUI, 1996.

We denote the complexity of system C. In accordance with Claude Shannon’s theory of informational entropy, finalized by G. Bonsipe, the complexity will be determined by the formula


where N is the number of all objects,
p _i is the ratio of objects in the i-th class to all objects (pi = ni / n),
n is the number of classes of objects,
n _i is the number of objects of the i-th class.

For use in video display terminals, we assign the complexity to the location and sizes of objects:
C = C _S + C _D ,
where C _{S is} based on the class-sizes of objects and C _D on classes-relative arrangement.

Difficulty of an individual object:
C_O = C / N

Of course, this is a primitive way. But this is a way that at least somehow tries to distribute objects by type. If the buttons are the same size and stand side by side, then everything is simple. If all controls are different, then the functions performed by them are also most likely diverse and specific.

The original algorithm involves evaluating only one, the main screen of the application. I will evaluate the complexity of the entire sequence of screens that a user must go through to complete his task. For each screen, an indicator of complexity is calculated, and if during the execution of the task some elements of the interface remain constant, a reduction factor is introduced for them.

To make the assessment more attached to life, I suggested introducing factors of significance of users and tasks.
Users are divided into several groups depending on their needs and tasks performed, a significance factor is set for each type of user.
It depends on:
- the number of users of a given type,
- the frequency of their use of the product,
- the cost of their time or the marketing significance of this type.


C _uk is the complexity of the system for the k- th type of users
C _tn is the complexity of the nth task
K _tn is the coefficient of importance of the nth task for the user

After we get information about how difficult it is to use the interface for each group of users, we can calculate the total complexity. To do this, you need to summarize the difficulties for the types of users multiplied by weighting factors of user significance.

The main difference between this approach and the original methodology is that we rely on real people with real needs. A program cannot be abstractly complex; it can be complex for people whose tasks they don’t or do for a long time, and overloading with unnecessary information. In fact, the concept of complexity is redefined in accordance with the tasks.

Briefly

In total, I took a technique that determined the complexity of the interface, measuring how many classes you can break all controls and how many controls in each class.
First, I proposed to single out several types of users, each, depending on the number, frequency of use and cost of time, to assign a coefficient.
For each type of user, highlight tasks with different significance factors.
For each task, create a sequence of screens and already count them according to the original method.
In the end, an assessment is obtained that reflects how easy the interface is for performing specific tasks by relevant users.

Weak point: you still need to highlight users and tasks independently. But once you figure out what types of users and what their tasks are, you can quickly and cheaply consider how alternative versions are worse or better. It works only for fairly simple programs.

Usefulness: it turns out not a vague expert comment, but numbers that can be compared.



In the diploma work, in addition to the special part, there is quite an interesting part with stories and stories about all sorts of horrors that occurred due to usap fakaps, a review of financial damage statistics that cause crappy interfaces and an overview of all sorts of ways to evaluate usability (carefully, albeit a little clumsily, collected and translated from a dozen sources).
You can see the content, and if you find something interesting, download the diploma itself .