Take this page for example:

The banner is the highest element in the hierarchy of this page. The banner and logo tell the viewer that everything on the page is associated with the site named in the banner.

The navigation bar on the left-hand side of the page comes second in the visual hierarchy.

The main content panel’s heading, “Events Calendar”, which describes the contents that follow, forms the third element in the visual hierarchy.

The two subheadings are subordinate to the main heading, so they come next in the visual hierarchy.

Finally, the sections of body text are subordinate to their respective headings. These come last in the visual hierarchy.

When scanning the page, the viewer’s eye will tend to look first at the banner, then move to the navigation sidebar, then the main heading. While the viewer may read the content under the main heading from top to bottom, it is likely that the viewer’s eye will be caught by the subheadings first, and then the viewer’s eye may go back to read the body text.

The visual hierarchy helps the viewer interpret the content on the page in a logical way. Let’s now take a closer look at how create a visual hierarchy and express relationships between different elements on the page.  Our main tools for achieving this are the use of similar or contrasting visual attributes of elements, and the relative positioning of elements.

Attributes

Attributes are the general properties of things on the page. Common attributes are size, shape, color, texture, and direction. For text, attributes include the typeface, weight, spacing, and decorations such as italicization or underlining. In other words, attributes are ways to style a visual element.

Visual elements that are similar or belong to the same category should share the same attributes, whereas elements that are intended to be different should have one or more contrasting attributes. If one element is intended to be stronger or more important than the other element, then the attributes should be chosen to reflect that.

For example, if you have a list or a menu, then all of the entries belong to the same class or category of elements, and so they should be styled consistently with the same attributes. But the heading that sits atop the list serves a different function. It describes or summarizes the contents of the list or menu, and so it should be styled with contrasting attributes that emphasize its dominance. The heading might be larger or bolder, or it may take a different typeface or color.

Contrast is weak when the elements being contrasted are only slightly different. When two element differ only slightly, it can often look like the difference was made by accident. Strong contrast is produced when the differences are clearly intentional. To create intentional contrast between two elements, the general guideline is to make sure the elements differ in at least two ways; that is, at least two attributes should be different between the elements.

For the purposes of this guideline, surrounding space is often considered to be an attribute as well, so leaving a gap of whitespace between two elements can count as one of the differences.

The following diagram shows some examples of weak contrast and strong contrast between a heading and a list of items:

In example (1), there are no differences between the heading “Commodities” and the entries in the list, so it does not look like a heading at all.

Example (2) is better — the heading is in bold type — but the difference still does not stand out strongly.

Example (3) places a gap between the heading and the list. While this is also better than (1), it is still not satisfying, as the heading is set in the same type as the list entries.

Examples (4) through (6) illustrate how using two differences produces much stronger visual contrast. Example (4) uses a gap and sets the heading in bold type. Example (5) sets the heading in bold type and uses indented bullets to offset the list from the heading. Example (6) increases the size of the heading’s font and sets the heading in a different color.

The latter three examples communicate the relationship between the heading and the list entries much more effectively than do the first three examples.

Positioning

In the English-speaking world, and in other left-to-right languages, we read from left-to-right and from top-to-bottom. What is at the top of the page is considered to be more important than what is at the bottom of the page, and to a lesser extent, things on the left in a row of things are perceived to come first. (In right-to-left languages like Arabic and Hebrew, the right-to-left direction is reversed.)

Thus, the top-left corner of the page is where the eye begins when scanning the page, and so the most important element in the visual hierarchy is usually placed there.

If we have two visual elements A and B, we should ensure that A is positioned either above, or to the left of, element B, when we want to show that:

• Element A is more important than element B; or,
• Element B is a subelement of A; or,
• Element B depends on, logically follows from, or derives from, element A; or,
• Element A is the cause and B is the effect; or
• Element B naturally follows A in a logical sequence.

As an example, let’s take one example of poor design that I’ve encountered. One system had a screen for editing customer details that looked roughly like this:

Users were expected to enter a value in the Customer Number field and then click Retrieve. The other fields on the screen would then be populated with the data on file for that particular customer.

The above design is poor because the relationship between the customer number and the remaining fields is not communicated by the visual design.

The data on this screen is dependent on the customer number, because the customer number is the identifying piece of information, or key, for a customer record. If the user enters a new customer number and clicks Retrieve, new data for the new customer number will be presented.

But because the user will start reading the screen from the top left, the user might assume that the last name and first name are identifying the customer record. Additionally, the fact that the user is expected to locate the Customer Number field first is troubling; it is buried deep in the screen, and there are no visual cues that it is the most important element upon which the others are dependent. If it is the identifying field upon which the other fields depend, then it should be situated in a place that better communicates its importance: the upper left, where the user begins scanning the screen.

And the fact that the user has to jump from the Customer Number field up to the Retrieve button is poor design as well. There are no cues that this is how the interaction flow is supposed to work; because we read from left-to-right and from top-to-bottom, jumping from below to above is counterintuitive. The button should be moved so that there is a left-to-right or top-to-bottom flow from the Customer Number field to the Retrieve button.

Thus, one possibility for an improved layout might be something like the following:

In this design, it is clearer that the details are dependent upon the chosen customer number. There is a left-to-right flow from the Customer Number field to the Retrieve button, and there is top-to-bottom flow that leads towards the finalizing Save and Cancel buttons.

Practical aspects of visual hierarchy for user interface design

