Living Style Guides – The Future of UI Design?

Like virtually all artifacts in software development, the style guide is also subject to continuous change. Nevertheless, traditional versions are frequently used today, even though technological progress has long since opened up new ways to bring traditional documents to life. This blog post addresses this issue, using the example of the style guide to show how its continuous development can improve the collaboration of designer and developer: Are living style guides the future of UI design?

Once upon a time… there was the document-based style guide

For a long time, the collaboration of the UX designer and the front-end developer was governed by an artifact: the document-based style guide. This style guide is typically created as follows:

  1. First, a requirements analysis is done.
  2. The designer then creates mockups based on the requirements.
  3. The mockups are discussed with the client (x iterations) and finally approved.
  4. Then, the designer creates the agreed graphics with the design tool.
  5. The “style guide” document is compiled from the graphics and corresponding descriptions.
  6. In case of amendments, all these steps have to be repeated.
figure for a document-based style guide
Figure 1: The document-based style guide

As a basis for communications, a good style guide should include the following points:

  • Concept (application from the project’s perspective, product vision, UX objectives)
  • Structure (structure of the application)
  • Interaction design (design of the dialog between the user and the system)
  • Color scheme (rules of use for colors)
  • Typography (fonts and font sizes)
  • Icons and graphics (overview of all icons and graphics of the application)
  • Standard interaction elements (repeatedly used user interface elements)
  • Special views (non-standard UI views and control elements)
  • Language (communication style and wording)
  • Multimedia (use of images, audio and video)

However, listing the standard interaction elements in particular in a rigid, document-based style guide is not ideal. Considering the number of different UI states such as hover, active, selected, etc. for each element, this list can easily grow to several pages. Few developers like to dig through pages and pages of documents; therefore, the risk of non-compliance with the style guide increases.

Furthermore, the traditional version of the style guide poses two problems: The rigid reference to a document which is often very long requires great imagination, and there is no possibility of interaction with the various elements.

Status quo & future of UI design… coming to life

There are several approaches for addressing the points of criticism described above. For example, the content of the style guide can be brought to life by means of a UI prototype kept and updated in parallel. This makes it possible to test the various states of the standard interaction elements in the context of the application, or also to represent special views in detail. With this “hands-on” mentality, the design requirements become clear more quickly, and the tedious rifling through style guide documents becomes unnecessary.

However, this solution does not eliminate the following issues: In everyday project work, the designer often creates templates that are too unusual and cannot be implemented with the applicable UI framework without significant additional effort. The limited range of functions of the prototyping tool is another problem. It is not always possible to simulate the final behavior down to the last detail, which can lead to false assumptions.

Therefore, the current trend is towards implementing the entire style guide as a separate “live” web application. This means that the elements are implemented in the actual application before use, and the developers only need to copy the source code.

Some useful references:

example from the IBM Style Guide
Figure 2: Example from the IBM Style Guide (www.ibm.com)

The benefits of this implementation are obvious: In addition to a clear structure of the necessary information and elements, maintainability in particular improves significantly. If a color has to be changed, this usually only means a change of the color code in the style sheet in the “living style guide”; whereas in the traditional, document-based style guide, countless paragraphs and designs have to be updated. Furthermore, the QA department can test the required behavior before the actual development starts. It is even possible for changes in the style guide to be adopted into the application immediately if both applications reference the same style sheet. This way, redundancies and inconsistencies can be excluded from the start. The level of integration of the style guide into the development process certainly depends on the project at hand, but the possibilities of optimization are limitless in this respect.

The “living style guide” has become all the rage, and it is used by numerous top IT companies such as Google or IBM. It continuously reduces the gap between design and development, and in the end, the one who profits the most is the user :-)!

Design Principles Reloaded: 13 Important Usability Principles

Some time ago I presented the design principles we use at Saxonia Systems (since 03/2020 ZEISS Digital Innovation) to design and develop user-friendly Software in a blog article. As part of the development of our Custom Usability Index, which can be used to measure the degree of usability of a software project, we as Usability Team took a closer look at those principles and extended them to 13 top categories, which contain multiple usability aspects each. In this article those categories and aspects are explained in more detail and illustrated with examples.

Effectivity: Reach the goal. (Principle 1)

The first and therefore most important rule is the observance of effectivity. An application should enable the user to work effectively by providing a suitable functionality for the completion of his task. The user is not overloaded with information and functions that are not necessary for his use case. Accordingly, dialogs should only contain relevant or frequently used information. Every additional information distracts the user from the important content and brings the risk of reducing relative visibility.

It is therefore necessary to answer the central question: What is the task to be supported? An in-depth analysis of workflows and their comprehension is the key to understand the tasks and goals of the users to be able to evaluate the efficiency of the implementation.

