Resource: Ch. 10, "Designing Forms and Reports".Design two forms for a new software application or business web app that will collect data from its user.Draw these two forms. You may use free tools,

Designing Forms and Reports

This is the second chapter that focuses on system design within the systems development life cycle (see Figure10-1). In this chapter, we describe issues related to the design of system inputs and outputs—forms and reports. In Chapter 11, we focus on the design of dialogues and interfaces, which are how users interact with systems. Due to the highly related topics and guidelines in these two chapters, they form one conceptual body of guidelines and illustrations that jointly guide the design of all aspects of system inputs and outputs. In each of these chapters, your objective is to gain an understanding of how you can transform information gathered during analysis into a coherent design. Although all system design issues are related, topics discussed in this chapter on designing forms and reports are especially relative to those in the following chapter—the design of dialogues and interfaces.

System inputs and outputs—forms and reports—were identified during requirements structuring. The kinds of forms and reports the system will handle were established as part of the design strategy formed at the end of the analysis phase of the systems development process. During analysis, however, you may not have been concerned with the precise appearance of forms and reports; your concerns likely focused on which forms or reports need to exist and their contents. You may have distributed prototypes of forms and reports that emerged during analysis as a way to confirm requirements with users. Forms and reports are integrally related to various diagrams developed during requirements structuring. For example, every input form will be associated with a data flow entering a process on a data flow diagram (DFD), and every output form or report will be a data flow produced by a process on a DFD. This means that the contents of a form or report correspond to the data elements contained in the associated data flow. Further, the data on all forms and reports must consist of data elements in data stores and on the E-R data model for the application, or must be computed from these data elements. (In rare instances, data simply go from system input to system output without being stored within the system.) It is common that, as you design forms and reports, you will discover flaws in DFDs and E-R diagrams; these diagrams should be updated as designs evolve.

Figure 10-1 Systems development life cycle with logical design phase highlighted

If you are unfamiliar with computer-based information systems, it will be helpful to clarify exactly what we mean by a form or report. A form is a business document that contains some predefined data and often includes some areas where additional data are to be filled in. Most forms have a stylized format and are usually not in a simple row and column format. Examples of business forms are product order forms, employment applications, and class registration sheets. Traditionally, forms have been displayed on a paper medium, but today video display technology allows us to duplicate the layout of almost any printed form, including an organizational logo or any graphic, on a video display terminal. Forms displayed on a video display may be used for data display or data entry. Additional examples of forms are an electronic spreadsheet, a computer sign-on or menu, and an ATM transaction layout. On the Internet, form interaction is the standard method of gathering and displaying information when consumers order products, request product information, or query account status.

Form

A business document that contains some predefined data and may include some areas where additional data are to be filled in. An instance of a form is typically based on one database record.

Report

A business document that contains only predefined data; it is a passive document used solely for reading or viewing. A report typically contains data from many unrelated records or transactions.

A report is a business document that contains only predefined data; it is a passive document used solely for reading or viewing. Examples of reports include invoices, weekly sales summaries by region and salesperson, or a pie chart of population by age categories (see Table 10-1). We usually think of a report as printed on paper, but it may be printed to a computer file, a visual display screen, or some other medium such as microfilm. Often a report has rows and columns of data, but a report may be of any format—for example, mailing labels. Frequently, the differences between a form and a report are subtle. A report is only for reading and often contains data about multiple unrelated records in a computer file. In contrast, a form typically contains data from only one record or is based on one record, such as data about one customer, one order, or one student. The guidelines for the design of forms and reports are very similar.

Table 10-1 Common Types of Business Reports

The Process of Designing Forms and Reports

Designing forms and reports is a user-centered activity that typically follows a prototyping approach (see Figure 6-7). User-centered design refers to a design approach that involves an understanding of the target audience, their tasks and goals, information needs, experience levels, and so on. So, to begin, you must gain an understanding of the intended user and task objectives by collecting initial requirements during requirements determination. During this process, several questions must be answered. These questions attempt to answer the “who, what, when, where, and how” related to the creation of all forms or reports (see Table 10-2). Gaining an understanding of these questions is a required first step in the creation of any form or report.

Table 10-2 Fundamental Questions When Designing Forms and Reports

For example, understanding who the users are—their skills and abilities—will greatly enhance your ability to create an effective design (Lazar, 2004; McCracken et al., 2004; Te’eni et al., 2006). In other words, are your users experienced computer users or novices? What are the educational level, business background, and task-relevant knowledge of each user? Answers to these questions will provide guidance for both the format and content of your designs. Also, what is the purpose of the form or report? What task will users be performing and what information is needed to complete this task? Other questions are also important to consider. Where will the users be when performing this task? Will users have access to online systems or will they be in the field? Also, how many people will need to use this form or report? If, for example, a report is being produced for a single user, the design requirements and usability assessment will be relatively simple. A design for a larger audience, however, may need to go through a more extensive requirement collection and usability assessment process.