While you may not necessarily explicitly design a visual hierarchy when creating a page composition, an awareness of the general concept of the visual hierarchy and an understanding of how relationships between elements can be expressed can help you produce better designs.

In large project teams, you can try to ensure some degree of visual design consistency throughout your product by creating a style guide that defines the general look-and-feel of the interface in terms of a visual hierarchy. Writing a style guide is not always easy; it’s not always possible to completely document everything that makes up a consistent set of visual designs. But by specifying rules for the styles and positioning of headings and other visual elements, and by providing page layout templates and examples, a style guide can help communicate your design intentions to your project team.

To help us understand what’s involved in interaction design for persistence and transactions, let’s first look at how data is saved in two typical classes of applications: document-oriented desktop apps, and multi-user web and client-server apps.

Document-oriented desktop applications

For document-oriented desktop applications, like word processors and spreadsheets, documents are usually saved as individual files on a disk.

When a user is working with a such an application, there is a copy of the document stored in the working memory of the user’s computer. As the user edits the document, the copy in working memory is modified, and so it will no longer match the copy on disk. By saving the document, the copy on disk will be updated to match the copy in working memory. If the user makes changes to the document and then closes the document or closes the application without saving the document, then the changes will be lost.

Most people with computing experience are familiar with this model. You can indicate that your application uses this model by following standard conventions (which can vary between platforms). There should be “Save” and “Save As…” commands under the File menu, and (especially on Windows) there may be a “Save” icon in the toolbar. On Mac OS X, a black dot appears in the red “Close Window” button whenever unsaved changes are present, and this dot disappears after the document has been saved. On Windows, some applications place an asterisk next to the document title in the window’s title bar when unsaved changes are present.

The dot in the red "Close Window" button indicates unsaved changes are present

Some usability specialists argue that the need to know about the separation between working memory and persistent storage is a “leaky abstraction” — an underlying aspect of the technology that is exposed to the user, creating an unnecessary mental burden. The Canon Cat was a unique word processing system in the 1980’s that hid the distinction between working memory and persistent storage. No “Save” command was offered because the system automatically synchronized all changes with the copy on disk. The popular word processing application Scrivener similarly saves all changes automatically every few seconds, meaning that users never have to worry about explicitly saving their work. Diverting from the conventional way of doing things can initially cause users confusion, though, and so Scrivener still offers a “Save” command in the File menu for convenience, even though it’s never really necessary.

Web and client-server applications

For most web applications and client-server applications, data is usually stored in a database (which in turn stores the data in files on a disk). Database systems allow many different users to access the same data simultaenously.

In applications that are backed by a database, when a user creates, edits, or deletes data in the system, these changes can be accumulated in units called transactions. If other users of the system retrieve data from the database while the first user’s transaction is still in progress, the other users will not see these changes. But when the software issues a “commit” command for the first user’s transaction, the transaction is ended, and the user’s accumulated pending changes are saved “permanently” to the database so that other users of the system can see the user’s changes.

If instead a “rollback” command is issued, the transaction is also ended, but all of the pending changes for that user’s transaction are cancelled, and the database is not updated; other users see no changes in the data in the database.

Most applications hide the technical concepts of transactions, commits, and rollbacks from the user. This hiding is done by aligning the start and end of transactions with places in the user interface where various events or task flows start and end. Terminology is also used that is more familiar to the user.

For example, we can image that when a dialog box such as a Properties dialog is opened, a transaction will be started. If the user closes the dialog or presses the “Cancel” button, then the transaction will be rolled back and any changes the user had made in the dialog will be lost. If the user presses the “OK” button, the user’s changes in the dialog will be committed to the database.

For multi-user systems, you also need to think about what happens when two users try to edit the same information records simultaneously.

Imagine a situation where two users are attempting to make changes to the address information on file for a particular customer. The original address on file is “123 Main Street”. User A opens the address record and starts changing “123 Main Street” to “456 First Ave.”, while seconds later, User B opens the same address record and starts changing “123 Main Street” to “789 Second Ave.” If User A presses the “OK” button to save the changes, and then User B presses the “OK” button shortly afterwards, what happens to the data on file? There are a couple of possibilities:

• User A’s changes get saved, but then User B’s changes overwrite User A’s changes. So the address on file at the end is “789 Second Ave.”
• User A’s changes get saved, but User B’s changes are ignored because User A was first.

Neither of these is particularly satisfying, as both users will think that their changes have been saved, but one user will have had their changes overwritten or lost without their knowledge.

One solution to this issue is to use some form of record locking: When User A opens the customer record, the system locks that record, so that if User B attempts to open the same record, she receives a message that the record is locked and unavailable for editing. When User A commits or rolls back his changes, then the lock is removed and the other users can edit the record again. One problem with locks is that if User A leaves his terminal and goes home, or if User A’s application or operating system crashes, the lock might be “stuck” in place for a long time, requiring an administrator to intervene so that other users can edit the record again.

In many applications, it makes sense to want to allow multiple users to view the same record simultaneously, but only one user at a time should be able to edit the data. This raises the question of whether users who are viewing a record should be notified when the data they are viewing has been changed by another user. If there is no notification and if the display is not automatically refreshed, the user will be looking at “stale” data that was at one time correct, but no longer matches the current state of the database, and this may or may not be a problem depending on the nature of the application.

Collaborative web-based applications where users work together on editing the same document can present many challenges like these, and it can take some creative thinking to find usable and non-intrusive solutions to avoid or manage simultaenous editing conflicts.

Designing and documenting a transaction and persistence concept

