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.