User Interface (UI) Prototyping Tips and Techniques

User interface (UI) prototyping is an iterative development technique in which users are actively involved in the mocking-up of the UI for a system. UI prototypes have several purposes:

• As an analysis artifact that enables you to explore the problem space with your stakeholders.
• As a design artifact that enables you to explore the solution space of your system.
• A basis from which to explore the usability of your system.
• A vehicle for you to communicate the possible UI design(s) of your system.
• A potential foundation from which to continue developing the system (if you intend to throw the prototype away and start over from scratch then you don’t need to invest the time writing quality code for your prototype).

I have found the following tips and techniques have worked well for me in the past while UI prototyping:

1. Work with the real users. The best people to get involved in prototyping are the ones who will actually use the application when it is done. These are the people who have the most to gain from a successful implementation; these are the people who know their own needs best. Follow the Agile Modeling (AM) practice Active Stakeholder Participation.
2. Get your stakeholders to work with the prototype. Just as if you want to take a car for a test drive before you buy it, your users should be able to take an application for a test drive before it is developed. Furthermore, by working with the prototype hands-on, they can quickly determine whether the system will meet their needs. A good approach is to ask them to work through some use case scenarios using the prototype as if it were the real system.
3. Understand the underlying business. You need to understand the underlying business before you can develop a prototype that will support it. In other words, you need to base your UI prototype on your requirements. The more you know about the business, the more likely it is you can build a prototype that supports it. Once again, active stakeholder participation is critical to your success.
4. You should only prototype features that you can actually build. Christmas wish lists are for kids. If you cannot possibly deliver the functionality, do not prototype it.
5. You cannot make everything simple. Sometimes your software will be difficult to use because the problem it addresses is inherently difficult. Your goal is to make your user interface as easy as possible to use, not simplistic.
6. It’s about what you need. Constantine and Lockwood differentiate between the concepts of WYSIWYG, “What You See Is What You Get,” and WYSIWYN, “”What You See Is What You Need.” Their point is a good user interface fulfills the needs of the people who work with it. It isn’t loaded with a lot of interesting, but unnecessary, features.
7. Get an interface expert to help you design it. User interface experts understand how to develop easy-to-use interfaces, whereas you probably do not. A general rule of thumb is, if you have never taken a course in human factors, you probably should not be leading a UI prototyping effort. Better yet, a generalizing specialist with solid UI skills would very likely be an ideal member of your development team.
8. Explain what a prototype is. The biggest complaint developers have about UI prototyping is their users say “That’s great. Install it this afternoon.” This happens because users do not realize more work is left to do on the system. The reason this happens is simple: From your user’s point-of-view, a fully functional application is a bunch of screens and reports tied together by a menu. Unfortunately, this is exactly what a prototype looks like. To avoid this problem, point out that your prototype is like a styrofoam model that architects build to describe the design of a house. Nobody would expect to live in a styrofoam model, so why would anyone expect to use a system prototype to get his job done?
9. Consistency is critical. Inconsistent user interfaces lead to less usable software, more programming, and greater support and training costs.
10. Avoid implementation decisions as long as possible. Be careful about how you name these user interface items in your requirements documents. Strive to keep the names generic, so you do not imply too much about the implementation technology. For example the name Security Login Screen implies I intend to use graphical user interface (GUI) technology to implement it. The name Security Login is still technology independent.
11. Small details can make or break your user interface. Have you ever used some software, and then discarded it for the product of a competitor because you didn’t like the way it prints, saves files, or some other feature you simply found too annoying to use? I have. Although the rest of the software may have been great, that vendor lost my business because a portion of its product’s user interface was deficient.

This article is modified from Chapter 6 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.

Suggested Reading

This book, Choose Your WoW! A Disciplined Agile Approach to Optimizing Your Way of Working (WoW) – Second Edition, is an indispensable guide for agile coaches and practitioners. It overviews key aspects of the Disciplined Agile® (DA™) tool kit. Hundreds of organizations around the world have already benefited from DA, which is the only comprehensive tool kit available for guidance on building high-performance agile teams and optimizing your WoW. As a hybrid of the leading agile, lean, and traditional approaches, DA provides hundreds of strategies to help you make better decisions within your agile teams, balancing self-organization with the realities and constraints of your unique enterprise context.