We’ve seen that an application’s learnability and usability can be impacted by how it handles the persistence of data and manages multi-user editing conflicts, and how the persistence model is presented via the user interface and interaction design. Therefore, explicitly designing how these aspects will work from a user’s standpoint is a good idea for applications of significant complexity.

Questions you need to ask and eventually make decisions about include:

• What types of data validations take place, and when is the validation performed? How are errors and warnings presented?
• Can data or documents be saved when validation errors exist or when mandatory fields are empty?
• At what points in the application can data be saved? How and when can any changes be lost (intentionally or unintentionally)?
• If the system uses transactions, where do transactions begin and end?
• Does the application save data automatically, or does it rely on the user to use some form of “Save” or “Commit” command? Are controls such as “Save” menu options or toolbar buttons prominently visible, and is it clear to the user how and when to use them?
• How is the user interface structured to help user understand the persistence or transaction model? Is the state of the data (saved or unsaved) made clear?

You’ll often need to clarify some of these questions with the technical architects and developers in your project, as the technology framework being used can often dictate how some of these aspects will have work. At the same time, just because the technology requires things to be done in a certain way does not necessarily mean that you have to expose all of the details to the user; technical details can be hidden. Whenever possible, create the design that is clearest and easiest for the user, and then build the system to support that way of working.

• where they currently are,
• where they can go, and
• how to get to where they want to go.

Designing how navigation and wayfinding works is a key aspect of your application’s information architecture. Let’s find out what you need to consider to design navigation effectively.

In this post, we’ll use “places” as a general term to refer to locations or containers that can present content and controls, because these can have different names depending on the context. For instance:

• In a web application, places usually correspond to different pages.
• In a mobile or tablet application, places typically correspond to different screens or pages.
• In a desktop application, places might be screens, windows, or dialog boxes.

“Places” could also refer to divisions such as panels, tabs, and subsections within a page, screen, or window.

Identification of places using names or titles

When your application has multiple places, each place should be clearly labelled with a title, so that the user can determine what place she is currently looking at. Assigning each place a title then allows you to refer to it in menus and in instructions and help text.

Examples of titles include a “Find and Replace” dialog, a “Departure Schedule” page on an airport website, or a “Level 5″ in a video game. Some places might have user-assigned names; for instance, in many document-oriented applications, the title of a window or tab will be the filename of the document being displayed there.

Some guidelines on naming are given in this blog post.

Presentation of places

Depending on the type of application, you may need to think about some of the following questions:

• Can the user view only one place at once? (Most mobile and table applications work this way.)
• Can the user have multiple places open at once, such as multiple documents in a word processor, multiple sheets in a spreadsheet, or multiple tabs in a web browser? How will you indicate which is the current “active” or “focused” place?
• If applicable, can the “places” be resized and rearranged?
• Can the content in different places be interrelated, and if so, how and when will changing content in one place affect the other places? For instance, in the Eclipse programming environment, if a programmer makes a coding error, the error will be detected almost instantly and a notice will appear in the “Problems” view panel. Or in a spreadsheet, changing a value on one sheet can cause recalculations that affect other related sheets.

Navigation map

You may want to sketch a navigation map to keep track of how users can move from one place to another. For instance, a simple game may have several screens that are accessible from a main menu screen:

Navigation map for a simple game

Navigation maps aren’t relevant or useful for all types of application, however, and there are many cases where drawing a complete map is impractical or impossible. In a wiki application, for instance, users can create new pages and interlink them however they like.

Navigation mechanisms

The following list explains some of the means by which the user might be able to navigate between different places. Most applications will use some combination of several of these.

• Menus: Navigation menus on websites direct users to other pages. Pull-down menus in desktop applications often open pop-up dialogs.

• Hypertext links: On websites, users can navigate to other pages by means of hypertext links.

• Buttons: Clicking or pressing a button or a similar control might cause the application to switch to another place. For example, clicking on a “Next” button will take you to the next step in a wizard. Toolbar buttons often open pop-up dialogs.

• Hierarchical trees: Many applications split the display into two panels; in the left-hand panel, a hierarchical tree control is presented. When an item or object is selected in the tree, the right-hand panel displays the contents of the selected item or object.

Hierarchical tree as a navigation mechanism in ChapterLab

• Map: Some applications might present a clickable or touchable geographical map. PadMapper, for instance, shows apartments listings on a city map; selecting a pinpoint pops up more information on each listing.

PadMapper uses a map as a navigation aid

• Process flow diagram: The main screen in QuickBooks is a diagram depicting the flow of accounting documents and processes. Selecting an icon in the diagram opens a window appropriate to each type of document or process.

Process flow diagram in QuickBooks

• Switching: If multiple places or documents are open at once, the user should be able to switch between them easily and rapidly.

• Task flow: Place changes can be triggered by the completion of a task. For example, upon successful completion of a purchase on an e-commerce site, the user may be taken to page showing an order confirmation.

• Events: An event triggered by the application itself, or by an input from an external system, could cause a pop-up dialog to appear. For instance, a reminder pop-up may appear at a specific time controller by a timer. In a stock trading application, an alert might pop up if a security’s price goes above or below a specified limit.

• Searching: Many applications allow the user to search for a keyword. Selecting a search result then takes the user to the appropriate document or place.

• Bookmarks and flags: Some applications, like web browsers and e-book readers, allow users to bookmark pages or flag specific locations for later access.

