Modeling User Workflows for Rich Internet Applications

As Rich Internet Applications (RIAs) become more advanced, the tasks, problems, and processes they address become increasingly complex, making it more important than ever to accurately model user workflows. Early Internet applications were often narrowly focused in scope, and the steps were relatively simple and sequential, for example, purchasing items through simple e-commerce, reserving hotel rooms, or renting cars. But as productivity applications move toward a web-based distribution model, the tasks become more complicated.

In these newer, more complex applications, the steps are typically nonsequential; some examples of these types of applications include educational online training content and applications that track customer public utility usage and payment. To build an effective, efficient, and useful application, an application designer must have a complete understanding of these complex workflows; the tasks, information, and processes necessary to complete them; and the needs of the people using the RIA.

The success of an RIA depends upon its ability to replicate and improve upon the workflow for the task it replaces or supplements. Therefore, it is vital that you define the workflow completely and accurately. There are two groups of people who contribute to the definition and description of the workflow:

• Application owners whose business or goal is to provide functionality for end users. (For example, the bank technology and customer service groups "own" the online application for account management.) Application owners are often concerned with increasing profit, decreasing costs, and improving efficiency. The owners often make initial decisions about what functionality to include in the RIA.
• Application users who need functionality to complete their tasks. (For example, bank customers need online access to their accounts to pay bills, check balances, or make transfers.) Application users are often concerned with ease of use and automating tasks. The users often identify and request additional functionality to include in the RIA, comment on (or complain about) functionality that is inadequate or broken, and identify unnecessary functionality that could be removed.

The needs of the application owners and application users are not always complementary. Sometimes application users expect functionality that cannot be provided yet, and sometimes application owners do not know the value of certain functionality to users. For example, redundant data entry is a common complaint from application users. They correctly believe that data they should not have to provide data that they have previously provided again. For instance, a user should not have to enter a mailing address to receive requested brochures when there is a mailing address on file in the account.

However, application owners may have decided to save development costs when building the application, and decided that redundant data entry was an acceptable cost to the user. Application owners often focus on developing processes for complex tasks while underestimating the value of simpler processes, for example, prepopulating form fields with previously-entered data is a simple process with high value for users. Application users do not always understand the underlying complexity of seemingly simple tasks like aggregating data from multiple databases and systems to generate a single page or screen. The final workflow should balance the needs of the application owners and the application users to optimize performance of the RIA for each group.

Discovering the Workflow

Most RIAs replace existing processes; very rarely is an application designed for a completely new workflow. Some applications replace a single process, while others consolidate and simplify multiple processes. Regardless of the extent and complexity of the workflow, there are three basic techniques for discovering the workflow:

1. Examine the current processes, forms, and applications. Study the existing tools and software to learn how the tasks are currently completed. Look at the way participants record, associate, and order information. Look at how your users use different information sources and when.
2. Conduct interviews with both the application owners and the application users.
   1. Interview application owners to understand the role of the application for the business:
      1. What service or function do they believe it should provide the users?
      2. What other functions do they need the application to provide for the business (for example, marketing, access and usage analysis/tracking, data collection?)
   2. Interview users to understand how the application is expected to function and what needs it should meet:
      1. What should the application do? How should it do it?
      2. How might it work with other applications?
      3. What is the role of the application in the larger workflow? (For example, is the application involved only in some steps of a larger, more complex process?)
      4. Are there multiple people involved in the workflow or is there task sharing or hand-off?
3. Observe the application users at work to see how they currently complete their tasks. What people say they need and how they say they work is often different from what they actually need and what they actually do, so do not depend on interviews to be complete and unbiased. For example, people may say they complete a form in a single pass but fail to mention that they interrupt the process multiple times to retrieve and validate information from separate sources. Watching users work with other tools or previous versions of an application can reveal more about how to model the workflow and how the application should function than simply interviewing users and expecting them to have "keen insight" into their own needs and behaviors.

Study the current workflow using these techniques, but be careful to not get caught in the trap that the application workflow should match and be modeled on the current workflow. Current workflows may not be optimal, and the RIA could be designed to improve upon current processes and methods. Knowing how people currently work is not enough to model the workflow. You need more description to identify how to optimize the workflow.

Describing the Workflow

You must compile and analyze the workflow data collected through examination of existing tools, interviews, and observation before you can create new, improved workflow models. To describe and define the workflow, use three areas of analysis:

1. What information is necessary to complete the task?

   The user provides some information (like names and addresses) in complete form, but some information, such as checkout totals, may be in a form that require processing before the application can apply it to a task. Your application calculates checkout totals from item prices and quantities, shipping, taxes, and applicable discounts before submitting them for credit processing. When defining the steps in the workflow, create a complete list of information required to complete the task, whether or not the information must be processed, and any dependencies among the data (for example, ZIP code and shipping fees).

