User Interface (UI) Prototypes: An Agile Introduction
- As an analysis artifact that enables you to explore the problem space with your stakeholders.
- As a requirements artifact to initially envision the system.
- As a design artifact that enables you to explore the solution space 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).
As you see in the activity diagram depicted in Figure 1 there are four high-level steps in the UI prototyping process. The first step is to analyze the user interface needs of your users. User interface modeling moves from requirements definition into analysis at the point you decide to evolve all or part of your essential user interface prototype into a traditional UI prototype. This implies you convert your hand-drawings, flip-chart paper, and sticky notes into something a little more substantial. You begin this process by making platform decisions which in effect is an architectural decision. For example, do you intend to deploy your system so it runs in an Internet browser, as an application with a windows-based graphical user interface (GUI), as a cross-platform Java application, or as a mainframe-based set of “green screens?” Different platforms lead to different prototyping tools, for a browser-based application, you need to use an HTML-development tool, whereas a Java-based application would require a Java development tool and a different approach to the user interface design.
While you’re determining the needs of your stakeholders you may decide to transform your essential user interface prototypes, if you created them to begin with, with sketches. Figure 2 depicts an essential UI and Figure 3 a sketch of two potential screens or HTML pages based on that prototype. Transform really isn’t the right word here seeing as I’m using a completely different modeling technology now (a whiteboard instead of paper) so in effect I’m replacing the essential UI prototype with the sketches.
I chose to split the prototype in two for cohesion issues – I prefer screens that fulfill a single purpose, in this case capturing basic student information and enrolling a student in seminars respectively. This is arguably a design issue (there’s a fine line between analysis and design which you’ll cross all the time). The sketches provide a final level of detail than the paper prototypes do, it is much easier to get a feel for how the screen will be implemented from than it is from Figure 2, although the sketch isn’t as flexible because it’s hard to shift widgets from one part of the diagram to another whereas with the paper it is very easy.
As you iterate through UI prototyping you will often discover information better captured in other artifacts. That’s okay, you can follow the AM practice Iterate to Another Artifact and capture that information in the proper place. It also points to the importance of the AM practice Create Several Models in Parallel – you often need to work on several things at once to get the job done. Agile software development is an evolutionary process, so this is normal.
Once you understand the UI needs of your stakeholders the next step is to actually build a prototype. Using a prototyping tool or high-level language you develop the screens, pages, and reports needed by your users. With the user interface platform selected, you can begin converting individual aspects of your essential UI prototype into your traditional UI prototype. You may want to create sketches such as you see in Figure 3 or go straight to a concrete implementation, such as the HTML page depicted in Figure 4. The sketches are more inclusive, your stakeholders can be actively involved in creating them, although the actual HTML page is much closer to working code (your primary goal).
It is critical to understand that you don’t need to create a prototype for the entire system. It is very common to prototype a small portion of the user interface, perhaps a single screen or HTML page, before moving on to implementing it. Remember, agile developers work in an evolutionary manner – the don’t need to define everything up front before moving on. Sometimes you will need to prototype a large portion of your system, perhaps as part of an envisioning exercise or perhaps even to help define the system scope so that you can obtain funding.
After a version of the UI prototype is built, it needs to be evaluated by your stakeholder’s to verify that it meets their needs. Sometimes this is as easy as asking someone to spend a few minutes to look at what you’ve built and other times it’s as complicated as scheduling a meeting so that you can demonstrate the software to a group of people. I prefer the first approach. When evaluating a UI prototype I’ve always found that the following questions provide me with significant feedback:
- What is good about the UI prototype?
- What is bad about the UI prototype?
- What is missing from the UI prototype?
After evaluating the prototype, you may find you need to scrap parts of it, modify parts, and even add brand-new parts. You want to stop the UI prototyping process when you find the evaluation process is no longer generating any new ideas or it is generating a small number of not-so-important ideas. Otherwise, back to exploring your stakeholder’s UI needs.
This artifact description is excerpted from Chapter 6 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.