several clocks with different characteristics
Figure 1: How much information is necessary to display the time?

Efficiency: Reach the goal quickly. (Principle 2)

Particular attention also needs to be paid to the optimisation of efficiency. The user should be able to accomplish a task in minimal time. At the same time, the application requires only minimal time to react and execute an action. So, this principal refers to the speed of operation of both users and the system. Indications of users not being able to work efficiently are for example unsuitably used interface widgets, missing default values, misleading search results and high-resolution pictures requiring a fast internet connection.

Signs of low system efficiency, on the other hand, are delayed reactions to input in the form of a “shaking” cursor, slow interface widgets and missing feedback.

Controllability: The user has the power! (Principle 3)

The user has, regarding his authority within the system, control over all actions. He may cancel, pause, and resume actions at a later point in time. It is possible for him to revert an action and, as the case may be, start a new attempt if the result was not satisfactory. To control the application, the user still has the option of using alternative input devices to the mouse, such as keyboard, screen reader and Braille display, according to his personal requirements.

Not satisfying these points will lead to increased frustration for the user.

Customisability: Everything suits the user. (Principle 4)

The application should be flexible enough to support different approaches for the completion of a task. Additionally, the user can customize the system according to his previous experiences, culture and needs e.g. by changing font size, changing the default settings, and setting his own shortcuts. A good example for the consideration of customisability is the online platform http://www.elster.de/, which is used for web based registration and submission of tax returns. After logging in, the user is asked to which user group he belongs to, to better adapt to his needs afterwards.

Consistency: Everything fits together. (Principle 5)

The control of the application should comply with the expectations of the user in every aspect and needs to follow general conventions (platform, style guides, etc.). One part of it is the consistent usage of terms, icons, and layouts within the application and in product families. Process structures also follow a uniform principle. By maintaining consistency, the user can reuse a behaviour pattern once learned. When using an application for example, every user knows (or expects) to find the button to close a dialog window in the upper right corner. When switching to the operating system Mac OS X he has to completely readjust.

Evidence that an application does not behave as expected and consistently includes surprised to confused users and e.g. the use of different terms for one and the same function.

Design and layout: Comprehensible at first sight. (Principle 6)

This principle comprises every aspect of visual design of an application. According to that, the kind of aggregation, layout of the GUI elements and purposely used colours should support the user with recognising links. Information and components are generally presented to the user in such a way, that they can be noticed and that texts can be read easily. Indications of not satisfying this principle are e.g. no obvious correlation between labels and data fields, tiny fonts and low-contrast colours used for front- and background.

Language: Speak the user’s language. (Principle 7)

The application should basically be in line with the user’s language and way of thinking. Text elements should therefore be verbalized clearly and a for the audience understandable vocabulary should be used. Nevertheless, a lot of things are worded technical instead of using the user’s words. The “best” example for it are error reports with a high degree of detail, therefore valuable for the system developer, but not helpful for the user at all. To avoid this, an in-depth analysis of the user’s technical vocabulary is necessary.

Visibility: The user recognizes his possibilities. (Principle 8)

To guaranty the user’s ability to complete his task instead of becoming lost, he needs to know at any time, in which part of the application he is, which actions can be executed and how they are triggered. He also needs to know his system’s status at any time. That is why the main menu should display the user’s current position and e.g. comprehensibly show how to get there using a breadcrumb navigation. Relevant objects, functions and options should be visible to the user’s eye and enable him to find the desired klicks directly. He needs to be able to estimate the effects an action is going to have.

Feedback: The user is told what is going on. (Principle 9)

The system should react to the user’s input at any time and inform him about events actively. In case of an occurring error, a corresponding notification illustrates its reason and suggests a solution to the user if possible. Shortcomings of an application regarding feedback can for example be a missing spinner icon during complex operations. User inputs seem to be ignored by the system and the user experiences the application as “frozen”.

Learn supportive: Easily learnable. (Principle 10)

The system should support the user getting to know the interface and should encourage him to try previously undiscovered features without having negative effects on the user. Especially during first usage the user should be supported when performing complicated actions and limit possible missteps this way. At this point, short tutorials and explaining texts are helpful. A possibility for experimental learning would be a test mode, meaning a separated test section within the application, where all the functionalities can be tested without consequences. Using a test mode, the user is training using the system und learns dealing with it without having to completely execute the processes.

Help and documentation: Help, that helps. (Principle 11)

Help systems should be easily findable or embedded into the interaction. Embedded help is for example implemented by using tool tips, place holder, short help texts and assistants. Are those not sufficient, contextual help like a help panel, getting-started pages and a search function should be the choice. Note that a help system is only supporting the user when relating to the user’s task and listing specific steps to solve the problem.

