ACM Interactions

There is a popular book in woodworking called Measure Twice Cut Once by Jim Tolpin. The title says it all. Make sure your measurements are correct and your woodworking piece is sure to fit together and you will not waste wood. The book is described as the following: "From design and layout to developing a cutting list, easy-to-follow style introduces a variety of tools (new and old) used to transfer measurements accurately to the wood. You'll learn the best cutting techniques, how to prevent mistakes before they happen." 

The theory goes that no matter what you are designing a good process will yield a good product. However, for several years now I have noticed that one crucial part of the process is commonly being skipped: the creation of task flows. This is the measuring, the crucial step to prevent mistakes before they happen. 

But why are task flows being skipped, how is the value of them being missed, and how can we promote them better? Over the years I have watched countless development organizations and product managers wiggle, sigh, eyes glaze over, and barely contain their frustration while I have asked them to painstakingly humor me in creating task flows. 

"We all know that this is the task that needs to be accomplished and how it's accomplished," is one common defense that I often hear. I could reply with, "But all my friends are doing it," but somehow I don't think that will help. I explain that I don't necessarily know all the tasks and the correct order in which they need to take place or all the variations in the tasks that might occur. The initial time involved tends to make non-designers impatient. Sure, it can be a tedious task in and of itself, and the time needed to define the task flows can feel like a waste of time when you don't understand the results they produce. 

I am a planner, and I think that spontaneity is great, just not for the practical aspect of planning software. Do you drive to an unknown destination without a map and hope you get there or do you plug the address into a maps program and shoot for the shortest distance possible? This saves time and gas, which can all equate to money. 

How does an architect quantify blueprints and how is it that developers architect the code but not the experience? Perhaps if we can quantify the cost of not producing the task flows, then maybe it would not feel like such a painful task, knowing what pains and what financial loss will be avoided in the end. How many pieces of wood were wasted and what was the cost? This is a very tangible quantification. 

So why do other industries and more so, other domains within software, understand this and yet software can't seem to understand the importance of task flows in design? This may be understood in theory but people just can't find the patience to put it into common practice. 

When a task flow for one core feature is not produced, the results can range from missed steps that are critical, to entire scenarios that are missed. Missing these can have huge repercussions. You know the ones. The ones where silence falls over the room, deep breaths are heard and the new plan on how to address the issue, which may or may not include a task flow, is launched. Complete with compromising other features, development resources, and perhaps even pushing out dates. These things happen. However, like a piece of wood, if you measure twice and cut once it would be like walking through scenarios and task flows twice and maybe developing only once. Imagine the issues and the innovative ideas that you might be passing over. Imagine the savings and of course imagine great software!

Monica Granfield