September 2009

Volume 24 Number 09

Usability in Practice - The Tao of Screen Design

By Dr. Charlie Kreitzberg, Ambrose Little | September 2009

The Cognitive View

As a developer, you are deeply immersed in the implementation model, but when you shift to designing the UI, you need to shift your perspective to see the software the way the user does. That’s not easy to do because it’s difficult to ignore what you know and adopt another person’s view. Many of the design techniques that we’ve discussed in previous columns, such as creating personas to represent typical audience members and constructing task scenarios to understand how users work, are intended to help you make that mental shift. You need a clear understanding of your audience, the tasks they need to accomplish, and how they think about their activity. It’s also important to recognize the level of technical understanding you can expect from the audience. With this knowledge, you can develop a manifest model that fits.

Figure 1 The Yin-Yang Symbol

First Create the Framework

We have previously written about the distinction between high-level and detailed design. Screen design should always start with the design of a high-level framework. Once that framework is in place you can use it as the basis for detailed screens. Two key elements of the framework are the following:

• A navigational scheme that allows the user to move easily from screen to screen in accord with the task flow. We discussed navigation in our March 2009 column (msdn.microsoft.com/en-us/magazine/dd458810.aspx).
• Persistent elements, such as headings, that serve to anchor the user and provide clues about where the user is.

In other words, start with a top-down approach through which you define the elements that are common to all screens and create a clear model of how the user gets around.  

With the framework in place, develop the most important screens, refining the framework if needed. Finally, develop the remaining screens and dialog boxes.

Create Wireframe Templates

The framework, which you might implement as master pages, should indicate the main areas for the screens. Some of the information in these areas will be the same on every screen (for example, the product name, logo, and the main menu). Some information will change from screen to screen but should appear in the same place on each screen (for example, the screen title and breadcrumbs). Finally, some information will be different from screen to screen (for example, the controls specific to the screen). All these elements, however, should work together to create a consistent and seamless design.

Start by dividing the screen into areas based on function. As an example, look at the wireframe in Figure 2, which serves to map out the basic screen areas. Note how every area in this wireframe has been labeled so that the user will understand its purpose.

Figure 2 Defining the Screen Areas

The overall design is easy for the user to organize perceptually. Each of the main tabs could have a somewhat different design, but as long as the basic layout doesn’t shift, the design will appear consistent to the user. To illustrate this, look at Figure 3, which shows another template that could be used for a different tab in the application. Because the basic framing elements are kept constant, the usability is preserved even though key elements of the design are different.

Figure 3 A Compatible Template

Of course, the design patterns you select for each screen should be consistent. For example, if two tabs each have a search function, they should present that feature in the same way.

All but the simplest systems need to deal with dialog boxes and other secondary screens. In the past, because of the limitations of browsers, a lot of Web-based systems avoided child windows and layers. A common alternative was to send the user to another page, and the user had to figure out how to get back. Often, this resulted in confusion.

With platforms like the Microsoft .NET Framework, its associated programming languages, and AJAX, creating pop-ups and other elegant ways to manage details is much more realistic. When you are creating a framework, think about how you will handle dialog boxes and details. For example, the templates in Figures 2 and 3 would work well with a modal pop-up child window, as shown in Figure 4.

During the creation of the framework, you should also think about user support and help. Help is often an afterthought, created as a “bolt-on,” but it works far better when it is integrated into the screens. Note that in the pop-up shown in Figure 4, we’ve reserved a place for explanatory text that can serve as a prompt to orient the user. The Learn More link enables the user to access additional information. (Of course, you need to design a template to show how that link will be processed.)

Figure 4 Pop-up

To help the user fill in the form, you might also want to create a tooltip to enable the user to get additional information about specific fields. A sample design for this is shown in Figure 5.

Figure 5 Tooltips

By thinking about user-support design at the very beginning, you take a large step toward ensuring that it will actually be created and will be useful and consistent. Note that the tooltip, like the prompt, has a link to enable the user to learn more. While this is not a common practice (and cannot be implemented in some tooltip controls), it is a powerful technique because it allows users to delve deeper while staying within the context of their current activity. You might want to create a template for yet another level of pop-up to support these links to avoid extra navigation.

In my experience, a few basic templates, with perhaps two levels of dialogs, can accommodate the UI for even very large systems. And by specifying the framework up front, you create the scaffolding for designing specific screens.

Create a Style Guide

As you create the framework, document it in a style guide. This will remind you of the choices you made and also enable others who need to develop screens to remain consistent with the design. A style guide need not be fancy. Typically, I capture the screen templates, annotate them, and paste the annotated screens into Word, Visio, or a Web site.  Figure 6 is an example of how you might annotate the pop-up wireframe.