Error tolerance: Forgive and avoid user errors. (Principle 12)

The system should be designed to save the user from mistakes from the beginning, for example by disabling invalid functions and describing the reason for the restriction. In case of happening anyway, the system should detect invalid inputs or actions. If they are unmistakable, the system can correct the mistakes on its own if possible. Are there multiple possibilities, alternative suggestions are shown. Under no circumstances errors may lead to data loss or even a system crash.

User experience (UX): The software feels good. (Principle 13)

One aspect not yet considered is the user experience (short UX). It results out of the complete experience of the user with the application and is made up of the actual usage, the user’s expectations, and the previous experiences with other systems. The application mediates a feeling of security and reliability, is fun to use and serves the purpose. The system excites the user by not only satisfying specific expectations, but also overshoot them. Principle 13 is mostly fulfilled by sticking to the principles listed above. A slow, inconsistent application with a lot of error messages and crashed will not contribute to the user’s satisfaction. That is why the software should be up to date with the current technology and should support the current control paradigms.

Conclusion

13 important principles for reaching user-friendly, satisfying software were presented in this blog article. Take note, that there is no such thing as the one and only user-friendly solution. How comfortable it is to use an application always depends on the specific use-case and the user group. This is why it is recommended to analyse the users‘ needs and involve them through user tests.

Additional literature

  • J. Nielsen‘s 10 Usability Heuristiken (Web)
  • B. Shneiderman: 8 Golden Rules of Interface Design, In: „Designing the User Interface: Strategies for Effective Human-Computer Interaction“ (Web)
  • DIN-Norm EN ISO 9241-110: Grundsätze der Dialoggestaltung (Web)
  • B. Tognazzini, Principles of Interaction Design (Web)
  • J. Johnson, GUI Bloopers 2.0: Common User Interface Design Don‘ts and DOs, 2007
  • D. Norman, The Design of Everyday Things: Revised and Expanded Edition, 2013
  • Web Content Accessibility Guidelines 2.0 (Web)

The Custom Usability Index (CUI) in Action – Usability Tests in Agile Software Development

Starting point – The story so far…

In two previous blog posts, I presented the concept of the Custom Usability Index and described the preparation phase, where the usability categories are customized and weighted, in more detail. In this post, I would like to elaborate on the application itself, and explain the steps necessary to obtain a valid CUI evaluation in the end.

This is the starting point for our application example: We are developing a new web application for a business client. At the start of the project, the product owner in charge had the usability categories explained to them by a UX expert, and then defined the target states. Then, they prioritized the latter according to their requirements, laying the foundation for the regular rating of the future application using the CUI. After a certain period of development, the first release candidate has now been deployed to the QA system, ready for testing.

The Custom Usability Index (CUI) in action – Now your software is up to bat!

What do we do now? There are several different test methods for testing the 13 usability categories. The choice of the test method depends not only on its suitability for the respective usability category, but on numerous other factors as well. The availability of the end users, the know-how of the usability tester, and time and financial resources play an important role. In practice, the preferred scenario in which numerous end users are comprehensively tested by several usability testers with minute-keepers over an extended period of time, is rare.

What do we forfeit by restricting the resources? Basically, accuracy and independence of the evaluation. But this is not the primary objective of the CUI. The tests, irrespective of their scope, are primarily supposed to identify problems and potential for improvement. That means that, even if the result of test A deviates from test B, the problematic issues are clear, enabling concepts for developing software with better usability. A resource-friendly method of testing is the heuristic evaluation. Heuristic evaluation is an inspection method where a group of usability experts check an application for compliance with specific guidelines and heuristics (in this case, the usability categories of the CUI adapted to the concept of use). According to Nielsen, approx. seven testers will find 80% of all usability errors; follow-up tests are less productive because few additional errors are identified.

Nielsen (1995): Number of heuristic evaluations vs. usability problems found https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/

In real-life agile software development projects, however, just getting several usability experts for the test is a rarity, which is why the evaluation is usually done by 1-2 experts. Depending on the complexity of the application and the scope of the documentation, a usability expert who is familiar with the application should be able to obtain a viable evaluation result within one to two days. This means that even with several “small-scale” usability tests, you can enhance the quality of your software and realize some improvements.

An example: Evaluation of 13 categories, 31 criteria “in a nutshell”.
Let us start with the category of effectiveness. The product owner defined the following target state for this category: “The user has access to the functions required for the completion of the tasks at all times, and reaches them in no more than two steps. In doing so, they are given no more than the information they need at the time (focus is to be on the data).”

