Two basic differences exist between essential user interface prototyping and traditional UI prototyping. First, with essential UI modeling the goal is to focus on your users and their usage of the system, not system features. This is one of the reasons you want to perform essential use case modeling and essential user interface prototyping in tandem: they each focus on usage. Second, your prototyping tools are simple, including whiteboards, flip-chart paper, and sticky notes. The minute you introduce electronic technology to your prototyping efforts you have most likely made a design decision about the implementation technology. If you use an HTML development tool to build a user interface prototype, then you may immediately narrow your design space to the functionality supported within browsers. If you choose a Java development environment, then you may narrow your design space to Java, and if you choose a Windows-based prototyping tool, you may narrow your design space to whatever is supported on the Windows platform. Right now, you should be focused on requirements, not design; therefore, you don't currently want to use technology-based prototyping tools. Understand the problem first, and then solve it.

So how do you use sticky notes and flip-chart paper to create an essential user interface prototype? Let's start by defining several terms. A major user interface element represents a large-grained item, potentially a screen, HTML page, or report. A minor user interface element represents a small-grained item, widgets such as user input fields, menu items, lists, or static text fields such as labels. When a team is creating an essential user interface prototype, it iterates between the following tasks:

1. Explore system usage. Your team will explore system usage via several means. First, you will likely work together on a whiteboard to discuss ideas, work on initial drawing together, and generally take advantage of the dynamic nature of whiteboards to come to an understanding quickly of the portion of the system you are discussing. For example, with the university system, you may gather around a whiteboard to make an initial drawing of what a university transcript would contain or what a seminar enrollment submission would contain. Second, as you have seen, essential use case modeling is an effective technique for understanding the behavioral requirements for your system.
2. Model major user interface elements. Major user interface elements, such as potential screens and reports, can be modeled using flip-chart paper. I say potential because whether something is a screen or printed report is a design decision-a university transcript could be implemented as an HTML page your users view in a browser, as a paper report that is printed and mailed to students, or as an application screen. Each piece of flip-chart paper is given a name, such as Student Transcript or Seminar Enrollment Request, and has the appropriate minor user interface elements added to it as needed. Pieces of flip-chart paper have several advantages: they can be taped to a wall; they are good for working in groups because they make it easier for everyone to see and interact; they are large enough so you can put many smaller items such as sticky notes on them; you can draw on them; and they can be stored away between modeling sessions.
3. Model minor user interface elements. Minor UI elements, such as input fields, lists, and containers (minor UI elements that aggregate other minor UI elements) are modeled using sticky notes. Constantine and Lockwood (1999) suggest using different color notes for different types of components, for example, bright colors (yellow or red) for active user interface elements such as input fields versus subdued colors (white or tan) for passive interface elements such as containers. Figure 1 depicts an essential UI prototype to enroll students in seminars. The Student name sticky note is a container that includes four active elements: First name, Surname, Middle, and Title. The other sticky note represents a list of the seminars a student has taken or is currently enrolled in. Notice how each sticky note has a name that describes its purpose, but not how it is implemented. You can look at the sticky note and immediately know how it is used. Different sizes of sticky notes are used, indicating the relative size of each UI element. Also notice how the relative order of the UI elements are indicated by the order of the sticky notes: a student's title comes before his first name, then come his initials and his surname. This ordering may change during design but for now it is close enough. Whenever you realize you may need a minor user interface element, you simply take a sticky note, label it appropriately, and place it in the general area on a major user interface element where your stakeholder believe it belongs. Sometimes you identify a minor UI element that may not have a major UI element on which to place it. Don't worry. This is an iterative process, so attempt to identify an appropriate major UI element and continue. The very fact that sticky notes do not look like a real GUI widget is a constant visual reminder to your team that you are building an abstract model of the user interface and not the real thing. Each sticky note is, effectively, a placeholder that says you need something there, but you don't yet know yet the best way to implement it, so for now, you want to leave it open.
4. Explore the usability of your user interface. Highly usable systems are learnable, they enable user productivity, their use is easy to remember, and they are supportable.

Figure 1. Essential UI prototype for enrolling in seminars.

Let's examine Figure 1 in greater detail. This prototype was created using a standard piece of flip-chart paper; you should use one piece of flip-chart paper per major user interface element. The name, in this case Enroll in Seminar, is typically written across the top. Notice how there is two containers, which I drew on the paper to help bound different sections of the UI. The pink sticky notes, such as Student Number and Student Name, represent input fields, whereas the yellow ones are display only. Student Name is interesting because it is a bit of a cheat, listing four separate data elements on the one sticky note. I will often do this when I know some thing always come in a group and when I think I will need the room, which, as you can see I do. The blue sticky notes, such as Search and Help, represent actions items. Action items are often implemented as push buttons, function keys, or "hot key"� combinations, such as CTRL-SHIFT-S. All of the lists support selection of the information within them, for lists that don't support selection, you should indicate this information.

I like to ask questions about how your essential user interface prototypes would be used. For example, what should happen if a student really wants to enroll in a seminar that is currently full? Should she be given the opportunity to add herself to a waiting list? If so, how does that affect the user interface? You likely need to support the capability to indicate a waiting list of X number of people already exists, as well as a way to request being added to, or removed from, the waiting list. Should obtaining detailed information about the professor teaching a seminar be possibleShould obtaining detailed information about the seminars in the prerequisite list be possible? In Figure 1 you see it is possible to search for a seminar by inputting its number or name. Should searching by the department that offers the seminar be possible? Or, by day of the week on which it is offered (when I was a student I had a 1.5 hour commute, so I tried to enroll in seminars that all were held on the same days)? Or, by the name of the instructor teaching it? These are all interesting questions, the answers for which could potentially result in new requirements. However, always remember that your stakeholders are the official source of requirements, not developers. If you identify some new functionality that you think is required you need to convince your stakeholder that it's a good idea, have them prioritize it, and add the new requirement to the stack. When you're following Agile Modeling's practice of Active Stakeholder Participation this is very easy to accomplish because your stakeholder(s) would have been part of the modeling exercise to begin with.

We have been jumping through hoops not indicating implementation decisions for the major user interface elements. The reality is that you know that the seminar enrollment prototype is going to be implemented as either a screen or an HTML page, so why not admit it? When a major user interface element contains one or more minor user interface elements that permit editing, then you know it's going to be a screen or a page. When it contains no editable elements, then it will be a report. If you are going to a lot of "unnatural"� effort to make your major user interface elements independent of implementation technology, then you may want to loosen up a bit and distinguish between reports and screens/pages. In fact, once the architectural decision of how we're going to deploy the system has been made, I have a tendency to draw screen sketches on a white board which enables me to get a more accurate rendering of what the screen/report may look like. However, as always my advice is always to choose the most appropriate tools and techniques for your situation.

Source

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

Translations

• Japanese