Figure 6 Annotated Wireframe for Style Guide

It is important to specify fonts, font sizes, and colors so that they can be consistent from screen to screen. Whenever possible, use styles rather than hard-coded values for fonts and colors so that you (or a graphic artist) can make changes to the visual design and still maintain consistency across the application.

The style guide can also specify the terminology to be used in the UI. It is important to use terms consistently and to select terms that make sense to your audience.

Agile

As we’ve discussed in previous columns, refactoring the UI can lead to confusion. For this reason, it’s usually best to come up with a comprehensive and flexible framework first and then elaborate it throughout the development cycle. You might find, for example, that you need an additional template or that you need to come up with additional design rules. You can certainly amend the style guide as UI development progresses, as long as you are refining the original design. If you find that the original design needs to be rethought, you should go back and review all screens for consistency and consider the impact of changes on users if the software is already deployed.

Usability Test

Once you have created your framework, test its usability if possible so that you can make certain that the design works as you intended. It is easier to make changes to the template and the style guide before a lot of screens are coded.

Creating Detail Screens

With the framework and style guide in place, you can create the screens. If you’ve developed a good style guide, you can distribute the work among several developers and still maintain the  consistency you want.

The work of designing individual screens is a combination of art and engineering. To create a screen design that works for the user, you need to place yourself in the user’s shoes and see the world the way the user does. That’s not an easy task and is one of the reasons that usability testing can be so powerful as a tool.

Cognitive Model

As a starting point, look at Figure 7, which shows a simplified cognitive model of how a user processes a screen.

Figure 7 Cognitive Model for Screen Processing

The user typically starts off the session with a major goal in mind. For example, “I want to select my corporate benefits” or “I want to solve this customer’s problem.” Then, as the user confronts each screen, she creates smaller, screen-level goals, like “I want to log on” or “I want to  locate the customer’s record.”

With goals like these in mind, the user views the screen and decides what action to take. She executes the action and observes the results. Based on those results, the user creates a new goal and repeats the process again.

This process can easily go astray if the user does not recognize the appropriate control on the screen. This situation can occur if the designer assumes that the user “remembers” where to go and does not create a visible prompt for it. An example might be a product in which a user needs to press F1 for help, but a prompt to that effect is not present. Another example is when a user needs to return to a specific screen to locate a function but does not remember where to find the  function. In either case, the result is usually frantic searching and frustration.

This leads to a key screen-design rule: never rely on the user’s memory; instead, try making every option visible. While over time, the user will learn the system, any reliance on memory just adds to cognitive load and, hence, to effort. Remember that cognitively, recognition is always far easier than recall. When you have a large number of options, you may need to make the selection a multistep process. In those cases, make it as easy as possible for the user to locate the element he needs as quickly and easily as possible, and always with minimal cognitive load.

Because developers are concerned with efficiency, they might feel that it is wasteful and sloppy to repeat information that is already presented elsewhere. But since recognition always trumps recall, you are better off presenting things multiple times than assuming that the user will remember something if it’s not in front of them. And since users rarely develop accurate mental models of the navigational flow—at least not until they have had a lot of exposure to the product—relying on them to recall that the  function they need is under a specific tab adds a lot of cognitive load to the process.

Layout

Last month we talked about information architecture and how to design the presentation of information for easy comprehension. Keep those ideas in mind when you lay out individual screens. Make certain that the screen is orderly and clutter free. You want users to perceptually group items that work together into visual units. Look at Figure 8 to see how disorderly alignment can make it really hard for the eye to group related items together. By lining up the items and placing the buttons in close proximity to the elements they control, the perceptual groups are easily formed.

Figure 8 Grouping Makes the Screen More Comprehensible

Internal Consistency

Unless you have a really good reason not to, try to be as consistent as possible from screen to screen. For example, here are some general guidelines:

• Use the same terminology throughout the system
• Organize information consistently using the same form of headings and information presentation
• Use the same techniques for search queries and results

Flow

When there is an order to the way that you want a user to scan the screen, you are usually best following the flow for the user’s native language. In English and many other languages, this suggests left to right and top to bottom. Look at Figure 9 to see how much easier it is to read the letters in alphabetical sequence when they conform to language flow.

Figure 9 Flow

If your audience’s language is Hebrew, Arabic, Persian, Chinese, or Japanese, the flow may be from right to left, so your screens should be adjusted accordingly. Flow is not a concern on every screen. Flow is not always related to text. So, for example, if you want to represent a process with multiple steps, arranging the flow is important, even if the objects on the screen are graphical. Take a look at the “washing a T-shirt” example at i18nguy.com/MiddleEastUI.html.

