Siebel Business Process Framework: Task UI Guide > Best Practices for Working with Tasks > Best Practices for User Experience of Tasks >

Best Practices for Designing a Task's Flow

When designing a task-based UI, envision the presentation of information in a series of linked pages, or steps. Although in many cases, a task step can be contained in a single page, this need not always be the case. If the step is complex, break it into two pages. The overriding principle of Task UI design is simplicity, both in content and the presentation of content.

Keep the following factors in mind while designing your task flows:

• Task frequency. How often will the user be performing the task?
• Task complexity. Make sure each task is self contained, a single point-to-point flow, not a collection of tasks contained in one task. Be mindful during the design phase of the number or steps or decisions, and if necessary break one task into two.
• User experience. Be mindful of not only the end user's experience, but of user's job role itself, and consider questions such as job turnover, and computer aptitude.
• Task size. Can the task be broken down into a number of logical chunks? The user should be taken through one task flow, easy to follow and review. If the task gets too long, you may lose the user.
• Enforce forward navigation allowing task review and editing. Design your tasks in such a way that your end user is guided forward through a task in a manner that allows editing and review of completed portions. Navigation that requires end-user use of the Previous button is acceptable, but the end user should not have to repeatedly click Previous back through a long list of views to correct data entered earlier.
• Organize flows in logical sections.
• Organize flows around logical task transaction commit points.
• Use the Chapters feature. Chapters represent a descriptive unit of the work covered by the task. The goal of chapters is to allow you to more easily guide a user through a process and supplement user inputs with additional procedural automations.

  Chapters also provide an outline of the task to the end user. This helps the end user understand what will be done in the task and how much is left to do. The individual steps within a chapter may vary depending on choices made by the user. However, the outline provided by chapters does not change. For more information on chapters, Task Chapter.

• Allow users to enter record data across multiple views.
• Allow users to enter multiple records. In general:
  • Use of form views. Looping over a form view is preferred if there is a lot of data being entered for each record.
  • Use of list views. Using a list view is preferred if the number of fields needed for each record is small and fits well on the screen without horizontal scrolling of the list view.
• Allow user specified queries. Putting query and results in separate views vs. using the same view for both query and result display.
• Use the same Task View in multiple view steps within a task.
• Choose a step display style for the Current Task pane. The choice is between displaying every step to the end user, or displaying a subset of steps that provides an outline of the task.
• Avoid hyperlinks within tasks. Remain within the task flow. Avoid scripts or run-time events that would break out of the task flow, putting the task on Pause.
• Include a Review page. A review page (or summary view) allows the user to review and change any data before it is committed. A review page can be at the end of a task, or in the midst of one, if the task flow it complex.