User Interface Design – Best Practice Guidelines

FSS User Interface Design & Development

If you stop and think about it, it is not surprising that almost everyone has an opinion on user-interfaces.  They are after-all what a user spends time interacting with, we have all had experiences of working with software that we find intuitive and also conversely we all have had moments of frustration where simple actions seem impossible to initiate.  In this article we focus on software based user interfaces (touch screens, etc. rather than physical buttons and switches).  We summarise the consequences of poor user interface design and give some best-practice guidelines that should help provide focus to User Interface developers.

In a safety critical environment, it is even more important to get the user interface right as the consequences of initiating the wrong action (or delays in selecting the correct course of action) could have disastrous consequences.

Clearly the process for a user interface comprising of a basic on/off workflow is incredibly simple.  But for users in complex and potentially hazardous environments a more robust process is needed to get the right results.

Human Error Refresher!

A human error occurs when an unexpected consequence happens due to a man-machine action (or series of actions).  Before looking at user interfaces and best practice guidance, it is worthwhile to visualise a simple workflow that shows the different ways a human error can occur:

human_error_flow_chart

With this in mind, we can go onto define user interface best practices, not only to define easy-to-use interfaces, but more importantly interfaces that minimise the probability of errors occurring.

Best Practice Guidelines – Introduction

The following guidelines are each expanded in more detail below:

  • Plan properly and realistically
  • Learn what you can about your target user.  What are their operational tasks, their typical prior user-interface exposure?
  • Learn about the operating environment
  • Build the right team
  • Design well – enforce consistency – Define a Style Guide
  • Manage Trade-offs – use dynamic prototypes
  • Use dedicated tools, and a dedicated development process

Plan Properly and Realistically

If your aim is to produce a great user interface that all stakeholders are satisfied with, the first step is to be realistic about the tasks involved, the people, software tools and time needed. There is not much that is unique to UI project planning over any other form of project planning, but it is worth taking a bit of time to consider the following, before producing a realistic plan:

  1. Do we fully understand the required system operation?
  2. Do we fully understand the operational environment (lighting levels, vibration, user’s restricted movement, specialist clothing, etc.)?
  3. What do we know about the end-user’s workflow, most common tasks, stress-points and previous UI exposure?
  4. Where are we starting from, what is desirable to re-use or replicate?
  5. Are we using technology that is new to us, if so how do we gain expertise in it fast?
  6. How and when will the user interface design be ratified – can we get agreement using prototypes to de-risk the solution?
  7. Do we have a streamlined process and the appropriate underling software architecture to develop the user interface efficiently?
  8. What are our dependencies, can we prototype and demonstrate dynamic user interfaces even if the systems behind are not complete?

Tips on answering these questions can be found in the following sections.

Learn what you can about your target user. What are their operational tasks, their typical prior user-interface exposure?

It is a fact that the operational experts and the user interface developers are going to be different people that speak in different technical terms.

This task is all about creating a user-interface that is going to be intuitive to the end user (and minimising the risk of the user interface failing acceptance testing).

So how do we record what an operator (or collection of operators) do in a way that is accessible to the development team? Here are some ideas:

  • Take the development team to a similar environment and educate them. E.g. for aircraft systems can you run developers through different scenarios in a flight simulator?
  • Hold regular briefings, focussing on one functional area at a time?
  • Bring operational experts into the development team
  • Perform “Operational Analysis” and record the analysis in an interactive model
  • A combination of the above!

More on “Operational Analysis”

We have supported operational analysis tasks, and found them to be an extremely effective means of recording the operator’s view of their tasks, in a way that is accessible to developers. This has significant advantages over ad-hoc briefings and site visits, in that it is an efficient way of permanently recording the information, which can be shared for the whole project life, and will be useful even when team members change.

The idea is that operational experts explain what they do to an expert in software / requirements modelling. The operations are recorded in a model that can be navigated by all the development team. Previously we have used a specially stereotyped UML model to help with this process. The idea is to record the operations in a “work flow / decision tree” format. The tree must support the following workflow modelling concepts:

  1. Show a normal sequence of events
  2. Show jumps required, e.g. on unexpected events occurring
  3. Show single user– tasks an operator is doing at the same time
  4. Show how users interact – tasks operators are doing collectively or at the same time as other operators
  5. Drill-Down – arrange complex tasks into summary blocks, under which a more detailed model of events can be created (and so on)
  6. Annotatable – use colours e.g. to indicate normal path, emergency event response paths, link tasks to system requirements or historical UI screenshots, etc.

