Finding Your Way Around Usability

The usability of software applications contributes greatly to their acceptance amongst stakeholders and must therefore be constantly assessed and optimised

That cat did actually not get lost

I remember reading a system requirements specification once that included a requirement which laconically stated the following:

The system must be user-friendly.

At a first glance, it occured to me that the author of this requirement must have had a notion of user friendliness of such - almost divine - universality that, alas, he was compelled to refrain from stating the intricacies of this requirement. It turned out that, quite to the contrary, the author deliberately phrased the requirement as fuzzy as possible in order to ultimately let the development team decide on how the application should be implemented in a user-friendly manner.

Although many developers have an intuition as with regard to what constitutes an easily usable implementation of a feature and what does not, this approach is nevertheless not the best one. Instead, one should try to adhere to best practices and heuristics when designing user-friendly applications and should, across their entire life cycle, iteratively test and adapt them together with their stakeholders.

How Can One Define User Friendliness?

The notion of user friendliness or, to use a more common term, usability of a software application is probably easy to describe, but hard to grasp. In my opinion, ISO-9241-11 (see this link for an overview on usability and user centred-design-related ISO-standards) provides a succinct definition of what constitutes the usability of a software application or, on a more general note, a product:

The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use

Obviously, optimising a software application in terms of its usability should both help its users to do their work better and to be more satisfied while doing it. The usability of an application is therefore an integral part of designing your application and should, therefore, be considered right from the very beginning.

Designing Your Application for Usability

In my experience, all questions around usability are mostly associated with graphical user interfaces and their design, as they have visibly strongly evolved in the past two decades and are the "window to an application's soul". The definition given above, however, is much broader in scope, as it refers to the entire product (i.e. software and hardware) and its context of use, which can, for instance, be the step within a business process, the working environment, or even the time of the day or season that a product is used in.

Achieving high usability in a product is therefore much more than simple user interface design, which is why often the term usability engineering is used. Usability engineering makes use of insights gained from various fields such as computer science, design, psychology and cognitive science to derive specific methods that are applied to examine users' needs and context of use and translate them into a usable product. For both mass-market applications and applications focused on experts, I would recommend to involve a usability engineer into the related project right from the very start, as this makes your team understand your stakeholders' needs better and, eventually, build a better and more satisfying application.

Start Off with an Educated Guess

As usually when employing iterative methodologies, it is good to start off with an educated guess about how your application should be built. I recommend that, when defining your Product Backlog, your team already involve a usability engineer in order to identify which stakeholders your application has, in which context they will use your application, and what their specific needs are.

The result of this can be, for instance, Epics formulated from a stakeholder perspective (refer to my post here for more information), process descriptions, personas and/or screen mockups, which can all be used to further detail your Product Backlog Items. Once you start development, make sure that you periodically let your stakeholders test your application in their own context of use, so that you can frequently inspect and adapt its usability.

But what constitutes an educated guess as with regard to usability?

Nielsen's Ten Heuristics for User Interface Design Revisited

In his very recommendable 1994 book "Usability Engineering", Jakob Nielsen recommends the use of 10 usability "heuristics" for user interface design that allow for user interfaces to be specified, evaluated and improved - the educated guess that we were looking for. Although 1994 is already quite a long time ago, the basics of usable interfaces have not changed and Nielsen's heuristics are well-known and still widely being used today.

As I would like to place emphasis on the usability of your entire product according to the definition above, rather than just the user interface, I will take the liberty to both restate Nielsen's heuristics in a more general manner and condense them were appropriate, arriving at my Seven Quintessential Usability Heuristics:

1. Reliability: the perceived reliability of a product depends on its performance and overall availability, the latter also taking IT service continuity and release/maintenance downtime into account. Simply put, your stakeholders want a system that is always working and responds fast to their input, no matter what the circumstances are.

2. Accessibility: stakeholders should be able to use your product from within their own context of use, which may be defined by expectations, metaphors or, even, disabilities that form their reality and should also be reflected or accounted for in your product. A good example for this is the ongoing quest for a new "Save" icon, as the old floppy disk icon may not ring a bell with nowadays youngsters.

3. Aesthetics: aesthetics are very hard to fathom, but often boil down to a unison of simplicity and harmony. A good example for this is the balance of colours that should be kept within a user interface, using only colours from a colour palette that has been optimised for visual harmony.

4. Intuitiveness: your product should be usable right from the start, without any or with only minimal instructions. Once your users have themselves learned how to use basic features through experimentation, they can use induction to easily learn how more complex features work (consistency is key here). This behaviour also helps stakeholders that use your application less frequently.

5. Transparency: your stakeholders want to know what is happening in your product, but, of course, in a reliable, accessible and aesthetic way. To me, cross-device optimisation is a good example for transparency, as it lets your users follow a process from all possible contexts of use. Me watching Netflix movies on my cell phone in the gym is also a good example, of course :).

6. Guard rails: being wrong costs time, is annoying and, often, also discouraging. Your team can help your stakeholders by giving them adequate guard rails (e.g. input validation), helping them understand what they did wrong (do not show Exceptions in error windows!) and letting them easily and quickly recover from their mistakes.

7. Helping hand: no matter how accessible and intuitive your product is and how many guard rails you have built in, there will always be users that get or feel lost. Lend them a helping hand in your product! Good examples are on-item instructions on hardware and walkthroughs and in-app tooltips in mobile apps.

How Do You Become Entangled?

Being in touch with your stakeholders in order to design and optimise your product such that their needs are met in the best and most satisfactory manner is probably one of the most important parts of your team being entangled with its surroundings.

So, whatever the product or application is that your team is building, you should at all times strive to understand what your stakeholders need, want and how you can improve. Usability engineering research, methods and heuristics can help you make an educated guess about a usable product, which you should, however, deliver to its users as quickly as possible in order to obtain feedback about its usability in a real-life context.

Care to Know More?

Care to know what the post featured image is all about? On a recent trip abroad, I was surprised to see roughly 30 streets cats of various shapes, sizes and colours lounging at the bottom of a ditch in the city centre, curled up next to each other . But there was a single cat that really caught my eye: away from everyone else, it was resting in a narrow drainage pipe in a wall, more than 2 metres above ground. I had no idea how it got there, but I assume it was looking to be away from the other cats and, actually, looked quite relaxed in this akward position.

The learning that I got here is the following: I would have never designed this drainage pipe as a rest place for a cat, but it seems that it turned out to be quite a good one. Obviously, your users behaviour can be unpredictable, so it really pays off to be as close to them as you can get.

Would you also like to know more about this post's topic? If so, then please post your questions in the comments below and I will be answering them. If the subject of your question is a hot topic, then I will dedicate a post to it in the future.