And Then the Magic Happens

Many designers (including myself) find that they have an emotional response to good screen design. You know when a design is right because things seem to fall into place. The approach makes sense as you look at it from different perspectives. Among ourselves we would characterize that emotional feeling as “and then the magic happens,” and we despair of being able to explain to clients why this particular design is the right one.

As a developer, you have probably experienced similar “Aha” moments when you solved a particularly knotty technical design problem. When you can get to the same point in screen design, you will be able to feel confident about the rightness of your design decisions, and rarely will usability testing prove you wrong.

Study the Tao of screen design and understand that you need to create two complementary views of the product – one technical and one user centered. When you can switch from one view to the other comfortably, you will have mastered a difficult but worthwhile skill.

The Software View

Amborse Little

Screen design is, I think, one of those things that is so concrete and practical that most of us just get it.  That has the unfortunate consequence of making us complacent: we not think enough about it or just presume that we know it—we’re experts because we design screens. As the other installments of this column have shown, there is indeed both a distinct science and an art to making software interfaces. The average developer can get only so far, depending on his innate talent and empathy, in making interfaces that foster good experiences.  On the flip side, I hope this column also shows that even if UI design is not your primary expertise, you can get better at it and also get better at deciding when you need to engage professionals in the field.

I say all this by way of noting that our UI technologies seem to have long recognized the need for design frameworks.  I dare say that the existence of such platforms has been driven more by a need for us developers to retain our sanity and some modicum of ongoing productivity in the face of changing requirements than by any conscious recognition of the importance of consistency for those we lovingly refer to as users.  So it is serendipitous that we have what we have.

And just what is it that we have?  Well, that obviously depends on what technology you work with, but I’ll try to stay focused on the main .NET UI technologies, given that this is, after all, MSDN Magazine. 

Stuff You Get in Them All

First off, let me say that all the .NET technologies have one shared, concrete concept of essential UI reuse—the control (and its derivative, the so-called user control).  These, as I’m sure most of us know, let you bundle up parts of the UI for not just visual but also functional reuse.  I’m not a technology historian, but my impression is that controls are generally meant for solutions that cross problem domains (often manifested in their own external project or assembly, or even supplied by third parties), and for these solutions, controls are typically implemented in very broadly applicable patterns. User controls, on the other hand, are typically oriented toward particular problem domains, often within the same project solution.

Both controls and user controls are good for code and UI reuse, which is well known, but they get you only so far in terms of a design framework.  For that, you need something more akin to what is often called a “master” or “template” framework to handle gross layout and hierarchically shared elements, as well as a way to manage consistent styling (meaning fonts, colors, spacing, and other visual treatments that serve both aesthetics and information design).  For these, the solutions vary across technology.

Windows Forms

Many moons ago, my fearless Floridian friend, Stan Schultes, penned an article in Visual Studio Magazine called “Understand Visual Inheritance” (msdn.microsoft.com/en-us/library/aa288147(VS.71).aspx) .  The approach outlined in this article can help largely with the gross, shared layout needs—in other words, you can make a base Form and a base Dialog and build out from those to meet most of your needs.     

Left to its own devices, I’m afraid that’s about all you’ll get out of Windows Forms in helping you implement a design framework.  That said, there are third-party solutions, such as Infragistics’s Application Styling Framework and tool ( infragistics.com/learn/applicationstyling.aspx ), that offer more consistency and agility and can help fill the gap where Windows Forms leaves off in helping you implement and manage a consistent design framework.

You might be thinking about the Composite UI Application Block (also known as CAB; see  msdn.microsoft.com/en-us/library/aa480450.aspx), and although CAB is intended more for modularizing and decoupling UI than it is for implementing a consistent design framework, you could define the shell UI (using one or more of the Workspaces) to make a sort of master layout to provide that level of design framework implementation.  You’re still left needing to ensure that the particular modules form a harmonious whole, however, and given the modularity that CAB provides, this means more responsibility on module developers to follow your design framework guidelines. And if you’re going to implement an application using CAB, you should look into the Smart Client Software Factory (SCSF). (See msdn.microsoft.com/en-us/library/bb266334.aspx for some good guidance on the two together.)

ASP.NET

ASP.NET, being a Web technology, can leverage the standard Web technologies that help with design frameworks.  Chiefly, this means CSS and, in more recent years, the popular shared CSS frameworks (bing.com/search?q=css+frameworks ).  If you’re careful and a CSS Zen master, you can sort of get away with nearly complete control of page layout, but more likely you’ll have some interplay between HTML structure and CSS.  CSS is most useful for more granular design details, such as spacing (margins, padding, line spacing, and so on), fonts, colors, and, of course, visual treatments that involve things like borders and various image-based gymnastics. 

