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 :-)!

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!

Prioritizing Usability with the CUI

Starting point – Let’s get started!

In an earlier blog post, I introduced the Custom Usability Index. The index allows you to monitor the usability in software development projects. In this blog post, I would like to further elaborate on this, and to explain the steps necessary to use the CUI.

The above diagram illustrates how the CUI is used in the course of the project, and constitutes the basis for the following observations.

Target state of the categories – Make a wish!

At the start of the project at the latest, the required target states should be defined for each of the CUI categories, i.e. the responsible stakeholders have to specify what they deem to be the optimal state. This state can be different for each project, as shown by the following example. Let us take the category of customizability. It means that the system is sufficiently flexible so as to facilitate different approaches to the way a task is executed. The user must be able to adapt the system according to their previous experience, culture, and requirements. The optimal state could then be described as follows:

  • Project 1: The optimal state in the category of customizability would be for the user to be able to configure different experience levels from the first time they start the application, with the system then automatically adapting.
  • Project 2: The optimal state in the category of customizability would be for the user to be able to activate an expert mode which in turn activates additional settings in the system.

Because of the different optimal states in the above example, reaching the highest possible rating is easier in project 2 than in project 1. When describing the target states, it is advisable to involve the actual users, such as the company’s department for which the new application is to be developed. This ensures that the usability requirements are not pulled out of a hat, and that the actual application is perfectly tailored for the end user’s needs. A general rule of thumb in this context: The more specific the description of the desired state, the better the evaluation results will be!

CUI prioritization – Everything is important, is it not?!

When the target state has been defined for each of the CUI categories, the following problem often arises in practice: the resulting catalog of wishes is extensive, and the client in charge is worried about high costs, or they may pursue different economic goals in developing the system. To take this aspect into account, the CUI categories must subsequently be prioritized. The following questions help with the prioritization:

The questions listed in the table above constitute a guideline for the usability expert in the interview with the client’s representative. The client’s responses need to be translated into numbers. The Fibonacci sequence (1, 2, 3, 5, 8, 13, …, as required) is used for the CUI priority. The higher the number, the more important the category is for the project.

If the client has trouble making a concrete statement as to the significance of the categories, the Magic Estimation method, which comes from the agile approach, can be useful. Here, the individual categories are briefly introduced and then arranged by significance. The comparison often makes prioritizing easier.

<Preparation> CUI </preparation> – Can I finally get started?

Yes! Now that the prerequisites in terms of content (target states of the categories) and business (CUI prioritization) have been fulfilled, the first usability tests can be carried out. All the stakeholders involved have automatically been made aware of the issue of usability, and (hopefully) they are enthusiastic.

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.