Design Values: Complete Workflows over Long Feature Lists

by Lynn Miller on January 21, 2010

This is a follow-up article to John Schrag’s post on Design Values. The original post described the values we believe contribute to a healthy software design practice.  This post looks deeper into why we value Complete Workflows over Long Feature Lists.

As with the proceeding posts, stating that valuing complete workflows over long feature lists does not mean that we are against long feature lists. If you can get a long feature list added to a product and still maintain complete workflows – go for it!

However, implementing a long list of disjoint and disparate features does not serve the end-users well. Even implementing a list of coherent features is unacceptable if the final result doesn’t support a complete workflow. As in the image below, constructing walls and a door doesn’t make a livable house if there is no roof. I would think potential end-users of these houses would have traded off the windows-feature to get the roof-feature implemented.

Photographer: David Goldblatt
Incomplete houses, part of a stalled municipal development of 1000 houses.
Lady Grey, Eastern Cape, 5 August 2006

Long feature lists often result from gathering customers' proposed solutions. The customer requests, “I want a print menu” (a solution), instead of “I need to share my work” (a problem). But as Theodore Levitt of the Harvard Business School said, "People don't want to buy a quarter-inch drill. They want a quarter-inch hole."  If you implement features without understanding what the customer really wants, then you can end up with multiple solutions for the same problem, with none of them quite succeeding.

To get a complete workflow you need to understand what your customers end goal is. From this you can either design a complete solution that gets the user to where they want to go or you can identify the gaps that need to be addressed in your current solution.

The Kodak EasyShare digital cameras are a good example of understanding what users are trying to accomplish and providing a complete solution. Kodak recognized that their user’s end goal wasn’t to take pictures – but to share pictures. Their solution was to create an inexpensive digital camera that people could slip into a cradle, click a button, and share photos effortlessly through email. Kodak became the market share leader because of this.

Understanding your customers end goal isn’t very difficult. Talk to your customers about why they are asking for a certain feature, instead of blindly accepting the solution they propose. (Note: Their solution may turn out to the dead-on, but you are still better off if you know the reasoning behind adding the feature.) Try the 5 Whys technique – ask "Why?" until you get to the true cause of a particular situation or problem. Then you know that you are addressing the right issue – the one that will make your customers happy and won’t waste your development resources.

Comments

[Levi Csanyi]

The roof example is brilliant. The hole-drill example is also good (all the good design books use this example, but I still love it), but both example needs good balancing. Will I reject a window for a roof? I don't think so. There are set of minimum features what I need. After the minimum it is also a question of balancing what is more important.

Just some addition for the drill-hole example: standards. If there is a standard solution for something you need to explain carefully why do you give something different. If I need a drill no one try to sell me a laser, black hole, whatever. Drill is a standard and as a user I may need it. And people are slow and traditional and most of them are don't like new stuff - even the non-conservatives needs some stable point. So balancing again is important.

Kodak... I disagree. Maybe in the US it has the top market share, but it is not because the weak easyshare feature. Kodak has a name because of films for analog cameras. I do not know why they can sell any of its digital cameras - it can be a question of marketing, name, brand, resellers, whatever, but I am pretty sure the easyshare function is pretty unused. However easyshare function has a good name, but I tried to use that some years ago and when if I clicked the button nothing happened. However I can't imagine a good workflow for that, because I do not have email addresses in my camera - if it needs to synchronize with my mobile phone for my address book it is better to take a picture with my phone...

[Steve Johnson]

On a slightly less serious note, I have yet to go into a hardware store and ask for a pack of quarter-inch holes. And I'd walk right past the hole-supportive workflow solutions counter to go and pick up my drill. I don't go to the hardware store for holes, I go there for tools which I then use as I see fit.

Also, I own a Kodak EasyShare camera. I have never used the EasyShare workflow and never will. EasyShare played no part in my purchase decision-making process. My 80-year old mother also refuses to fit into the EasyShare workflow model, despite owning an EasyShare camera and docking station / printer, which sits gathering dust.

We both like the fact that the cameras have easily removed SD cards, allowing us to do pretty much what we like with our photos without having to conform to somebody else's carefully designed (and restrictive) workflow.

[Steve Johnson]

The trouble is, you have millions of customers with millions of different workflows. You can't possibly understand and cater for them all. By all means provide a set of tools thet supports a certain set of common workflows, but don't expect that you can cover anything but a small portion of your customers' needs with those workflows.

You also can't expect that if you design a set of tools for a given workflow, those tools are all going to be provided fully baked and working well together. Frequently, an unforeseen problem or insufficient development time leads to one portion of a workflow being half-baked or broken. Result? The customer can't use the workflow you decided that they needed.

So you still need to provide a wide set of tools, even if you can't fit those tools into a convenient workflow box. The best source of information about what those tools should be is the customer. Despite what I'm reading here, which appears dangerously close to "we know best", customers have a much better idea of what they need (not just want) than any software developer. True, some articulate their needs better than others, but the users are the experts on using the product, not the developers.

As for bloat, users certainly don't like that, but they absolutely loathe it when the bloat appears to be a result of developers adding stuff they haven't asked for, or even seen anybody else asking for. Recent AutoCAD history is replete with examples of this, and I bet they're based on carefully designed workflows that most users won't follow.

[Jean Foster]

Thanks for these articles Lynn and John. I agree completely that understanding user goals and identifying workflows are critical for creating useful and usable software features.

My favorite example of bad design and product bloat caused by long feature lists is MS Word somewhere around the Office '97 release. Being a Word power user since Word 2.0 I came to dread each new release, knowing that the features important to my work would be buried under more and more features that I would never use, some of which were just downright puzzling. Microsoft, realizing the problems users were having because of the feature bloat, added insult to injury by implementing the infamous disappearing menu items as a solution.(http://apcmag.com/microsoft_humble_pie_over_office_bloat.htm)

My favorite puzzler was the feature that allowed you to make your text look like marching ants! Where did this come from? My theory was that this came out of long lists of customer requests resulting from someone asking users what they would like added to the product, with marching ants being the equivalent of "kitchen sink".

A couple of years later I happened to be giving a talk at an event along with the director of one of Microsoft's HCI Research Labs and she confirmed my suspicions. The product features were driven by requirements lists gathered during marketing-led focus groups. She lamented that the HCI researchers were ignored when they suggested a user-centered approach to researching user's needs or warned against implementing features like Clippy. Since the development teams had no contact with how their customers really used the product, there was no way to prioritize such lists so the safe thing to do is just throw it all in, right?

The most dangerous thing we can do when conducting user research is ask users what they want, when we really need to understand what they need. And that is something the user generally doesn't consciously know or can't articulate. It's our job to discover user needs based on our research, understand their goals, and design the workflow necessary to realize them.