In this article, we address an often controversial topic: When is a software application good? Or to put it another way: What makes good software? Somewhat casually formulated, one would probably say that an application "is good when it is useful and can do well what it was made for". More formally, the application should have a high degree of ease of use or usability. For the sake of simplicity, we will use the English term usability to discuss these concepts.

Hmm, what exactly is usability?

The term usability is not always clearly defined and is certainly interpreted differently by different people. A simple search on the Internet yields a variety of not always congruent definitions. Usability can of course be applied to any man-made object (not just software), but we are not interested in that here. Often one comes across the term software ergonomics. What is certain is that usability is not measurable on an absolute scale and that is exactly why it often falls victim to subjective perceptions. This then leads to discussions about who is now right with his assessment of the software.

In this article we try to get to the bottom of the term usability and in particular to take a closer look at the measurability. We will try it in a very simple way and distinguish only the following three aspects in relation to the usability of a software application:

• Functional scope(What can the user do with the application?)
• Operating concept(How can the user do something?)
• Response time(How quickly does the application respond to user input?)

Let's shed some light on these terms below and take a closer look at each one.

The range of functions: What can my application do at all?

The functional scope of an application is often overloaded and does not really cover what the user actually needs. What good is an application if I don't need 80% of the functions offered for my work? This ballast is usually not just somewhere in the background and has cost me a lot in the purchase - no, it may even hinder me in the use of the really useful 20% of the functions. Rumor has it that well-known applications like Office products suffer from this malady. Concrete, corroborated statistics are not easily found. And those that are found are certainly to be taken with a grain of salt. However, you can easily find dozens of blog posts on the web ("The 50 hammer tips for Word", "Hidden settings in Microsoft Office", "10 practical tips for Word" etc.), which suggest that the typical Office user obviously only works with a small part of the available features and does not know the rest at all.

A good application therefore has as many functions as possible that the user expects and uses on a daily basis. The term "exactly these functions" is of course defined somewhat differently depending on the user. But if we imagine a business application that is used by a large number of users in the same company or even within a business sector, then a common denominator can certainly be found across these users. Such a business application must offer those functions that optimally support the typical business processes. And if the price is right, many an organization is also prepared to adapt its processes to a standard product for the few deviations from the desired application.

The operating concept: How do I do now again...?

The operating concept of an application determines how quickly a user can find and use the function he needs for a task. One often speaks of the user's intuition or that the "application can be operated intuitively". Of course, the principle of subjectivity applies here as well: what is intuitive for one person is complicated and incomprehensible for another. Here, after all, there are measurement possibilities. Simplicity of use can be measured and evaluated over a larger group of users. The test persons are simply given a task to solve with the application and it is measured how quickly they actually manage it. In this way, different applications built for the same purpose can even be compared with each other quantitatively and compared somewhat objectively (because statistically). In practice, different competitive products simply have to face the market. A pilot operation that can be set up quickly and is sufficiently long can definitely help.

A good operating concept is always consistent, i.e. as consistent as possible across all functions: The same actions are performed in the same way. Searching for objects, setting displays, opening and editing data elements, deleting objects,... Everything always works according to a uniform principle. It is precisely when assessing the operating concept that it becomes clear whether the developers of the application have pursued a generically applicable approach from the outset, or whether the application has simply become somewhat larger over time and functionalities have to be called up differently again and again because there is simply no common thread running through the application.

The response time: How long does it take again!?

Last but not least, there is the response time. The most appropriate (feature set!) and intuitive (operation!) application loses a tremendous amount of value and user acceptance if it's slow. And it doesn't take much to be considered slow. At least from the point of view of often very demanding users. Time is money. And nobody wants to spend a lot of time waiting in front of the screen every day until the expected data finally appears in front of me. A few seconds are already too long when it comes to a function that the user calls up every few moments. The non-existent performance of an application is often death in sales. "Luckily," you may still say to yourself, "the competing product isn't faster either." But in this day and age, when new technologies are replacing each other almost on an annual basis, bandwidths on networks and especially on the Internet are getting better and better, and computer performance also doubles about every two years according to Moore, in such times there are no more excuses for poor performance.

How does a software application achieve high usability?

One often speaks of user-centered design or user-driven design. By this we mean the inclusion of the future user in the entire development process. Ideally, this begins with the first description of the future application, i.e. in requirements engineering: What should the application actually be able to do (functional scope)? From our experience, a purely textual description of these requirements is of little use. In terms of the prose formulations, the project participants are quickly in agreement. But the core of the matter lies in the screen design. This is where the user actually sits in front of the screen and does what the application was built for. The best way to start is with simple sketches on a whiteboard or in a suitable drawing program. In a pinch, PowerPoint will also do. Later, these screen designs have to be cast into clickable mock-ups. So that the users can play with them and develop a feeling for how the usability is. Only in a later project phase can the construction of a prototype begin. This is where the performance, i.e. the reaction time of the application, comes into play for the first time. Of course, this only really becomes apparent (or not) when the final quantity structure (larger number of users, realistic data stock, actual network latency, etc.) is simulated.

There is enough literature about the development process of a software application and the inclusion of the users. We refrain here from even starting with a reference list. However, we will gladly come back to possible and good development methodologies and processes in a future article. Just stay tuned.