Skip navigation

Design Your User Interfaces—Don't Just Decorate Them

Take on the challenge of multiple, parallel prototypes

Widows Presentation Foundation (WPF) was released more than three years ago, and Silverlight is up to version 4. Both applications allow you to create compelling user interfaces that make users happier and more productive. Unfortunately, examples of such user interfaces are few. Instead, most Silverlight and WPF efforts merely recapitulate interface designs from earlier technologies.

Such interfaces often have pretty colors, and sometime gratuitous animations. I often say that such user interfaces are not designed; they are merely decorated. I believe this problem results in large part from obsolete ideas about prototyping. For most development teams, prototyping means creating one prototype, which is then refined in cycles of user feedback.

A single prototype might be adequate for mature UI technologies that have limited flexibility. User interface stacks with more flexibility require a different approach. One technique that does a better job of exploring the possible interaction patterns available is the creation of multiple, parallel prototypes. Briefly, the process looks like this:

  1. Create a prototype that you think addresses the users’ needs
  2. Without showing it to users, pretend you cannot use it and put it aside
  3. Create another prototype with a completely different interaction pattern for the user
  4. Repeat steps 2 and 3 until you have several prototypes; a typical team should be able to come up with about four
  5. Now show the varying results to users, and let them guide you to the one that fits their needs most effectively


Unfortunately, many developers just starting with XAML user interfaces learn only enough to spoof the same kind of UI they've always done. This is understandable. First, the surface area of the API is quite large. Second, many of the concepts exposed by the API, such as animation and rich color, are new to developers and are not part of the typical developer’s code-centric skill set.

Using XAML technologies effectively requires effort and dedication. In fact, it’s not an exaggeration to say it requires an entirely new mindset about UI design. Making such a transition includes many ingredients. Looking at good samples (and bad ones), reading design books, and learning more about how the human brain works are all helpful. A sidebar to this article contains a list of suggested resources you might want to try.

A multiple, parallel prototyping process encourages such exploration. Besides giving a better end result, I think it’s a good exercise. The challenge will further your development into new UI design territories.

A Case Study

Let’s look at a multiple-prototype process for a real-world project. You can see the example application by watching episode #115 of the Internet video show .NET Rocks TV ( This episode was made more than two years ago, but surprisingly, it’s still considered to be one of the better examples of effective UI in WPF.

The scenario is temporary staffing management. The application is used by salespeople and other personnel in temporary staffing firms to match people desiring temporary work with companies needing temporary workers. This is squarely in the territory of typical, data-oriented business applications. Major data entities include employees, customers, orders, skills, and so forth.

However, the application addresses a few interesting needs not met by routine business applications. For example, it contains an interaction pattern for suspending data screens in any state when a user is interrupted and must move to a different screen. This was needed because the typical salesperson in a temporary staffing firm is subject to frequent interruptions. It’s a challenge to handle this use case with traditional UI stacks, but the flexibility of WPF and Silverlight offer multiple ways to accommodate the user.

Figure 1 includes three sample screens from the finished application. They don't communicate the interactivity, but they do show some of the aspects possible with XAML-based technology.

Next, let’s look at the prototyping process that yielded this result. First, a prototype was created to help the application's sponsor decide if XAML-based technologies offered enough benefit to accept the risk and potential extra development time required\\[1\\]. Figure 2 shows two screen shots of this prototype.

The prototype looks rather primitive compared to the end result, doesn’t it? However, it taught us a lot. We learned to emphasize non-rectangular screen constructs, and to format lists with data templates in ways that made the most important information accessible and helpful to users.

Then we tried different approaches for user interaction. Figure 3 shows screen shots of three different ways to manage records associated with main entities such as employees. A fourth alternative was the one we used, shown earlier as the first screen in Figure 1.

Each of these four approaches has interesting characteristics. We placed all of them in front of a group of users. There were plenty of differing opinions, but in the end the "home screen" option won, and worked out well as an overall interaction pattern.

We learned some major lessons during this design and prototyping process. Your mileage may vary because your circumstances might be different. However, here are significant lessons as we see them:

1. Multiple, parallel prototypes lead to a better overall design at no sacrifice in time.

The prototyping stage was less than five weeks. Had it not been the first serious WPF project undertaken by the team, it would have been even shorter. After becoming experienced XAML developers, we can now usually create an informal prototype in a couple of days, using mostly the Expression Blend tool with a bit of hacked out code at key points.

This compares favorably with prototyping cycles that center on a single prototype. This is particularly true if the original prototype starts off in the wrong direction, and requires several iterations to get back on course. Multiple prototypes dramatically reduce that risk.

Sometimes users prefer a result that includes design features from more than one of the prototypes. Though one overall pattern usually works best, others might contain desirable features that can be transplanted into the favored one.

2. It helps to understand how human brains are wired

When using animation, it’s a lot easier to reach the correct degree of subtlety if you understand why animation is helpful. It’s very easy to overdo animation, and this usually comes from a mistaken understanding that an animation is supposed to draw attention to something. That’s incorrect. Sometimes a well-done animation isn’t even noticeable. Animation is important because human brains aren't wired for a world in which objects disappear in one location and appear in another, or suddenly blink out of existence entirely.