As a complement (or a contradiction, depending on who you ask) to out-of-the-box styling, ASP.NET supports themes and control skinning to help you get that extra bit of organization and potential maintainability out of your app.  Infragistics also offers Application Styling for ASP.NET, which makes managing the styling for your app easier, especially if you’re using Infragistics ASP.NET controls.  CSS and HTML are very powerful, but they can also become unmanageable, and both the Infragistics products and the built-in ASP.NET themes and skinning, as well as other frameworks, try to help you manage that complexity and keep your sanity.

For the purposes of shared gross layout and elements, ASP.NET has master pages ( msdn.microsoft.com/en-us/library/wtxbf3hh.aspx ), which let you define common parent/master layout and elements using content placeholders for the areas of the layout that can vary based on particular views.  Master pages  can be nested, and you can have multiple masters (for example, one for Corporate, one for MyApp, and even one for MyAppDialog—that sort of thing).  It’s really a rather good and ingenious framework for supporting and simplifying the implementation and maintenance of a design framework, and yes, for MVC lovers, you can use master pages there as well. (See msdn.microsoft.com/en-us/library/dd381412.aspx as a starting point.)

One other note on ASP.NET.  You can also leverage ASP.NET AJAX (and other AJAX technologies) to essentially maintain an outer, common layout and just update and replace content areas.  ASP.NET AJAX is another tool that can be used in conjunction with master pages to give you the benefits of AJAX while leveraging the benefits of CSS and master pages for a consistent design framework.

SharePoint and Other Content Management Systems

Lastly, as pertains mostly to ASP.NET, SharePoint and other content management systems typically go beyond the basics of what you get in the ASP.NET framework to provide page templates, content types, and similar functionality that can further help you establish and maintain a consistent design framework, even enabling nondevelopers to, in a sense, extend the system while keeping the same design framework intact.

WPF

WPF (Windows Presentation Foundation) has basically two layers of styling—styles and templates*.* (See msdn.microsoft.com/en-us/library/ms745683.aspx. ) Styles are essentially a way to group together a shared set of property values.  Templates come in two basic types in WPF—data templates and control templates.  Control templates are a way to completely customize the look and feel of controls, including their essential structure and behavior.  Control templates are often used together (for example, you can set a Template property in a style for a control) to customize the experience to a degree not really feasible in earlier .NET UI technologies. Data templates are a very nifty way to share a common UI definition for a shape of data, by which I mean that a data template cares only about finding matching bindings and not, for example, that the data source is of a particular type.