Ways to build an operational analysis model include:

  • One-To-One sessions with normal operators
  • One-To-One sessions with experts, trainers, etc in specialist areas
  • Operational environment visits, etc.

 

Operational_Analysis_Model_Example

Example of an operational analysis model style, note an entire user’s operational workflow can be recorded in a single navigable model. By using a task hierarchy where tasks are broken down into sub tasks and then in-turn into their constituent parts. This makes it easy for UI developers to quickly “drill down” to the areas they are developing the UI for.

Learn about the operating environment

We all make assumptions, when a user interface designer makes bad assumptions the cost of rework can be costly. Learn about the operating environment, for example:

  • What is the range of lighting levels? – May need multiple palettes depending on light levels
  • What about vibration? – may need large touch areas, or specialist drivers to work out operators true intent from multiple screen touches in short time period
  • What about clothing – does the operator wear gloves, etc.
  • What about previous environments – are users expecting certain icons, colours, etc.

Understanding the answers to these key questions can have a fundamental impact on the UI design.

Build the right team

We have an article on software teams here. But for user interface development you also need the following:

  • Human Factors experts
  • Technology Experts
  • Access to end-users

Design Well – Enforce Consistency – Define a Style Guide

Large user interfaces can only be developed with large teams, sometimes different functional areas are produced by separate suppliers, so there is a need to ensure that all contributors work to common design principles. It is essential to ensure that when the complete system is fully integrated the end-user is presented with a consistent look and feel. This is a major factor in preventing “miss-selection” type errors.

A good style guide will define all of the design parameters to work within, using specific details for your technology choice, it will include:

  • The colour palette, fonts and their usage
  • The “widget types” and how to choose (e.g. when is a check-box used and when is a toggle button used)?
  • Layout guidelines
  • Clutter guidelines
  • Page navigation guidelines

Ideally the style guide will be traced to human factors guidance, samples / prototypes and also evidence as to why a particular choice was made. The trace is important for maintenance purposes, so when someone proposes a change to the style-guide it is possible to trace back to the reasons behind the original choice, before changes are made.

Over the course of a large product the style guide may evolve, but in the interests of reducing re-work the first working draft should be as well thought out as practical.

Manage Trade-offs – Use Dynamic Prototypes

User Interface design is all about compromise, so how do we ensure we make the right compromises?

user_interface_grades

A common example of compromise is deciding on how much information to display at once. Fast decision making and clarity is helped by avoiding overloading what is displayed, but you may also want the end user to have “all” the information available at the same time. When faced with difficult key decisions the style-guide may help, but sometimes you simply have to try out different options. Create working prototypes and engage with the end-user community.

Use Dedicated Tools, And a Dedicated Development Process

Managing the man hours required for a complex User Interface is not easy, but it is made a lot easier when you have dependable metrics to base management decisions on. To achieve predictable and efficient User Interface development, three things are required:

  1. The right process
  2. A good team
  3. The right tool-set

It is obvious that it is worth spending time fine-tuning the process, selecting the team and also the development tools. Check do you have the following capabilities?

  • Can you build visual design prototypes quickly?
  • Can you build dynamic (interactive) prototypes?
  • Can you test your user interface’s interactivity using repeatable automated tests?
  • Can you create new certifiable widgets easily?
  • Can you test /demonstrate the user-interface even if the system is not present?
  • Are your tools interconnected, can you trace from UI design right through to the system components and requirements?
  • Does your process scale to multiple developers and distributed teams?
  • Can you verify that your UI will work on the target hardware early?

We firmly believe that selecting the right tools is paramount to delivering a quality solution on time. The tools should be intuitive to use, yet powerful. We can advise on specific products for ARINC 661 development that are used worldwide to cut the development time for ARINC 661 solutions.

In Summary

There is a lot to consider when embarking on a large scale and/or safety critical User Interface project.

Flexible Software Solutions offers user-interface development support advice throughout the UK and beyond, contact us for more details.

We believe this article (although brief) to be accurate. If you have comments or suggestions, or believe there are inaccuracies in this article – let us know, we appreciate your feedback.

The author (Rob Harwood-Smith) has been developing software for more years than he cares to mention, his experience ranges from embedded safety critical software, large scale database systems and also to custom business software solutions. Rob has a passion for helping others deliver great solutions driven by friendly and safety-aware user interfaces.