User Interface Prototyping Tips and Techniques

Scott W. Ambler + Associates
 
     Home  |  Articles  |  Books  |  IT Surveys  |  Podcasts  |  Contact Us  |  Announcements  |  Site Map
Recently reviewed

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

Disciplined Agile Delivery This book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise describes the Disciplined Agile Delivery (DAD) process decision framework. The DAD framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and provides the foundation for scaling agile. This book is particularly important for anyone who wants to understand how agile works from end-to-end within an enterprise setting. Data professionals will find it interesting because it shows how agile modeling and agile database techniques fit into the overall solution delivery process. Enterprise professionals will find it interesting beause it explicitly promotes the idea that disciplined agile teams should be enterprise aware and therefore work closely with enterprise teams. Existing agile developers will find it interesting because it shows how to extend Scrum-based and Kanban-based strategies to provide a coherent, end-to-end streamlined delivery process.

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer.  A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates


Disciplined Agile Delivery: The Foundation for Scaling Agile Agile Modeling: Practices for Scaling Agile Agile Data: Practices for Scaling Agile EnterpriseUP: Agility at Scale AgileUP: Towards Disciplined Agile DeliveryAmbysoft Inc. Software Development Practices Advisor Scott Ambler + Associates Follow @scottwambler on Twitter!


Copyright 2005-2014 Scott W. Ambler

This site owned by Ambysoft Inc.