• History: Some applications provide a chronological list of recently-accessed places. All web browsers have some form of history list and offer Back and Forward buttons for navigating through the history list. Similarly, most Mac applications offer an “Open Recent” menu option offering quick access to recently-opened files.

“You are here” indication

The more complex the navigation is and the more places there are in your application, the more important it is to clearly show the user where she currently is. Some ways you can indicate the current location are:

• Conspicuously presenting the title of the place
• Highlighting the current location in a visual map or process flow diagram
• Highlighting the current item or object in a hierarchical tree control

For websites that organize content in a hierarchical fashion, the “breadcrumb” technique is simultaneously a location indicator and a means of navigation. As shown in the following example from Amazon.com, the breadcrumb lists the categories in the hierarchy that you would need to navigate through in order to get to the final destination, and each of these categories is a clickable link:

Example of breadcrumb navigation on an e-commerce site

Because usability problems tend to emerge when key issues like navigation, workflow, and transactions haven’t been thought all the way through, it is worthwhile spending time on thinking about these issues and explicitly designing and evaluating solutions.

Not everything can or should be decided at the very beginning; preliminary decisions will often have to be made which can then be changed or refined as the project goes on. However, some fundamental things are very hard to change once product development is in full swing, and so these things — what we might call the architectural design — should receive special attention early on in the project.

It is possible to describe an interaction concept in a formal specification document, and for large teams building large products, this can be a reasonable approach for recording and communicating the design to team members. But creating a formal deliverable is not the point, and nor is it the only way to document and communicate design decisions. Writing a specification is good if it forces the team to think through and decide on key issues, but a formal document can be difficult to write because many things, like the visual design, are very difficult to specify completely and accurately in writing.

A more agile approach that tends to be more successful is prototyping, in combination with some minimal, agile documentation. Prototyping can be a very effective way of trying out different design ideas and getting feedback through peer reviews and usability testing. A prototype alone cannot capture and communicate all of the design decisions and rationale, though, so lightweight written records can be used to supplement it.

What kinds of issues make up the interaction concept?

• A choice of one or more interaction styles
• The basics of the information architecture, which may include:
• Data model
• Behavioral model
• Glossary of preferred names
• Navigation and wayfinding
• Search and indexing
• A framework for interactions and workflow
• A transaction and persistence concept
• A visual design framework (essentially, the product-wide look-and-feel)

We’ll examine each of these in upcoming blog posts.

• Use consistent naming, labelling, icons, and visual presentation to reduce any confusion.
• Try to avoid redundancy so that the same information doesn’t need to be read and processed repeatedly.
• Put related things close together, and avoid forcing the user to switch between different tabs or windows or scroll back and forth to find or enter information.
• Avoid distractions like pop-up dialogs that break the user’s concentration and flow.
• Identify and eliminate any unnecessary steps. You might allow expert users to hide instructions and turn off warning messages.
• If your application has multiple tasks or screens that share similiarities, be consistent in designing the visual appearance and workflow of these tasks and screens, so that once the user has learned how to use one, the same patterns can be applied to the others.
• Automate as much manual work as is reasonably possible. In some cases, though, you may want to allow experts to have the option of doing things manually if they need an extra level of control or precision.
• Where there is a list of steps to be followed, always make it clear how to do the next step. When possible, guide users through tasks with wizard-style interfaces rather than force users to memorize a complex procedure.
• Use visual cues and clues to avoid the need for memorization and recall. Allow options to be selected from menus instead of requiring users to memorize commands.
• Reduce delays and latency as much as possible. Give feedback quickly. If an operation will take a long time, use a progress bar or other indicator to show that the system is busy, and when possible, give an estimate of how much time the remainder of the processing will require.
• Getting started with a blank document can be confusing as users often don’t know where to begin. Where possible, provide templates or “worked examples” so that users can modify an existing document or follow a pattern.
• Avoid forcing the user to memorize data in the short term. For example, I’m aware of one system that required users to make note of a nine-digit customer number, close the window, and then go to another window and re-enter the customer number; this is absurd when the system could remember and fill in this information automatically.

Consistency

One of the major ways that people learn is by discovering patterns. New situations become more manageable when existing pattern knowledge can be applied to understanding how things work. Consistency is the key to helping users recognize and apply patterns.

Things that look similar should do similar things. For example, if we learn that protruding surfaces with labels on them are buttons that can be pressed, then the next time we see a new protruding surface with a label on it, we’ll tend to recognize it as a pressable button.

Likewise, behavior and conventions should be consistent across similar tasks and actions. QuickBooks makes a chime sound whenever a record is successfully saved, and this is consistent, no matter whether you’re editing a invoice, a cheque, or a quote.

Inconsistency causes confusion, because things don’t work the way the user expects them to. Forcing users to memorize exceptions to the rules increases the cognitive burden and causes resentment. Attention to consistency is important for instilling confidence in the product, because it gives the impression that there is a logical, rational, trustworthy designer behind the scenes.

For desktop and mobile applications, you should aim to understand and conform to the user interface guidelines for your operating system or platform. Consistency with these standard conventions reduces the number of new things a user needs to learn.

Visibility

Users discover what functions can be performed by visually inspecting the interface and seeing what controls are available. For tasks that involve a series of steps, having clearly-marked controls in a visible location can help the user figure out what to do next.

The principle of visibility suggests that usability and learnability are improved when the user can easily see what commands and options are available. Controls should be made clearly visible, rather than hidden, and should be placed where users would expect them to be. Placing controls in unexpected, out-of-the-way locations is tantamount to hiding them.

