Topic Archive: Task Flows

Use a Task Flow to Show “How do I ___?”

Alice Toth, Tuesday, April 8, 2008 @ 11:20 am

Although task flow diagrams (sometimes referred to as interaction flows, process flows or work flows) are a standard in most IA’s toolkits, it can be confusing for those unfamiliar with this particular tool to know when to start diagramming. When in the process is it started? How much information is needed before diagramming? How much detail should be added? When is it considered complete? 

The short answer is to start diagramming once the task is identified because it’ll help in flushing out the requirements. The diagram starts to identify what the user and the system need to do. It delineates a repeatable pattern of activity. It answers the question: “How do I _____________”.

After you have an identified task (I like to use Use Case Diagrams to call out the high-level tasks), the start point and end point need to be established. For example, let’s say your business requirements state that the web application is only accessible by authenticated users; therefore, a user needs to successfully login in order to see the home page. The initial diagram has the user starting on the login page, submitting their information and viewing the home page after the system logs them in.

But wait … I did say *successfully* login, didn’t I. O.k., so we add a decision point to the diagram to show that only successful logins allow a user to access the web application. Don’t worry just yet what the details are for the system to successfully authenticate a user. The purpose of the diagram is to identify the process, not to define it. For now, all that's needed is to show that the login information must be vetted before the system allows access.

Granted, the previous examples are simplistic, but simple is where task flow diagrams start. This basic statement “How do I ____________” turns into an initial task flow, delineating the steps needed to complete the task from start to finish based on the information known at that time. The first iteration is generally the ‘happy path’ and identifies the main flow of a task.  As more steps are uncovered through requirements, the flow is updated and modified to accommodate the new information and show the various decision points and/or alternative paths as they become known. The end result is a flow diagram that conveys both the overall structure of the main user tasks and the sequencing of activities to be programmed into a repeatable activity.

• Digg
• Reddit
• del.icio.us

Comments (0)

user experience design

It Starts with the User Story

Alice Toth, Thursday, March 6, 2008 @ 12:01 pm

Having recently been asked about the difference between a use case and a user story, I came up with this explanation:

Use cases detail the interactions between an actor and the system in a sequence of steps and are generally used to capture the functional requirements of a system before implementation. Because of their scope, i.e., they take in more exception scenarios, they can be too large to be used for iteration planning since they would be split across multiple iterations. Also, there is a bit of a learning curve to interpreting use cases which can leave the non-technical customer out in the cold.

A user story is a short description of a feature as told from the point of view of the user (generally your persona). They consist of one or two sentences written in the language of the user, and are used to estimate the degree of difficulty to implement (which ties in with iteration planning). At Pathfinder, we also include acceptance tests when we write the user story as a way to set out the criteria that determines when the story's goals have been met. Again, written in plain English so that both technical and non-technical team members understand what success means for that feature.

For our Ruby on Rails projects, we're writing our user stories in a format that'll help the developers convert them into automated tests using the Rails framework:

As a [role]
I want [feature]
so that [benefit]

From here we create the acceptance criteria, which we write as scenarios in a specific format (givens, events and outcomes) in order to help with writing the automated tests:

Scenario 1: Title
Given [context]
  And [some more context]…
When  [event]
Then  [outcome]
  And [another outcome]…

We'll then go on to create flow diagrams, requirements and wireframes to further flesh out the details of this feature, but it all begins with the User Story and Acceptance Tests.

• Digg
• Reddit
• del.icio.us

Comments (0)

user experience design

Goldberg workflow

Michael Dain, Friday, February 22, 2008 @ 5:11 pm

In a current project there is the need to use email to allow customers to 'sign up' for information updates. In working through the user experience I have been looking deeper into how different programs have enabled email to process and initiate workflow that it led me to solve a problem in a surprising way. It also reminded me of how in user research it can be nonsensical and even counterintuitive how people use software to help them with their tasks. Its all a strange rube goldberg like process, which gives me an excuse to share the "Pitagora switch" video, which always invigorates me when a software project seems to lose momentum.

