There are lots of reasons for software to push messages to the user and a variety of ways for this to be done. Messages are often overlooked and left until late in the development process, but they an important aspect of design, since they represent the software reaching out to the user directly. Messages can be a great way to set the tone of your software: businesslike, friendly, casual, or even off-beat. They can also be a great way to irritate users by interrupting them inappropriately, using unnecessary technical terminology, and offering unclear choices.

At the heart of creating great messages is choosing the right basic style for each type of message. Some things need to be said in a modal pop-up, whilst others need to be barely hinted at. If your project is small, you can control the design of every message, but in other circumstances (such as a large corporation with lots of products), you need some good standards to promote consistency and help product managers and developers make good choices even when you aren’t there.

This article outlines a framework for thinking about messages and identifying the right kind of approaches for each one. The analysis and options are meant to be reasonably comprehensive, so if you are constructing a set of standards there is no need to support all of the formats that are described. Instead, a set of standards should aim to provide one or two valid solutions for each of the cases.

THE FRAMEWORK

The framework considers messages to be made up of five factors:

The type of message: this describes the basic content and purpose of the message: positive feedback, warning, user error, system failure, confirmation, alert, or loading.
The interaction style: primarily whether the message is modal (preventing the user from doing any else until it is dismissed), or non-modal.
The message format: how the message is presented to the user, for example as a pop-up, a banner, by placing text next in amongst content, by highlighting a control etc.
The message content: the actual text and/or icons used in the message.
Actions and behaviours: any actions associated with the message, e.g. Yes/No buttons; or behaviours such as a message fading and disappearing after a certain time.

TYPE OF MESSAGE AND INTERACTION STYLE

This article deals primarily with the first three of these – essentially the question of how to select the right kind of message format, given a specific situation.

The table below is a decision matrix representing the first two factors, with the message type shown down the left and the interaction style across the top. For a particular message, select the correct row and column. The cell where they cross over indicates the message formats that are appropriate to that situation. Example messages corresponding to each of the cells can be found later in the article.

Note that some cells are greyed out to indicate that this combination is an inappropriate choice. Positive messages should never be delivered via a modal message, since this interrupts the user’s flow with a message that everything has proceeded as it should. In contrast, Confirmation dialogs should not be non-modal, since this defeats their purpose by allowing the user to miss them.

Loading / progress indicators and messages which provide some form of countdown are a special case since the message will expire automatically of its own accord. These messages may be modal or non-modal. More details for these are included in a separate section.

EXAMPLES OF THE MESSAGE FORMATS

The following examples are intended to illustrate the different formats of message that would be appropriate in each section. However, the actual content is meant to be amusing – please don’t copy them!

1 – Positive Feedback