Using Design Patterns to Gather More Complete Requirements Before Development

In my last article, "Give Users What They Want" in the March 2005 issue (available to subscribers at http://Advisor.com/doc/16030), I focused on the importance of meeting with customers, tips about conducting the interaction, and creating documentation including a workflow and context model diagram. This article expands on how you can use those diagrams to create an even more useful design specification called a wireframe application. In this article, you learn how to create and use the wireframe as a professional modeling tool.

To review, a workflow is a listing of the business process in some logical order. For example, a customer calls to place an order, the operator enters or searches for a client record, and the application creates the order record. A context model is a diagram that graphically represents all the consumers of the application data. The basics of the diagram is a circle in the middle that represents the application, and boxes around the circle represent any entity that can interact with the application, such as a user, another application, or piece of equipment. You draw lines between the boxes and the circle to represent any user interface, or other custom functionality you'll create as part of the new application.

The next step in the design process is to turn these two-dimensional items into a rich and vibrant user interface the customer can use to help visually understand how the application will look and operate when you complete it.

To help understand the concept I'm describing, I'm going to use a movie analogy. When beginning a project for a movie, the special effects creators typically start with a picture of whatever it is they're trying to create—whether it's a building or a space creature. The next step may be to develop blue prints or some other structural document, and then they create a model. This process helps the creators determine structural feasibility, and define scary or interesting features to appeal to audiences. To build this model, the designer can use an inexpensive medium, such as wire and clay, which is far less expensive than steel and concrete, or ballistics gel for that matter.

Imagine the process of creating a new space monster using clay. First the designer bends some wire into place to take the shape of the creature. He might add other wires to give the creature appendages such as arms, legs, or a tail. Using this base wireframe, the designer adds multiple layers of clay, which gives it depth, until there's enough clay to sculpt definitive features such as eyes, noses, or cool scars. Any errors he makes at this stage aren't costly, because the designer can add or remove clay with minimal time and resource loss. But, after the clay dries, it might not be as easy to add a new feature.

So, like the builder, you have blueprints at your disposal in the shape of the context model. From there, you have to create the wire skeleton so you can add clay, and finally sculpt into the picture that exists, typically only inside the customer's head.

Without the customer around, you want to start putting together the wire skeleton. Using the context model diagram, create a blank form (Would Access developers be creating a Web page) for each line that spans from a box to the circle. To each of these new forms, add only of controls for the form name and the form description (this is akin to starting to add clay to your wire model). For example: Form Name: Customers Form Description: Allow viewing/entry of customer data.

Notice the simplicity of this initial design is exaggerated, because it's just the first layer of clay. It is minimal, but it demonstrates the scope of the project to all parties from the customer to the developers. Everyone can begin to get a feel for the amount of work that lies ahead. One of the side benefits of creating all these forms is that when you save each one, you have to give it a name. Whether it's a form name in Access, or a file name in a Web folder, you must organize these forms from the very beginning of the project. It would be counter-productive to use names such as frm1 and frm2, because it would lose meaning quickly as the project progresses and be impossible to manage when its time to demonstrate to the customer. Take this opportunity to develop the naming conventions you'll use for the remainder of the application.

One of the reasons projects fail is that the customer doesn't commit the time and resources required to complete a successful design phase. After you create this base layer of forms, it's a good time to show it to the customer. Your presentation should demonstrate the need for more details (or clay in this analogy), which to the customer must provide. For each form, your customer can see you must have his input to specify what fields you have to add to the form, and the order in which you have to place them. When he sees this, he's usually eager to help, which helps to maintain interest and momentum in the application creation process. From here, you can inform the customer of what it may take to add the clay to each form. For example, simple forms may need only 30 minutes of discussion, but complex ones could take 2-3 hours. You can create work plans to specify which forms you'll cover in which meetings, letting the customer schedule users depending on the topics you plan to explore in that meeting.

In the final article in this series, I'll show you the importance of using a white board. Regular white boards can work, but if you don't have access to a self-printing, or one that directly links to a computer, then you may want to consider renting one. You may already use a voice recorder for meetings, but words on paper are always more useful to locate than offhanded, recorded comments. During a design meeting, you and the customer can both draw representations of the layout of each of the forms. You can show the location of controls, list example data values, and note data validations. Here are some of the important parts of this process: for every tab control, data grid, and field label, make sure to put the exact words you plan to use in the application. The customer must understand that if the column header shows a word on the wireframe, you'll use the same word in the application. You don't want to spend multiple hours after development (when the clay is dry) changing labels on every form. So, spend some time up front to get them correct the first time. An added benefit of this process is that you'll be able to define the vernacular you'll use throughout the application. (There's nothing worse than calling the same entity something different names in different parts of the application, such as Program vs. Project.) If you really want to impress the customer, have previous applications loaded and ready or have some Web sites in mind to demonstrate functionality you might be able to include in their application. When a customer can envision functionality he knows and loves from existing applications such as Quicken, ACT, Google, or eBay, he can get very excited about your project. During this process, customers are prone to add "one liners" about the functionality of each form. For example, "Can you make that dropdown only show the ...?", or "We need to change the records to red that are..." Adding notes to the drawings about each of these requests ensures the functionality doesn't get lost. It isn't good for your business when a customer refers to something he was said in a meeting that doesn't make it into the application. Don't forget also that you can charge for each piece of requested functionality, so don't let them forget they've requested it. Finally, after the completion of each drawing, take a photo, print, or download the drawing and give a copy to the customer. Be sure to date each of the drawings, too, because this helps you remember which forms were discussed in which meetings. Continue the meeting/drawing/revision process until you've covered all the forms, or until the set meeting duration has expired.

After each meeting when the customer is gone, return to the wireframe application and add more controls (clay). But, don't just add clay to add clay; instead, take time as you add it to reflect on what was drawn, what the intent of each control was, how it contributes to the overall application, and scrutinize your work. Review the concepts with a co-worker to verify technological feasibility, or just to get a developer mentally into the process so he's more familiar with the project when development starts.

The added controls don't have to work or be attached to a dataset, but are simply a placeholder to help the customer envision the layout of the form. You can add fake data to combo boxes, and rectangles and labels or basic HTML tables can represent subforms or data grids. The objective is to create something quickly and inexpensively the customer can understand and verify is correct.

Finally, it may be helpful to add a rudimentary level of navigation, to make a more "clickable" demonstration tool. For Windows applications, you can use a menu bar or form full of buttons, or for a Web application, create a navigation bar. Refer back to the workflow document to look for any navigation steps you can work into the process. Although this may add a couple of hours to the clay application, the customer may respond favorably to the ability to click around the wireframe. After each round of meetings and wireframe updating, deploy another version of the wireframe application to the customer. Send them a new Access database, or publish the changes to a Web server, but don't forget to retain the previous versions. Treat it just like a live deployment, in case you have to rollback.

Depending on how you run your shop, you can request the customer sign a document that says he agrees that each of these forms, or all of them collectively, have been designed correctly, and that development based on these specifications may proceed. Not that you don't trust your customers, but getting them to buy into the concept early with a signature keeps them motivated to continue working with you on the project. Plus, if anything goes wrong down the road, you have a gentle reminder that they authorized you to proceed. This article covers the basics of creating the wireframe application, but don't forget that reports are an important part of every application. Although I didn't cover them in detail, assume you have to also explore any user interfaces required to collect criteria or capture additional data for a specific instance of a report during these customer meetings and add them to the wireframe.

In this article, you learned the basics of expanding a workflow and context model diagram into a more 3-D model. This process can help the customer better understand the scope and complexity of their new application and keep the customer involved in the development process. These techniques can help to ensure the project development results in a successful outcome.