2. Where does the information come from and how is it entered into the RIA?

   Information may be collected and drawn from multiple sources such as paper forms, user memory, uploaded files, linked applications, or one or more databases. Information is most often entered into RIAs by typing, importing files, or from databases, but other methods exist, including voice recognition, gestures, alternate keyboards and control panels, touch screens, live capture. The source of information and how it is entered into the RIA is also necessary when defining the steps in the workflow.

3. What are the steps necessary to complete the task?

   When identifying and describing the steps involved in the task, define the start state (where the user begins, including the information the user should already have), the end state (when the user stops and the final results), and the path(s) that connect the two states, or how the user gets from the start state to the end state. A simple, linear sequence of discrete steps is often only relevant for simple tasks. Complex tasks typically have multiple levels of nested steps which may require nonlinear access to conditional steps.

   Identify higher-level steps and break them down into lower-level steps; distill each step into increasingly smaller steps until further decomposition would produce steps that are too granular to be practical. For example, users expect to provide their entire address on a single form, not one piece of information at a time on separate screens. In most cases, one low-level step corresponds to a single page or screen in the RIA. Finally, identify and describe the relationships among the steps: Are the steps in a linear sequence? Does one step depend on data provided in another? Does the user require data to be processed to use the results in another step?

At this point, you've collected the information necessary to develop an optimized workflow and to have analyzed and synthesized it into a descriptive form that defines how users work, the steps in the process, and the information necessary to complete the task. Developing a model will help you identify ways to improve the workflow as well as serve as the structural basis for designing and developing the user interface.

A workflow model serves as part of the foundation for the design of the user interface (in addition to the requirements and information design documents), but it also facilitates communication with the application owners and users. Use the workflow model to explain and illustrate how the needs of the owners and users are being met by the RIA, how users will interact with the RIA, and how the RIA will present, request, and process information during the task process.

Workflow Diagrams

You create diagrams of workflows as flow charts that show decision points (either user decisions or RIA conditionals), interaction points (where the user provides, receives, or modifies information), and RIA processes (either client-side or server-side). Although simple workflows may be linear sequences of steps and relatively easy to diagram, complex processes with nonlinear workflows require more elaborate representations.

When you describe the workflow steps, you will identify hierarchical relationships among steps and substeps. The workflow model should illustrate these relationships. It is usually necessary to create multiple workflow diagrams to represent the entire task process. There may be one high-level overview workflow diagram to describe the general process, a mid-level workflow diagram for each high-level step, and multiple lower-lever workflow diagrams (or substeps) for each mid-level step. The level of granularity depends upon the complexity of the process.

For example, workflow diagrams for an online shopping process may include:

• High-level workflow diagrams show an overview of the process, including steps for selecting a product category, browsing products, selecting products, and buying products.

(+) View larger

Clearly, there is too little detail at this level, but it is possible to illustrate easily how people shop in a non-linear manner by changing categories, selecting products and returning to browsing, even starting to check out and then returning to shopping.

• Mid-level workflow diagrams break out each step in the high-level workflow, such as dividing "buying products" into the substeps for viewing shopping cart, modifying cart contents, and checkout. Workflows at this level may not yet include all the details, but it is possible to illustrate how people look at and interact with their carts before returning to shopping, when they decide to view their carts, and when the RIA displays their carts for them.

(+) View larger

• Low-level workflow diagrams break out each step in the mid-level workflow, such as separating "checkout" into substeps such as gathering billing and shipping address, choosing a shipping method, choosing a payment method, verifying a credit card, and confirming the order.

(+) View larger

At this level, the workflow is still focused on the process. Further decomposition of the workflow would begin to focus on specific form fields and data (for example, entering a credit card number and expiration date), but the sequence of form fields on a page or screen is better addressed during the design of the user interface than with a workflow diagram. In some cases, it may be necessary to create even more granular, lower-level workflow diagrams, but in most situations two or three hierarchical levels is sufficient.

Improving Workflow

Use the workflow descriptions and workflow models to help identify ways to improve them. Look for ways to improve efficiency by reducing user and data errors and cutting down the time required to complete the task. Optimal efficiency occurs when you've minimized both errors and time. If going faster increases errors or reducing errors further would significantly increase time, then the balance is not optimal. Always consider the task at hand: If there is little or no margin for error (for example, financial transactions), then it is better to sacrifice time in the interest of accuracy. Take a look at the following areas to help bring your RIA to optimal efficiency:

Eliminate redundant data entry; do not force users to enter the same data more than once. Most tasks involve data entry of some form, and many involve collecting data from multiple sources; so, make it easy for users to modify or edit data previously entered and move among the steps without losing previous work. Include data validation in the workflow, and build error checking into the application whenever possible, ideally at the end of each step so that users can make corrections before proceeding to the next step—this maintains continuity of the workflow.

Strive to create a workflow that requires minimal instruction. The process should be obvious, easily discerned, and easily learned. Do not hide necessary information or options from the user, and do not complicate the process with unnecessary information or options. There should also be mechanisms for users to seek help and instructions. Ideally, help is context-sensitive and provides users with assistance based on the current step or the error, if one has occurred.

Consolidate steps to simplify the workflow. Why take five steps to do something that can be done in three or four? Combine steps when they are logically and practically related to reduce the number of steps, but do not combine steps simply because one step is smaller or shorter than another or because it is possible to do so. Consolidation may also involve removing information from immediate view (for example, tabs, drop-down lists, panes), but making it easily accessible without interruption to the workflow.

Consolidation should make the RIA more efficient in a rational and plausible way. Although it may be possible to combine steps or conceal information, it may not always be an improvement to the workflow. For example, if more than one person on a team works on a single task, it may be better to keep their contributions in separate steps to minimize error and confusion. Team members would only need to focus on their steps, pages, or screens.

Integrate functionality currently provided by different tools or applications, if possible. What can you combine? What should remain separate? For example, you may want to integrate address data from a contact management system with account data from an investment portfolio management system. This would eliminate redundant data entry and the need to manually access two separate information sources. Integrate components and functionality only when it does not interfere with or unnecessarily complicate the optimal workflow.

"As Simple As Possible—But No Simpler"

More consolidation and integration is not always better, and sometimes workflows are more easily understood and followed by users if further integration and consolidation is avoided (even if it is possible), because the transparency of the more explicit workflow (and potentially greater number of steps) creates context for application users. Understand which information is necessary to create context and to complete a step; sometimes consolidation makes steps more complex and less easily understood.

Albert Einstein said, "Things should be made as simple as possible—but no simpler." Workflows are no exception. Although it may be possible to reduce, consolidate, and integrate further, this may not lead to increased efficiency and efficacy. The best RIA is one that requests only what it needs, provides what is necessary when it is necessary, reduces the cognitive burden of the user whenever possible, and always provides context and status information. Once the workflow model has been developed, review it critically and look for omissions and/or inconsistencies, test it with users to verify that it represents how they work, and iterate and revise the model until it encompasses the range of tasks and processes the application must provide.

Once you've created and tested the workflow model, you can use it in the design and development of the user interface asking yourself the following questions:

• How are the steps represented and navigated?
• How are the steps associated?
• What information must be presented, collected, or modified in each step?
• How is progress and status information communicated?

The steps and substeps and their sequences and associations have been mapped out in the workflow diagrams. Each step, page, screen, or dialog box must create context and a sense of "place" in the process by identifying how and from where the user arrived, the purpose of the step, what information will be provided, what information must be collected, and what will happen next.

Additionally, there is step-specific information to be displayed and data to be collected from the user. The order of the information and the form fields for a particular step should logically represent the task. For example, you should collect address data in the expected order city, state, ZIP code—even if the page layout would be more efficient and would fit more information if that sequence were to be changed.

Also, do not ask users to make choices or perform actions unless they have completed all prerequisite steps and provided all the necessary information. Users on e-commerce sites will abandon a shopping cart if the checkout process asks for a credit card number before asking for a name or before showing a purchase total. It may be more efficient to request a credit card number and run the verification in the background while the customer provides shipping data, but users expect the credit card number to be entered at the end of the process just as if they were in a brick-and-mortar store.

User Interface Components

For most tasks and steps, there is more to do and show than you can place on the screen at one time, yet all of the information may be necessary at some point. There are several ways to make information visible or available on an as-needed basis and to move among steps—you can employ specific user interface components, which correlate to various information display methods. There are four categories of display methods and interface components: modal/non-modal, interactive/static, conceal/reveal on demand, and progressive disclosure.

Modal/Non-Modal

Users must complete modal steps before proceeding. (For example, shipping estimates cannot be calculated until the destination address is known.) When dealing with non-modal steps, on the other hand, users may start the step, leave it, and return to it repeatedly without affecting the task. (For example, one can view a shopping cart and modify its contents while continuing to browse and shop.) Modal steps are discrete, are present only as long as needed, and are then removed when completed. Pop-up dialog boxes and alerts are modal—once the user action is complete and the information has been collected or acknowledged, the dialog box or alert is removed.

Modal Flash/Flex components:

• The Alert component is a modal window that presents a message and buttons to capture the user's response. Once the user responds, the application removes the window and returns the user to a step in progress.