Furthermore, effectiveness was weighted with the Fibonacci number 3.
The category of effectiveness comprises the criteria scope of functions and adequacy. For the “scope of functions” criterion, the different use cases of the web application have to be tested, and in addition, the tester has to check whether the required functions can be reached in no more than two steps.

The current release candidate fully meets the target state for this criterion, and consequently, it is awarded the maximum rating of five points.
Now for the second criterion of adequacy, which requires the user to be given no more than the information they need at the time, and the focus to be on the data.

Several minor anomalies cause a 2-point deduction, resulting in a rating of 3 points. Together with the rating of the scope of functions criterion, the average rating for the category of effectiveness is 4 points.
The other 12 categories and 29 criteria should be rated the same way as shown in the above example. As the complete documentation of an entire CUI test would go beyond the scope of this blog post, we are going to skip to the next step and take a closer look at the final calculation.

Example of a complete CUI calculation

The table above shows a completed CUI calculation matrix after the completion of the test. The final CUI value is calculated as follows:

  • Calculation of the average value of a category (sum of the ratings / number of criteria)
  • Calculation of the relative weighting (weighting value of the category / sum of all weighting values)
  • Calculation of the final category value (average value of the category * relative weighting)
  • CUI value = sum of the final category values
  • CUI degree of achievement = ((CUI value – 1) / 4)

Let’s run this calculation for our example:

  • Rating of the effectiveness category (scope of functions 5 points + adequacy 3 points) / 2 criteria = 4 points
  • Sum of the weightings of all categories = 24
  • Relative weighting of the effectiveness category = 3/24 = 0.125
  • Single value of the effectiveness category = rating of 4 * relative weighting 0.125 = 0.50

Hooray, it’s done! – Now what?

First of all: Congratulations for taking care of your users’ needs. Now, the following steps need to be taken:

  • Develop possible solutions for the identified problems in the form of wireframes and prototypes
  • Illustrate the effect of future user stories with respect to the different usability categories
  • Question the specifications of your product owner… You are the expert!
  • Actively present alternatives instead of unquestioningly implementing the specifications you are given
  • Carry out further CUI tests at regular intervals, thus tracking the effect of the improvements and/or new specifications on the usability of your software

The Custom Usability Index allows you to obtain useful results with few resources. The lightweight method is smoothly integrated into the agile software development process and identifies flaws in your software. Regular tests enable long-term tracking and make usability truly comprehensible. Take the leap—your users will appreciate it!

Brief insight into usability tests in agile software development!

Usability in Software Development Projects

The problem: Making usability comprehensible and transparent

How is the usability of my software? At the latest, this question will arise by the time the actual users first see the application. Often, this is when you notice that the planned software is not really optimally tailored for the end users. However, it is usually too late to make major changes at this point. Subsequent problems such as poor acceptance or even the failure of the software project have been confirmed by numerous studies. Approaches like “user-centered design” that put the user at the center of attention of the development process show just how beneficial such involvement and the consideration of usability at an early stage can be. The core problem that persists, however, is the difficulty of making usability comprehensible. This blog post presents a possible solution.

The idea: The Custom Usability Index

The Custom Usability Index (CUI) is an index that measures the degree of achievement of the usability of computer software at the current project stage.

The basis: 13 design principles

The index represents the aggregated rating of 31 criteria allocated to 13 categories. The categories are based on design principles developed in-house that are in turn based on ISO standards and the state-of-the-art literature on usability.

At the start of each project, stakeholders can weight the categories listed above according to their individual requirements, and thereby specify priorities.

The evaluation: Where the magic happens

As each project is unique, it is important to specify at the start of a project when a criterion has reached the best possible usability. To gain a uniform understanding of the required target state that the application is to achieve with respect to the respective criteria, it is advisable to involve the entire team, including the stakeholders involved, in the definition. The fact that both sides are made aware of the issue of usability is a positive side effect.

The actual evaluation of the criteria is done by means of specific usability test methods. The tests have to be done on the sub-product on a regular basis throughout the course of the project. A criterion is given the highest rating in the assessment only if the previously defined target state has been achieved 100%. The final CUI value then reflects the weighted average rating of the 13 categories.

The result: Usability brings happiness

Measuring the CUI at regular intervals makes usability transparent both for the team and all the stakeholders. The current status of the software in each of the categories is apparent at all times, as are any issues that may still require improvement.

The example above shows continuous improvement in usability up until release 2. Release 3, however, brought a deterioration. By identifying the categories affected, it was possible to remedy the issue immediately during development. The result becomes apparent in the significant increase in usability in release 4.

The CUI presented in this blog post provides a possibility to measure the usability of software throughout the development process, and to make it transparent for all the parties involved in the project. The high level of transparency and the stakeholders’ awareness of usability in general constitute a distinctive quality feature of the software.