Task Analysis
Task analysis is a process that builds a solid, extensible software design foundation. Often, software is designed by executing a series of prototypes. While prototyping is useful, the process does not provide any quantifiable way to ensure the design meets all the requirements or easily supports enhancements in the future. Task analysis provides a way to substantiate all aspects of the requirements by rigorously examining the user task flow. Task analysis also helps software designers get outside the box, by intentionally focusing on the operational problems to solve rather than implementation problems. By collaborating with all team members, designers using task analysis can consider the design from new perspectives, ultimately making a difference for the end users. The goal of task analysis is to empower the user beyond the original task requirements. 
How Do You Perform Task Analysis?
A task analysis consists of a breakdown of all the users' tasks to basic building blocks, then a subsequent buildup of these blocks into site features and components. 
Often original client taxonomies can be broken down into building blocks. The original categories are reorganized in such a way that the names for the original high level components may not truly apply. The original names for the low-level blocks, however, are usually preserved. 
A task analysis is a way of formally analyzing and reorganizing the features, goals, and requirements of an application. A useful analogy will help explain the process: Imagine you receive a box of office supplies. You unpack the box and find several cartons of colored pens, a few packages of post-it notes, some binders, little boxes of paper clips, several staplers, and a stack of notebooks. At this point, you need to decide what to do with the supplies. You can unpack them and put them in storage, in which case you would use a certain organization scheme, where like items would be stored together. Or, you could set them up in neat little packages so new employees can easily grab a set that contains one of each item. Or, perhaps you are preparing for a presentation and wish to create a subset of tools for each presentation attendee. Each purpose requires a different organization of the supplies. A task analysis, in this situation, would be the formal process you would use to unpack all the items and decide what your users will need. The task analysis will inform your organization of the supplies. 
The task analysis that Young Ideas performs for its clients serves this same purpose. Young Ideas unpacks the features and goals that our clients have defined, and reorganizes them according to the requirements that the users have outlined. 
A formal task analysis not only points the way toward a logical organization of features, but also provides naturally extensible solutions. When building up components, the team doing the analysis thinks in broad terms, making sure they explore and include any boundary conditions within any groupings they create. A design based on a formal task analysis is therefore more flexible and solid than a design created by skipping from feature set to feature set. 
Task analysis consists of several stages. These stages include initial investigation of the workflow, breakdown and definition of user tasks, buildup of those tasks into one or more configurations, and description of future use cases. 
Work Flow Analysis
The first exercise in a task analysis is to research how the potential users currently do their work. The Young Ideas user interface team gathers work pattern data from the client and from consultants that the client has hired. This data typically includes workflow reports, usability test results of current systems, definitions of all the types of users (analysts, editors, system administrators, customers, etc.), and preliminary designs of the new product. If there is time in the schedule, Young Ideas will also interview the users. 
Next, the Young Ideas user interface team lists all the tasks in the workflow, and often draws a diagram of the workflow, to help visualize the process. The team then passes the work to the client for verification that all tasks have been included and that no boundary conditions have been left out. 
User Scenarios
To further help visualize the workflow and to name the series of tasks, the Young Ideas user interface team writes several descriptions of how an example user works in the current document flow. These scenario descriptions use believable characters so the reader can get a better understanding of what challenges face the user each day. 
Task Breakdown
After the list of tasks is complete, the Young Ideas user interface team analyzes the tasks and breaks them down into atomic steps. These atomic steps --the individual bits of work that a person does, are then spread out and analyzed. Items that are the same are deleted without regard to parent, as this is the analytical process that allows the designers to empower the user by streamlining tasks. 
At the end, the user interface team writes definitions of each atomic task and prioritizes the list. 
Component Buildup
After the atomic tasks are analyzed and defined, the Young Ideas user interface team begins a second analytical process of grouping these tasks in new ways. The team explores several configurations. This process provides the foundation for the user interface for the final product. The team writes definitions for the new tasks. 
Use Cases
To validate the new design, the Young Ideas team takes orthogonal slices through the workflow, capturing at least one task of each flow, and writes use cases. These use cases feature believable characters and seek to depict the way in which the interface will work. If, during the writing, a flow does not work, then the team returns to the component buildup stage. 
After the team finishes the task analysis, they proceed to the user interface flow stage of the Young Ideas process. In this stage, they diagram the flow of the new interface, then draw schematics of the interface. These two products, along with descriptions of every page on the site, are included in a document called the Functional Design document.