Functionality which does not have a visual representation can be hard to discover and find. For example, keyboard shortcuts save time for expert users, but when a keyboard shortcut is the only way to activate a command, then a new user will have no way of discovering it, except by accident, or by reading the reference documentation.

The principle of visibility should not necessarily be interpreted to mean that every possible function should have a prominent button on the screen — for any complex application, there would be so many buttons that the screen would become crowded and cluttered, and it would be difficult to find the right button. Pull-down menus are an example of a compromise: the commands are visible when the menus are opened, but remain tucked out of sight most of the time. And in a full-featured application, you may want to consider only presenting the commands and controls that are relevant to the user’s present context. In Photoshop, for example, one of the toolbars shows the settings for the current drawing tool and omits any settings that are irrelevant for that tool.

Affordance

An affordance is a visual attribute of an object or a control that gives the user clues as to how the object or control can be used or operated.

The standard example used for explaining affordance is the door handle. A round doorknob invites you to turn the knob. A flat plate invites you to push on the plate to push the door outwards. A graspable handle invites you to pull on the handle to pull the door open towards you.

Applying the concept of affordance to graphical user interfaces, you can use visual cues to make controls look clickable or touchable. One common technique is to make buttons and other controls look “three-dimensional” and raised off the screen by using colors to simulate light and shadows. Dials and sliders can be made to look like real-world controls. Whenever possible, you should use the standard controls (“widgets”) provided by the operating system or platform; this makes the controls easily recognizable because the same controls are used by other applications.

Design conventions are another means of providing affordance cues. For example, underlined blue text is a standard convention for representing a textual link on a webpage. There is nothing inherently obvious about underlined blue text that makes it mean “I’m a clickable link”, but it is a widely-used standard that users have learned.

In desktop systems with pointing devices, another way of showing affordance is to change the shape of the mouse pointer when the mouse pointer is moved over a control. Tooltips, or small pop-up messages that appear when the mouse pointer hovers over a control, can provide some additional assistance.

One particularly challenging thing to show affordances for is indicating that some element can be dragged-and-dropped, or that some element has a context menu available by right-clicking on it.

Mapping

Pressing a button or activating a control generally triggers the system to perform some function. There is a relationship, or mapping, between a control and its effects. You should always aim to make these mappings as clear and explicit as possible. You can do this by using descriptive labels or icons on buttons and menu items, and by using controls consistently (again, similar controls should have similar behavior and effects).

Controls should also be positioned in logical ways that match real-world objects or general conventions. For instance, it’s obvious that a slider control to adjust the left-right balance of stereo speakers should increase the volume of the left speaker when the slider is moved to the left. Or if you have an ordered list or a sequence of steps, these should obviously be positioned in left-to-right or top-to-bottom order.

The flight stick in an aircraft or flight simulator might be considered by some to have a non-conventional mapping. Pulling the stick downwards and towards you causes the aircraft’s nose to point upward, while pushing the stick up and away from you causes the aircraft’s nose to point downward. This is because the position of the flight stick controls the flaps on the wings, and if the flaps are down, this will cause the aircraft to climb. The mapping becomes natural for a trained pilot, but can initially seem backwards to new pilots.

Feedback

If you press a button and nothing seems to happen, you’re left wondering whether the button press actually registered. Should you try again? Or is there a delay between the button press and the expected action?

The principle of feedback suggests that you should give users confirmation that an action has been performed successfully (or unsuccessfully). We might distinguish between two types of feedback:

• Activational feedback is evidence that the control was activated successfully: a button was pressed, a menu option was selected, or a slider was moved to a new position. This evidence could be provided with visual feedback: an on-screen button can be animated to give the appearance of being depressed and released. Physical controls can provide tactile feedback; for instance, you can feel a button clicking as you press and release it. Auditory feedback could also be provided in the form of a sound effect.
• Behavioral feedback is evidence that the activation or adjustment of the control has now had some effect in the system; some action has been performed with some result. For example, in an e-mail client, after clicking the “Send” button, you may get a confirmation message in a pop-up dialog, and the e-mail will be listed under the “Sent” folder.

One business system I’ve encountered offered a menu option for generating a report. When this menu option was selected, nothing appeared to happen. Because no feedback was provided, it was unclear whether the report generation was triggered correctly, and if it was, it was unclear whether the report was generated successfully. It turned out that a report file was created in a certain location in the file system, but the system did not tell the user where to find this file. This system could be improved by giving the user feedback: at the minimum, a confirmation should be provided indicating that the report was created successfully, and better yet, the report should be automatically opened for viewing as soon as it is available.

Constraints

Interfaces must be designed with restrictions so that the system can never enter into an invalid state. Constraints, or restrictions, prevent invalid data from being entered and prevent invalid actions from being performed.

Constraints can take many forms. Here are some examples:

• A diagramming tool for drawing organizational charts will prevent the boxes and lines from being dragged-and-dropped and rearranged into configurations that are not semantically legal.
• Word processors disable the “Copy” and “Cut” commands when no text is currently selected.
• The dots-per-inch setting on a scanning application is often controlled by a slider that restricts the chosen value to be within a range such as 100 to 400 dpi. This is a good example of a control that can show a constraint visually.

The user interface framework will provide user interface controls or “widgets” — buttons, text fields, drop-down boxes, and so on. Knowing what set of controls you have to work with and what they look like is obviously important for design and prototyping. For the purposes of visual design, it is also good to know the degree to which the look-and-feel of the controls can be adjusted and customized, and what mechanisms are used for managing the page layout.

