Grant Consulting - The Simple Story

As discussed in an earlier article, many software and website projects fail. They end up vastly over budget, way behind schedule, or do not see the light of day at all. One reason why this happens is the constant pressure to complicate the project. The answer to the problem is the simple story.

By the simple story, I refer to a concise understanding of the work to be supported. Everyone on the project who affects the technology design should agree to and understand the simple story. The simple story covers the critical and common steps that customers will take. The technology design should support and enhance the simple story.

Technology: An enterprise system for a reseller of loans
Simple story: Customer service handling phone calls from individual borrowers

Technology: A web site selling books or music
Simple story: Customers buying a specific book or music album

(This simple story is satisfied quite well by amazon.com. Business challenges notwithstanding, amazon.com generally has been a successful site and provides an example of good design.)

Technology: A corporate web site
Simple Story: Potential customers visiting the site for the first time

Technology: A B2B site providing agents with quotes on financial products from multiple companies
Simple Story: Agents getting quotes for a customer

This last example reminds me of a meeting for that project. A number of business managers and information architects attended this meeting. They had been spending a good deal of time trying to figure out how agents would handle multiple sets of quotes and proposals for one customer, and also handle other entities called results, drafts, and saved quotes. I honestly can’t recall exactly what “results, drafts, and saved quotes” meant, and it was obvious that most people in the discussion had become unclear about it as well.

I asked the team what was the common use of this section of the site. In particular, I asked how often agents would deal with more than a few quotes and proposals for one customer. Despite some initially pained looks from the group, eventually we all acknowledged that the design had become over-complicated. The design strayed far from supporting the basic and frequent needs of the business. By spending a lot of time and attention on logically possible but unlikely circumstances, the site design had become confusing and unusable. The critical and common use of the site had become obscured. The simple story was lost.

In his book First Things First, Stephen Covey uses a wonderful metaphor about deciding priorities and maintaining focus. Suppose you have a bucket on a table along with large rocks, small rocks, and sand. To put as much of the rocks and sand into the bucket as possible, what would you do? For an exercise in frustration, first put in all of the sand. It will be quite aggravating to then try to squeeze in all of the rocks, especially near the end.

The best approach puts the big rocks in first, then the small ones, and then the sand. By putting the large rocks in first, you assure yourself that they will fit in the bucket. The small rocks and the sand fill in whatever space is left. If all of the sand does not fit, so be it; at least it wasn’t the big rocks.

How is this related to technology? Projects fail because they cram more into the design than they can handle. If a project can keep its focus on the simple story, it will be far more likely to finish on time and on budget. A technology design focused on the simple story will always allow the user to easily recognize how to handle the common and critical tasks.

This is not to say that other complications or circumstances can’t be supported; but they must be subordinated to the simple story. If additional features are added that undermine the basic purpose, the design or the decision to add the feature should be reconsidered. The important work to be supported must always be simple and clear. If it is not, then the risk of the project stalling out due to over-complication rises, and the likelihood that customers cannot work with the technology jumps dramatically.

In current software methodology, use cases can do a reasonably good job of capturing the simple story. (Many I have seen, though, suffer from being technical where they should not be.) Contextual inquiry offers the best way to understand how customers work, and to thus understand the simple story with confidence. User-centered design methods such as paper prototyping and usability testing do a great job beating the drum for simplicity by plainly showing everyone when customers cannot use the technology design for its basic purposes.

[1] Most of these examples are based on actual projects in which I have been involved. Details have been changed for the sake of confidentiality.

Written by Joe Grant
Posted on February 27, 2001