After collecting the initial requirements, you structure and refine this information into an initial prototype. Structuring and refining the requirements are completed independently of the users, although you may need to occasionally contact users in order to clarify some issue overlooked during analysis. Finally, you ask users to review and evaluate the prototype. After reviewing the prototype, users may accept the design or request that changes be made. If changes are needed, you will repeat the construction–evaluate–refinement cycle until the design is accepted. Usually, several iterations of this cycle occur during the design of a single form or report. As with any prototyping process, you should make sure that these iterations occur rapidly in order to gain the greatest benefits from this design approach.

The initial prototype may be constructed in numerous environments, including Windows, OSX, or, most frequently, for the web. The obvious choice is to employ standard development tools used within your organization and the target platform for your system. Often, initial prototypes are simply a series of mock screens that are not working modules or systems. Mock screens can be produced from a word processor, computer graphics design package, electronic spreadsheet, or even on paper (Snyder, 2003). This series of mock screens is commonly referred to as a paper prototype. In addition to providing a look and feel that can be assessed, the paper prototype is also used to test content, task flow, and other usability factors. It is important to remember that the focus of this activity is on the design—content, layout, and flow—of forms and reports; of course, you must also consider how specific forms and reports will be implemented. It is fortunate that tools for designing forms and reports are rapidly evolving, making development faster and easier. In the past, inputs and outputs of all types were typically designed by hand on a coding or layout sheet. For example, Figure 10-2 shows the layout of a data input form using a coding sheet.

Paper prototype

A series of mock screens that can be used to test content, look, and feel, as well as the task flow and other usability factors.

Although coding sheets are still used, their importance has diminished due to significant changes in system operating environments and the evolution of automated design tools. Prior to the creation of graphical operating environments, for example, analysts designed many inputs and outputs that were 80 columns (characters) by 25 rows, the standard dimensions for most video displays. These limits in screen dimensions are radically different in graphical operating environments such as Microsoft’s Windows or the web, where font sizes and screen dimensions can change from user to user, or from device to device. Consequently, the creation of new tools and development environments was needed to help analysts and programmers develop these graphical and flexible designs. Increasingly, developers are using tools that can quickly create screen mockups, referred to as wireframes, to show the placement of information elements on a screen and the space needed for each element. Wireframe can be used to quickly develop a series of screens so that users can get a sense of the look and feel of a design, as well as the flow and interaction of a series of screens (see Figure 10-3a). Some wireframe development tools, like Axure, can directly generate HTML code for web applications. For non-web applications, developers may build screen prototypes using a development language. For example, Figure 10-3b shows an example of the same data input form as designed in Microsoft’s Visual Basic.NET. Note the variety of fonts, sizes, and highlighting that was used. Given the need for rapid, iterative development when designing forms and reports, tools that seamlessly move prototype designs to functional systems are becoming standard in most professional development organizations.

Wireframe

A simple design to show the placement of information elements on a screen and the space needed for each element.

Deliverables and Outcomes

Each systems development life cycle (SDLC) phase helps you to construct a system. In order to move from phase to phase, each activity produces a type of deliverable that is used in a later phase or activity. For example, within the project initiation and planning phase of the SDLC, the Baseline Project Plan serves as input to many subsequent SDLC activities. In the case of designing forms and reports, design specifications are the major deliverables and are inputs to the system implementation phase. Design specifications have three sections:

Figure 10-2 The layout of a data input form using a coding sheet

1. Narrative overview

2. Sample design

3. Testing and usability assessment

Figure 10-3A A data input screen designed as a wireframe

Figure 10-3B A data input screen designed in Microsoft’s Visual Basic.NET

(Source: Microsoft Corporation.)

The first section of a design specification contains a general overview of the characteristics of the target users, tasks, system, and environmental factors in which the form or report will be used. The purpose is to explain to those who will actually develop the final form why this form exists and how it will be used so that they can make the appropriate implementation decisions. In this section, you list general information and the assumptions that helped shape the design. For example, Figure 10-4 shows an excerpt of a design specification for a Customer Account Status form for Pine Valley Furniture (PVF). The first section of the specification, Figure 10-4a, provides a narrative overview containing the relevant information to developing and using the form within PVF. The overview explains the tasks supported by the form, where and when the form is used, characteristics of the people using the form, the technology delivering the form, and other pertinent information. For example, if the form is delivered on a visual display terminal, this section would describe the capabilities of this device, such as whether it has a touch screen and whether color and a mouse are available.

Figure 10-4 Design specification for the design of forms and reports

(Source: Microsoft Corporation.)

In the second section of the specification, Figure 10-4b, a sample design of the form is shown. This design may be hand drawn using a coding sheet, although in most instances it is developed using standard development tools. Using actual development tools allows the design to be more thoroughly tested and assessed. The final section of the specification, Figure 10-4c, provides all testing and usability assessment information. Procedures for assessing designs are described later in this chapter. Some specification information may be irrelevant when designing some forms and reports. For example, the design of a simple Yes/No selection form may be so straightforward that no usability assessment is needed. Also, much of the narrative overview may be unnecessary unless intended to highlight some exception that must be considered during implementation.