The technology framework that will be used for implementing the user interface can impose constraints on your designs. In particular, different web application frameworks can vary widely in their capabilities. For instance, some frameworks offer the ability to present modal popup dialogs, while others do not; older frameworks may not support partial page refreshes, requiring entire pages to be reloaded to show new data. The Oracle ADF framework, as of the current writing, does not offer any means for disabling or hiding options in pull-down menus.

If the framework chosen for your product has limitations, you will need to be aware of them and find ways to work around them — but these workarounds can often impact usability. If the problems are serious enough, you may need to reconsider the choice of framework, and it’s better to discover and decide this early on in the project, rather than later, after most of the product has already been built. Thus getting a good understanding the framework and its capabilities and limitations is a critical early step in user interface design.

In some projects, UX designers may have some input into which user interface framework will be chosen for the project. But in most projects, technical architects choose the technology stack — the set of frameworks that will be used to develop the software, including the user interface layer — based on technical considerations, cost analyses, political factors, and sometimes, personal preference. The UX designer, who is typically brought in at a later stage in the project, is then left to design interfaces that are implementable with the chosen technology.

The choice of user interface framework should be decided upon careful consideration of the requirements, or at least the best known understanding of the requirements at the early stage of the project, and ideally a user experience designer should be involved in determining those requirements.

It’s usually pretty difficult to talk about something if it doesn’t have a name. In casual in-person conversations, you might be able to point to somebody and say “that guy” to refer to him, but of course this doesn’t work well in a written context (or when “that guy” leaves the room). Things in your application need to be named and labelled so that users can know where they are, what data they’re looking at, and what actions they can perform. Good names and labels help the user form a correct mental model. Clear and consistent naming is also important so that unambiguous instructions can be formulated, like “In the Search dialog, under the ‘Advanced’ tab, uncheck the ‘Case sensitive’ checkbox.”

What kinds of things are typically given names in software applications?

• “Places” such as pages, screens, dialogs, and tabs
• Menus
• Tasks (the names of tasks may not necessarily be exposed to the user in many applications, however)
• Controls such as buttons, icons, checkboxes
• Data elements such as fields and column headings
• Objects, classes, tables, records, files, and other forms of persistent data collections almost always need to be uniquely identified (though not all of these may be exposed to the user), and unique identifiers such as customer IDs or social security numbers could be considered to be names
• Domain-related or interface-specific concepts, constructs, and abstractions, such as “contribution limit” in a pension administration system, or “layer” in Photoshop

Names are used for differentiation between things. If two things are given the same name, then that name is ambiguous because it could refer to either of the two things. Imagine you work in an office where there are two people named John: John Smith and John Thompson. If your boss asks you to “please pass this letter on to John”, then without additional information, you can’t be sure which John your boss is referring to.

In other words, “John” is not a unique name within the context of your office. The name “John” is ambiguous because it could refer to either John Smith or John Thompson. To eliminate the ambiguity, you have to add enough “qualifying” information to uniquely identify the target. So “John Smith” would be ideal, but “John S.” or, say, “John in Accounting” would also suffice in this case.

Ideally, names are unique within the context in which they are used. You may know a Suzanne in your office and a Suzanne at your yoga studio. If someone from the office mentions Suzanne’s name, you’ll probably assume they’re talking about the Suzanne in the office, whereas if someone you know from the yoga studio mentions Suzanne, you’ll probably assume they’re talking about Suzanne from the yoga studio. Because of the two different contexts, you’re usually able to make a reasonable assumption about who is being referred to.

In software development, naming contexts are often called “namespaces”. If you were to make a list of all the names within a namespace, it is best if all the names are unique, because they can then all be differentiated from each other.

Here are additional guidelines and things to keep in mind when you are naming things in your application:

• Does the name accurately describe the target? For instance, a tab named “Address” is accurately named if the tab contains a customer’s address information. But if the tab is then redesigned so that the customer’s phone number and e-mail address are displayed, then “Address” no longer accurately describes the contents of the tab. Perhaps “Contact Details” might now be a more accurate title.

• Does the name unambiguously describe the target? If not, consider a different name or add adjectives to make the name more specific. For example, if you label a field “Profit”, is it clear from the context whether this refers to the gross or net profit?

• Consider whether the level of abstraction is suitable for your audience and context. The name “Universal Serial Bus” is an technically accurate name for hardware designers, but from average consumers don’t know and don’t care about what “serial” and “bus” mean; the context of computer architecture is irrelevant to consumers. “FireWire” is a better name for marketing purposes, because the name does not expose unnecessary technical details (and the rhyming and repetition in the name makes it more memorable).

• Names should be of a reasonable length, as excessively long names are hard to remember and time-consuming to read and write. On the other hand, don’t try to shorten a name to the point where it no longer clearly and uniquely identifies the target. Yes, abbreviating John Smith to JS makes the name shorter, and may be suitable in some particular context, but now JS referring to John Smith is no longer differentiable from, say, Jane Smith or James Schmidt or Jerry Springer (or perhaps even Javascript). Abbreviations and acronyms increase the chances of misinterpretation and so should be used with restraint, except for well-known or domain-specific cases that you’re certain your user audience will understand. For example, VAT for Value-Added Tax is a well-known acronym in the UK, but is unfamiliar (and probably irrelevant) to users in the US.