Interactive interface components, like editable text boxes or checkboxes, collect or modify information. Static interface components, like instructional text, images, and error and status messages, communicate with the user. These components are often among the most commonly used in an interface.

Interactive and static Flash/Flex components:

• The Button component (interactive) is a resizable button that can be customized with a custom icon.
• The CheckBox component (interactive) lets users make a Boolean (true or false) choice.
• The Loader component (static or interactive based on container content) is a container that holds a loaded SWF file or JPEG file.
• The NumericStepper component (interactive) is a text box with arrows a user can click to raise and lower the value of a number.
• The RadioButton component (interactive) lets users select between mutually exclusive options.
• The TextArea component (interactive) is an optionally editable, multiline text field.
• The Label component (static) is a noneditable, single-line text field.
• The ProgressBar component (static) displays the progress of a process, such as a loading operation.
• The ScrollPane component (static or interactive based on container content) displays movies, bitmaps, and SWF files in a limited area using automatic scroll bars.
• The TextInput component (static or interactive) is an optionally editable, single-line text input field.
• The Window component (static or interactive based on container content) is a draggable window with a title bar, caption, border, Close button, and content-display area.
• The UIScrollBar component (static) adds a scroll bar to a text field.

Conceal/Reveal On Demand

Conceal/reveal components show supplemental information or other optional components only when requested by the user. (For example, date selector widgets only show the calendar if the user selects it, otherwise he or she may enter the date by typing text.) When the component is not active, its contents are concealed from view but are immediately accessible without disrupting the task or step. This method helps create a user interface that is clean and uncluttered, yet contains extensive information and functionality.

Conceal/reveal Flash/Flex components:

• The Accordion component is a set of vertical overlapping views with buttons along the top that let users switch views. This is perhaps one of the most common methods of concealing information and/or form fields until they are needed; it may also be used to display discrete steps for very simple workflows.
• The DataGrid component lets users display and manipulate multiple columns of data.
• The DateChooser component lets users select one or more dates from a calendar.
• The DateField component is a nonselectable text field with a calendar icon. When users click inside the component's bounding box, a DateChooser component displays.
• The MenuBar component is a horizontal bar of menus.
• The Menu component is a standard desktop application menu; users can select one command from a list.
• The Tree component allows users to manipulate hierarchical information.

Progressive Disclosure

Progressive disclosure components show more information or interface components as the task progresses; they may also remove or conceal what has been completed. When the information that displays depends on prior choices, selections, or actions, it is unnecessary to show all possibilities before that choice is made—simply show the appropriate information after the choice has been made. (For example, some lists populate based on prior choices, such as a city list that is populated only after a state has been selected.)

Progressive disclosure is also a technique used to associate steps and identify their conditional relationships. The simplest form of progressive disclosure is to proceed to the next step when the current step has been completed. Progressive disclosure may also involve conditional relationships; for example, you might only display a shipping address form if the customer indicates that she wants to send the merchandise to an address different from her billing address.

Progressive disclosure may also depend upon data processing—the total cost of a stock trade can only be calculated when the price of the stock, the number of stocks, the cost per trade, and any applicable discounts or fees are known. RIAs excel at assessing conditional relationships, local data processing, and validation to create user interfaces that rapidly adapt to users’ individual needs and responses.

Progressive disclosure Flash/Flex components:

• The ComboBox component lets users select one option from a scrolling list of choices. This component can have a selectable text box at the top of the list that allows users to search the list. If the contents of the ComboBox component depend upon previous user choices, it is a progressive disclosure component.
• The List component allows users to select one or more options from a scrolling list. If the contents of the List component depend upon previous user choices, it is a progressive disclosure component.

Effective RIAs are built upon accurate and efficient workflows. Defining the needs of the application owners and understanding the needs, expectations, and tasks of the application users is necessary for modeling workflows and designing an effective and usable application. The techniques and components discussed above form an approach to modeling user workflows for RIAs that can clearly identify the steps and substeps of the task, help create efficient pages with limited screen real estate, and provide structure and guidance for users for complex and/or multistep tasks.

Workflow modeling is an analytical and iterative process. Effective workflows arise from a full and complete understanding of the goals and purpose of the RIA and how it will meet the needs of application owners and users. Each project will present unique constraints and demands, but the general process will always be to define and describe the current workflow, seek improvements in the process, create an improved workflow model, test the model with users, and revise the workflows until they fulfill the requirements for the application.

A common error in workflow modeling involves making assumptions about how people work and how the application will respond without explicitly including those conditions or circumstances in the workflow, because "everyone knows what should happen." An example of omitting a common workflow is not planning for a user who provides incorrect login information. How does the application respond? What options does the user have? How does it handle forgotten login information? Even if the condition and response is common knowledge, it should be included in the workflow.