However, such rapid appearances and disappearances are common in most user interfaces, and they convey a sense of unnaturalness that is detected by users on a subconscious level. This raises stress, even if the user is unaware of it. We had an excuse when our UI stacks didn’t allow us to do any better. Now we need to keep brain wiring in mind, and use animation to fade things out or move them around the screen.

Another similar area is gradient colors. If you watched the video of our application, you saw the attachable notes. Right after a demonstration, I often minimize the application and then ask the audience about the color they recall for the notes. Invariably, the answer is “yellow.” However, the notes are not solid yellow; they’re a gradient fill of yellowish shades that gives the note a natural, and slightly 3D appearance.

Well done gradients, like well done animations, are barely noticeable. However, their impact on the natural feel shouldn't be underestimated. The real world isn’t made up of monochrome colors. Even a wall that’s all the same color will seem to have a gradient because of variable lighting.

Users like interfaces that use gradients and animation to enhance naturalness. They often can’t verbalize why they like them. The reasons may be subconscious. That doesn’t make them less real.

3. Data templates are your friend.

A goal in user interface design is to present the user with exactly the information needed at any point. This is much easier in XAML-based technologies. Items in lists can be laid out with precisely the information desired, using data templates. You can even create multiple templates for different circumstances or to give the user a choice.

I sometimes see XAML-based applications with lots of plain data grids, instead of templated lists. That’s the lazy way to do UI design. The underlying message is “I don’t have the patience or desire to figure out how the user needs to see this data, so I’ll just dump it in a grid and let them figure it out.”

4. Expect failed experiments.

If you create four prototypes, you’re going to throw three of them away. Those rejected alternatives will contain interesting ideas. In some cases, they might contain ideas to which you're particularly attached. However, you have to let go of ideas that don’t make the final cut. The users are the guiding authority as to what works and what does not.

5. Get your interaction pattern right early; worry about styling and detailed layout later

In XAML-based technologies, changing colors and templates is easy, and such restyling of the application can be done very late in the development process. In fact, it’s not hard to make styles dynamic and loaded at runtime.

By contrast, the interaction pattern is typically baked into code. It’s possible to make some interaction patterns pluggable, and I think it’s a good idea; but in practice I rarely see it done. Therefore, it’s important to settle on an interaction pattern rather early in development. Much of your prototyping will be aimed at finding the right pattern. Your main interaction pattern is usually implemented in an outer container for the application. I call it a navigation shell.

Coding patterns can be helpful for creating your navigation shell. A popular pattern is the Model-View-ViewModel pattern, usually called MVVM. Several pre-written implementations of this model are available. However, it’s not the only way to go, and if you try MVVM and it doesn’t seem to be a fit for your application, don’t force it in.

Also, starting with a sample MVVM implementation does not relieve you of designing a good user interaction pattern for you users. Such implementations may have default interaction patterns, but you need to experiment and derive one that works well for your users.

6. Collaboration is key.

Doing multiple prototypes requires lots of ideas and experiments. A team is usually far more effective at producing lots of ideas than a single person working alone. Having a design professional on the team is very helpful because a good one can help generate good ideas and supply guidance on usage of animation and color. However, I don’t believe it’s a good idea to delegate the design to such a person.

Unfortunately, one of the earliest recommendations out of Microsoft was to do exactly that. I recommend against it. I believe a designer working in collaboration with developers who have deeper domain knowledge will typically achieve far better results.

7. Don't use a prototype as the starting point for your production work.

This should be obvious, but all too often it’s not. Don’t think you’ll save time by re-using the prototype for production. It may save a small amount of time (a few hours) when you first begin, but it’s virtually certain that you'll later give back that time and more, fixing the inadequacies of a rapidly produced prototype.

Knowing that a prototype is disposable gives you freedom to take short cuts and hack out simulations of user interactions. The goal in a prototype is to help users see what the design is trying to accomplish, not follow best practices or coding patterns.

8. Don't make your first project time sensitive.

XAML-based technologies take time to assimilate. As I discussed earlier, the magic isn't in a few features. It's in how various capabilities combine in interesting ways. If you rush your first project, you're likely to skip over that assimilation phase and produce a disappointing result. Even worse, your mediocre design might be setting the pattern in your organization’s XAML development, causing even longer term damage.

Such a rich design process isn’t for all applications. It’s an investment, and as with all investments it’s important to gauge cost-benefit. An application with five users usually can’t afford the design investment of an application with a thousand users.

For situations that warrant the investment, however, I believe a multiple prototype process that respects the powerful capabilities of Silverlight and WPF will result in a much better return than an application that copies an older UI design and merely decorates it with pretty colors. That’s why my advice to you can be distilled down to just three words: design, don’t decorate.


\\[1\\] In fact, development time proved to be less than for many competing user interface technology alternatives. The advanced object-oriented nature of XAML-based technologies, plus the vast array of built-in technologies such as highly flexible data binding, resulted in a very reasonable total development time.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.