I started with a basic problem of the customer (In this case, me) who is a amateur oenophile. I try a new wine and would like to keep track of my thoughts and rankings in the easiest way possible. I have an account on Corkd, a wine rating site, but the customer experience is lacking in some ways, and adding wines is a chore. A friend mentioned that he only buys wine based on label, and that is important, so I would like to keep a photo for reference as well. Many sites do photos, many do blogs, but I wanted to do them both together. So I set up my own site with a bit of wordpress and a domain name, I was up and running. However, it still seemed a chore, if I was enjoying a wine, I would have to go to the computer, log in, write, set up, upload photos, remember which one... oh, again, too much work, and the site and content stagnated.

Armed with some experience in the email interfaces to these blogging/cms systems, I came up with a weird way to make the process easier. It does involve an iphone, but that is just to enable the 'mobile' experience. As I went through it, it worked perfectly, and was quite a bit of fun, not to mention a triumph of non-linear thinking! To summarize:

1. Enjoy some wine - be sufficiently inspired to blog something about it
2. Use the iphone (or I suppose any picture phone) to photograph the wine label
3. Email the picture to flickr (check flickr account details for your personal email address that posts the picture)
4. Set up flickr to be aware of the 'wineskeptic' blog by pointing it to a script within wordpress that will accept XML posts
5. This enables the little 'blog this' link above the picture, using the iphone web browser enter the tasting notes. Save.
6. Check the blog, notes and picture are posted, success!

I hadn't really used the flickr service for anything but archiving and sharing photos before, and its a very cooperative model they enabled. The photo is not the main reason for the post. If you have experiences with similar ways you mashed up some technologies to solve a workflow problem, please comment!

• Digg
• Reddit
• del.icio.us

Comments (0)

user experience design

Writemaps: A web based site map generating tool

Sholom Sandalow, Friday, November 30, 2007 @ 2:24 pm

Came across an interesting web tool today...Writemaps: A site map generating tool that allows you to build, edit and share site maps. 

It's got limited features, but it has two big things going for it:
1 - It's web based, and you can share your files via url.  So anyone with a web connection can view and edit what you've created.

2 - It creates presentable sitemaps.  The page representations (nodes in the site map tree) have subtle gradients and drop shadows, and the tree diagram contains only right angles, giving your sitemap a polished professional touch.

A few other notes about this tool:
Can't print or save as image, but you can save as XML.
It's got an undo button! (how many web apps do that?)
You can zoom in/out on your map views.
It's dead easy to get started.

In summary, there's a lot of potential here, and I think I might give it a try on my next project.

Powered by ScribeFire.

• Digg
• Reddit
• del.icio.us

Comments (1)

user experience design

Get in the Flow (Task Flow that is)

Alice Toth, Wednesday, September 19, 2007 @ 12:40 pm

Call them what you like (task flows, work flows, process flows), flow diagrams are an important part of any software project. As a developer, you may be more familiar with sequence diagrams, a nifty way to visualize an exchange of messages between different processes and the order in which they occur.

Well another useful diagram is the end-to-end task flow. This handy dandy diagram shows all the steps necessary for a user to accomplish a task. Buy a pair of shoes? Select shoes, select size, add to cart, go through checkout process. Simple and easy.

And yet, what is it really telling you? Well, a flow diagram gives you an overview of the end-to-end process, the start to finish if you will. It lets you know what the user needs to do in order to start a task (select those really cool shoes) and what defines that the task is completed (display order confirmation). In between those two points are all the necessary steps to go from start to finish.

Initially, the in betweens are very high level (as evidenced by the above diagram). As more information becomes available, the flow is modified, added to, subtracted from and generally redrawn to show not only the user tasks, but also the system tasks (return error message, validate and continue), alternative routes (continue shopping, display upsell message) and decision points.

I've found flow diagrams to be very helpful because they let team members know how their stuff fits into the big picture. Let’s face it, on most projects the end-to-end flow is never developed lineally by one developer. Instead, it’s broken down into pieces and parts and assigned to various people. Seeing the end-to-end diagram up front gives you the overall picture of how an entire feature will play out and, more importantly, shows you how and where your piece fits into the whole. It'll get you thinking about potential points where code can be reused (sweet!) or better ways the data can be used at the presentation layer.

End-to-end diagrams let you see that what you're working on is no longer a lonely story in isolation, but rather something that’s part of a defined sequence that contains a beginning and middle and end. It ties what you're doing into the whole and brings a coherency to the process. This is especially valuable for large features that are spread out across teams and even iterations.

