Flash Article

Modeling User Workflows for Rich Internet Applications

Modeling the Workflow

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.

  

  Figure 1. A high-level workflow diagram illustrating the most common sequence of tasks involved in creating a list of items to be submitted to a requisitions office

  (+) 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.

  

  Figure 2. A mid-level workflow diagram illustrating the login process for the RIA for generating a requisition request

  (+) 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.

  

  Figure 3. A low-level workflow diagram illustrating the forgotten password process for users unable to log in to the requisitions RIA

  (+) 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.

Page 3 of 5

Previous Page

Next Page