As for gross layout and shared elements, because WPF is an inherently client-side technology, it’s a more or less simple matter of creating a view (a Window), laying it out, and substituting the contents of placeholders at run time (often with UserControl instances).  WPF also supports an implementation of the Journal Navigation pattern (see quince.infragistics.com/#/Main/ViewPattern$pattern=Journal+Navigation ) and lets you use Frames with it to mimic the Web experience of navigating to different pages.  This can be an effective way to implement the placeholder approach. (You’ll find more information at msdn.microsoft.com/en-us/library/ms750478.aspx ).

WPF (and Silverlight) also have a CAB-like framework called Composite Application Guidance (CAG, formerly known as Prism; see msdn.microsoft.com/en-us/library/cc707819.aspx) that you can leverage in a similar way as described earlier for Windows Forms.  CAG supports the idea of Regions, which can be used as containers or placeholders within a larger layout, and which can be nested as well. And if you’re working in Blend (inevitable, at this time), you can find a good bit of guidance on organizing stuff to make Blend and Prism work well together at https://www.johnpapa.net/using-blend-with-prism-apps-in-silverlight-3/.

Using a combination of styles, templates, main views with placeholders, and user controls (or Frame controls with pages), you can implement a very manageable design framework in WPF.

Silverlight

Because Silverlight is for all intents and purposes a subset of WPF, and it is a stated goal of Microsoft to try for 100 percent source (XAML) compatibility between Silverlight and WPF, most of what I said about WPF applies to Silverlight, with some exceptions, of course.

First off, there is no formal concept of a Page in core Silverlight—basically, everything is a Control or a UserControl.  In version 3, Microsoft added a navigation framework, which adds a Frame class for hosting “pages” and a Page class that derives from UserControl, and a Title property that will automatically update the browser title bar.  These are an implementation of Journal Navigation so that you can mimic the Web approach (similar to WPF, but as of this writing the implementation is not source compatible—see msdn.microsoft.com/en-us/library/cc838245(VS.95).aspx) .  Instead of navigating to pages, you navigate to user controls that are impersonating pages.  But the core concept of defining shared gross layout and elements with placeholders remains. And, as with WPF, you can manually manage the replacement of visual elements in particular areas (placeholders) of the UI with new ones—usually user controls.

As for styling and templating, it is pretty much the same story, with the caveat that Silverlight provides  a VisualStateManager that allows for control (or user control) developers to define semantic states and state groups.  In the context of our discussion here, this chiefly means that the VSM impacts the way you customize control templates.  VisualStateManager for WPF is in the Toolkit right now; see windowsclient.net/wpf/wpf35/wpf-35sp1-toolkit-visual-state-manager-overview.aspx .

Also, because Silverlight is not an all-or-nothing choice, you can use it in conjunction with ASP.NET and use the ASP.NET means for an overarching design framework. You just have to manage the integration of styling between the standard Web (CSS+HTML) technologies with the styling in Silverlight.  So keep this in mind if you go that route.

You can find more information about the differences between WPF and Silverlight at msdn.microsoft.com/en-us/library/cc903925(VS.95).aspx .

SketchFlow

SketchFlow has just been released as of this writing.  While SketchFlow supports WPF and Silverlight (although a SketchFlow project targets a single technology), it has some of its own ideas about design framework management.  And since many developers will use it to prototype for these .NET technologies, I thought it worth mentioning.  Although SketchFlow sits atop these two technologies, it has some different terminology, namely Screens and Component Screens.

A Screen is basically what it sounds like—a screen that people navigate to. (You can create visual navigation connections between screens in the SketchFlow Map.)  What this usually means is that a Screen has enough distinct UI to warrant its own life and layout.  Component Screens are essentially an easy way to share bits of a screen with other screens, very similar to user controls. (In fact, a Component Screen will create UserControls in code).

While part of the point of prototyping, especially early prototyping, is to not over think stuff like design frameworks, there is a point at which you may want to do this.  If you get much beyond prototyping a page or two and expect to further iterate and refine, you need to start thinking about how to share the common bits to make your prototype more manageable.  That said, even though there is a story to carry forward from SketchFlow prototype to final implementation, that’s not the main point of SketchFlow. 

Your thinking about a detailed implementation design framework can probably wait until you decide to start building, at which point you can leverage some or many of the component screens and even some of the styles, states (in the visual state manager), and related storyboards if you or your designers go to the trouble of defining them in any detail.

Using Common Controls

In addition to frameworks and tools that help you implement a consistent design framework within and across your applications, you should also think about design framework consistency in terms of how your solutions map to other design frameworks. This is where UI patterns can help you choose and implement the best, most common ways of solving related problems.

Again, it seems that developers unconsciously (or not) have done this all along by trying to mimic common solutions that end users are familiar with (like Excel and Outlook) and, of course, by using the controls that come in the box.  Many of us don’t think about it, but something can be said for the consistency provided by a limited control set. We don’t need to worry too much about how to implement, say, a Drop Down Chooser (see (quince.infragistics.com/#/Main/ViewPattern$pattern=Drop+Down+Chooser) because we have that in the box. Similarly, for more complex but familiar interfaces that are not in core framework libraries, we can take advantage of the work that third parties do to provide good implementations for items like the OutlookBar, the Ribbon, and so on.

You can think of these common controls as a kind of shared, universal design framework within which most (business) applications are built, and you should take advantage of the shared design framework to leverage this familiarity.  Some have said that what is intuitive is often simply just what is familiar (see, for example, portal.acm.org/citation.cfm?id=584629), so using familiar UI controls can go a long way toward helping your interfaces seem intuitive.

At the same time, keep in mind that you still need to choose controls based on the needs of your application and not apply unthinkingly a familiar control just because it is familiar or because, for example, it is used in Microsoft Office.  It may go without saying, but in the rush to get things done, I think we’ve all misused controls like this.

One thing that can help you make such judgment calls more quickly is a good UI and UX pattern library like Quince (quince.infragistics.com). Read the Problem, Solution, Context, and Rationale for the patterns—they’re usually fairly short and can do a lot to help you discern whether a particular pattern (which is often implemented as a control) is right for your context. Many alternatives are offered, and you can use the tagging to explore other possible alternatives.

Wrapping Up

Now that you’ve had this whirlwind tour of enabling .NET capabilities in the various .NET UI technologies, you should be able to apply and leverage your (or your designer’s) efforts to define a consistent framework and make it something that is manageable enough to enable you to refine it during development and continue to iterate and refine it as you maintain the application in production.