• Whenever possible, use existing standard terminology. If there are multiple synonymous terms for the same thing, like “Income Statement” and “Profit & Loss Statement” in accounting, choose one as the standard and use it consistently in your application.

• The first letter and first syllable, or the first word in a compound word, are the most strongly memorable and differentiable. Suffixes are the least differentiating and memorable.

The sprawling city of Calgary, Alberta, Canada requires all streets within each demarcated suburban community to have names that begin with the same three letters. The Taradale suburb, for instance, is a maze of streets with names like Taradale Drive, Taradale Close, Tarrington Close, Tararidge Close, Tararidge Crescent, Taracove Road, Taracove Landing, Taracove Crescent, Taralea Park, Taralea Green, Taralea Way, Tarawood Grove, and Tarawood Lane. This can make finding a particular address while driving rather difficult. “Tararidge Crescent” would be a very unique name in a community with street names like “Bay Street”, “MacDonald Avenue”, and so on, but since all the names in the community sound nearly identical, the cognitive load of trying to remember an address and simultaneously compare it against virtually identical alternatives is challenging.

Calgary's Taradale suburb (courtesy of Google Maps; map data copyright 2012 Google)

• Within each naming context, names should be consistent in terms of phrasing and capitalization. If you are choosing names for your tasks, for instance, having both “Add new customer” and “Customer editor” in the same list is awkward. The former with a verb and describes an action, while the other is a noun phrase that describes the “place” (screen, dialog, or page) where actions take place. Using the pair “Add new customer” and “Edit customer” would fix the problem. Likewise, “Add new customer” and “Edit Customer” are inconsistently capitalized. Yes, some people will not notice this sort of thing, but your more literate and attentive users will notice, and this kind of sloppiness does not inspire confidence.

• Human languages tend not to consider numbers to be names, but numbering systems like social security numbers, passport numbers, phone numbers, etc. are essentially a form of naming, as they are intended to uniquely identify something and differentiate specific things from other things within a context.

• For product names, distinctiveness and descriptiveness are important, and of course you’ll want to make sure that the name is available for domain name and trademark registrations. When selling internationally, try to ensure that the name is free of negative connotations in all of your markets. For example, “Siri”, the iPhone feature, sounds like the Japanese word for “buttocks”. And a “Mist” air freshener wouldn’t sell very well in Germany because “Mist” is German for “manure”.

Product names should also be pronounceable: given the name in written form, people should not have to ask, “How do you say that?” And when someone hears the name being spoken, it should be recognizable and the listener should ideally be able to spell it. If you had never heard of YouTube, but somebody said that name to you, would you interpret it as “YouTube” or “UTube”? Intentional spelling and punctuation variations like “Flickr” and “del.icio.us” can be distinctive but have the trade-off that people will be forever misspelling them. Also, be consistent with your branding; is the correct spelling Walmart, Wal-Mart, or WAL*MART? That retailer has itself used all three variations in different contexts.

To give you ideas for structuring your application, the following list gives some examples of major interaction styles. There is much overlap between some of these classifications, and most applications use a combination of these styles. A video editing application, for example, combines aspects of the direct manipulation and control panel styles.

• Command-line: The user controls the system by entering commands or queries in a console.
• Menu-driven: The user controls the system by picking options from menus.
• Conversational: The interaction focuses around a give-and-take between system and user, often with one side asking the other questions. Depending on the sysetm, the user may engage in the conversation using natural language (textual or vocal), a specialized query language (essentially the command-line style), or by picking options from a menu (the menu-driven style). For example, medical expert systems ask a series of questions about a patient’s symptoms, and then suggest a diagnosis. iPhone users can speak questions or commands to Siri and receive responses.
• Form-filling: The interaction revolves around the user entering data into standard forms.
• Direct manipulation: The user manipulates objects on the screen. In Visio or Photoshop, the user draws or edits diagrams or photos by directly drawing and working on a canvas. A word processor lets the user write and manipulate text as if it were on a page. An automobile racing game lets the user steer the car.
• Control panel: The display simulates gauges, buttons, and other controls normally found on a traditionally hardware-based device or control panel, like a industrial process control board, a stereo, or aircraft flight controls.
• Content consumption: The application serves to present content to the user, but the user may have little means of interacting with it, other than navigation. Video players and book readers are examples.

For many applications, the choice of interaction style or styles is self-evident, but thinking through alternative or unconventional styles of presenting functionality can sometimes lead to ideas that differentiate your product from others in the market. Income tax preparation software involves a lot of form-filling, but some packages, like UFile.ca, offer an “interview” mode that collects information by asking a series of questions about your personal situation. While you end up entering the same information as you would with a long form, the conversational approach of the interview is more personal and less overwhelming than being faced with pages of data-entry forms.

Visual attributes are properties of visual elements – the different ways that you can “style” the visual elements on the page.

In designing the visual style for your application or website, you’ll need to decide on a system of arrangement of visual elements, combined with a consistent way to style those elements using visual attributes. Elements with similar function and meaning should usually be styled the same way.

But you can also selectively use attributes to create contrast. Contrast is an intentional difference between two elements. Contrast can be eye-catching, and we can intentionally use contrast to highlight or draw attention to a particular element, or to provide clues that two elements are different in some conceptual way.

Here are some of the main visual attributes you need to be aware of:

Size

The most instantly noticeable visual attribute of all is size. We can’t help but notice when one element is bigger than another, and, all other things being equal, our eyes will almost always look at the biggest thing on a page first. So size can be used to draw attention to something.