Technorati Tags: task flows, information architecture, diagrams

• Digg
• Reddit
• del.icio.us

Comments (6)

user experience design

User Task Flows Help Developers:

Alice Toth, Sunday, March 11, 2007 @ 7:51 pm

Work out the Workflow. Making changes after a product is released is much more costly, and sometimes not even feasible, than identifying issues up front and solving the problem before coding begins. Documenting the user task flows during the design phase allows team members to walk through the tasks as the user, identifying available actions and uncovering places where the sequence doesn’t match the user model. Decision points are identified and subtasks mapped out, giving the developer a visual of not only what the workflow needs to allow but how flexible it needs to be.

Model the Data. Creating task flows that diagram the end-to-end tasks throughout the system generates a picture of how the software will be used and how the user will interact with the data. Developers will begin to identify how and where the data is needed throughout the application. In turn, this will help them structure and organize the data in a manner that supports the users’ needs, rather than having the user modify their behavior in order to support a theoretical data model that doesn’t match their reality

Identify Patterns. Task flows gives the team a wall of visuals representing various tasks throughout an entire application. Scanning the flows allows them to quickly identify recurring patterns throughout an application. This, in turn, lets development begin to address creating reusable components or extending existing ones to allow the flexibility of reuse throughout the application

See the larger picture. Documentation binds large teams together. The end-to-end flow isn’t developed linearly by one developer or even by one team. Instead, it’s broken down into features with various teams coding the stories for that iteration. Creating end-to-end task flows is the perfect vehicle for letting a developer see the overall picture of how an entire feature works and, more importantly, how and where their piece fits into the whole. For developers it’s no longer one story in isolation, but rather a relationship of their one story with entry and exit points that define the sequence.

• Digg
• Reddit
• del.icio.us

Comments (0)

user experience design

What are Task Flows?

Alice Toth, Tuesday, March 6, 2007 @ 9:38 pm

Task flows are a tool to help us think through the design before a feature is actually developed. They allow us to interject the user into the flow of the application and determine if the conceptual model agrees with the user model.

The Information Architect (IA) is generally the team member taking the lead on diagramming the user narrative. With the business requirements and user modeling taken into consideration, the IA determines the tasks needed for a specific feature and maps out how the user will accomplish the task within the application. The resulting diagram shows a series of actions the user must do in order to begin and end the task, which can be anything from uploading catalog data to generating reports to assigning rights and permissions to user accounts.

Starting with the initial flow, which is a high level concept flow for that feature, the necessary steps to initiate and complete the task are detailed and mapped out into the flow. From there, various iterations of the original diagram are created and expanded upon as more requirements become known. The end result maps out the different levels of complexity for that task once subtasks and parallel flows are identified and designed.

By placing the user into the process at this stage, the Information Architect and the team can determine up front whether or not the final task flows will meet the business requirements along with any system requirements and still make sense to the end user.

Updated: Attached is an example of a task flow. Click on the image to view it full size. For this particular project, we were displaying new functionality at the UI layer and the diagram was created to visually show all the different ways a user could arrive at this new feature. Not all flows are this complex.

• Digg
• Reddit
• del.icio.us

Comments (6)

user experience design

The Design of Non-Everyday Things

Bob Moll, Wednesday, April 12, 2006 @ 6:29 pm

Often as User Experience Architects, we are asked to bring the design process into new domains and complicated products that may have not been previously exposed to such a process. How can we, as professionals, achieve success in new and challenging environments? The answer is nothing new: Stick to the fundamentals. Don Norman listed them in his timeless classic, The Design of Everyday Things. As "Things" become more complex and more niche oriented, the principles still apply. Let's review a few of them.

First, keep the structure of tasks simple. A task may have many steps, and involve complicated data, but the structure can still be simple. Second, make things visible. If the user can't see it (or hear it or touch it), they probably can't use it. Third, design good error recovery mechanisms. The user should not be allowed to box themselves into a black hole they can't get out of. Finally, create and leverage standards. Think about the amazing complexities in road travel that are possible with a few simple standards of lights and signs.

Applying the fundamentals is the key to success in complex projects. Getting good with these timeless principles will make the complex manageable, and even fun.

• Digg
• Reddit
• del.icio.us

Comments (0)

user experience design