For example, book designers have for centuries used “dropcaps” – like in the “E” in the paragraph below – to help direct the eye to the beginning of long blocks of text (which are not always visually exciting):

If an element is bigger than other surrounding elements, the contrast in relative size makes the bigger element visually dominant. We perceive a big, dominant element to be more important than the other elements.

For example, here, despite not being able to see the contents of the panels, we would generally assume that the big center panel is the most important on the basis of its size:

The relative size of elements can be used to communicate the intended relative importance of those elements – for example, you might expect that certain features will be used more frequently, so you might make the buttons for those features larger than the buttons for lesser-used features.

Users may also have their own expectations for what is important and not, and they could be annoyed if seemingly irrelevant things are taking up too much screen real estate.

For example, a time-and-date clock in the corner of an accounting program should be small because, while convenient, it has little to do with the main task of the application. However, in a “chyron” system for overlaying graphics onto live television broadcasts, a time clock with millisecond precision is pretty important for synchronization, and so making it quite large and prominent would be justifiable and expected.

Size contrasts can also be used as a highlighting technique. For example, in this particular view of the Mac OS dock, the currently selected item is biggest:

Color

After size, color is generally regarded as the next most immediately noticeable attribute. Colors, if applied carefully, can be used to attract attention and guide the eye. Color can also work very well for suggesting importance: brighter, more intense colors tend to suggest more importance and urgency than duller, muted colors.

Color can also be used to suggest similarities and differences. Elements sharing identical colors are perceived as belonging to the same group, whereas elements with contrasting colors are perceived as belonging to different groups.

Colors can also have implied, culture-dependent meanings, like red indicating “danger” or “stop”, or green meaning “OK” or “go”.

(Color is an important and complicated topic that we’ll explore in more detail in future blog posts.)

Shape

We can perceive and differentiate the outlines of shapes very easily: we can quite rapidly tell the difference between squares, circles, and triangles.

You can draw attention to one object if it has a different outline shape than the objects surrounding it – for example, a round or a pointy angular shape in a sea of boxes.

As shown in a previous post, the icons in the following Mac Finder window all have the same general outline shape, so it takes a bit of effort to tell the difference between them:

Direction, angularity

Elements like text, lines, or graphics that are set at an angle can be quite eye-catching. The angles create “tension” by breaking the traditional rules of grid alignment.

Traditional design wisdom says that angular elements are perceived as being unconventional and “edgy”, so conservative, respectable business applications like banking websites might want to avoid them, while they might add dynamism to entertainment or game applications.

Weight

Weight refers to the thickness of lines:

When applied to text, weight refers to the thickness of the lines of the letterforms. Bold text has a heavier weight – more “heft” – than regular text.

Many typefaces are available in families, where the letterforms have the same basic shapes but have different weights. Most famous is Helvetica:

The contrast and similarity of two words, set side-by-side, using the same font but with different weights, can create a really awesome look – though some would argue it’s an over-used design cliché:

Text styling/decoration

Apart from size and weight, further attributes for styling text are decorations like italics and underlining.

Additionally, contrast can be created by intentionally pairing typefaces from different categories – for example, pairing a sans-serif font for headings with a serif font for the body text. We’ll talk more about this when we cover typography in a future blog post.

Texture

Texture can refer to giving visual elements the appearance of surfaces that, if they were actually touchable, might feel rough, or smooth, or concave or convex, etc. Panels and buttons might look like they’re made of shiny brushed metal, or illuminated plastic, or semi-transparent glass; websites might use decorative backgrounds that look like paper or wood. The so-called “Web 2.0” look relies a lot on illumination, reflections, gradients, and shading effects to create a more sophisticated, “photorealistic” texture that stands out more than simple blocks of plain colors.

In the following illustration, on the left, buttons from Mac OS and Windows 7 are shown; these look like raised, convex, clear plastic buttons that look very pressable. In the center, a scrollbar from Java Swing’s (old) Metal look-and-feel has a nice grippy tactile texture that makes you want to touch it and drag it up and down. On the right is an example of a novelty background texture for websites (courtesy of www.allfreebackgrounds.com).

Giving some thought to creating texture can give your user interface some eye-catching “pop” and a unique look-and-feel, but for business applications, you probably don’t want to get too carried away with overly distracting decorations; it’s best to stick to more conservative styling. Novelty textures, like UI components appearing to be carved out of wood or stone, might help give an immersive ambiance to a game, however.

Note that graphic designers also use the word texture to refer to the overall visual effect of a block of text. If you look at a block of text and squint or defocus your eyes until you can no longer distinguish the actual words, you can sort of see a “texture” emerge. Or, if you were to imagine that the text were raised off the page, and you could close your eyes and rub your fingertip over it, then a block of text set in Times New Roman (upper left) would probably feel different to the touch than a block set in Helvetica (upper right), or Times New Roman Italic (lower left), or Gill Sans Regular (lower right).

Surrounding space

Humans place value on space, and so things that take up more space than necessary tend to be perceived as important and valuable.

If an element is in a region that’s tightly-packed with other elements, it will not stand out. But if that element is surrounded by generous whitespace, we’ll tend to believe it must be either special or valuable to deserve all that space.

Summary

We’ve examined the most important visual attributes and we’ve seen some basic examples of how the careful, intentional use of visual attributes can create contrast and attract interest. Upcoming blog posts will continue our exploration of graphic design for user interfaces, so stay tuned!

[ad#AdSense_MedRect]