What the stakeholders and end users don’t want is just as important as what they do want. This is especially true of upgrades or enhancements to existing systems. It’s common to get caught in the flow of the existing design and to just keep doing more of the same.
Here’s an example.
Let’s say your company has a retail website. Customers register, place orders, track purchases, etc.
The site stores lots of information about customers and tries to make it easy for returning customers to place new orders. The site also displays ads both to entice people into buying products they haven’t tried before and also to show them what other products are available on the site. There are occasional pop-up ads in key situations.
Now the site wants to add a new feature — the ability for returning customers to reorder items that are used regularly such as paper products, toiletries, cleaners, etc. Multiple user stories will be needed to map out all of the features needed, of course.
Subtle differences really matter.
There will be a natural tendency to build the new re-order feature around all the existing operations of the site. Yet, there is a big difference between browsing for products and re-ordering products.
When browsing, shoppers like to see many items in a category and they like to compare and contrast them. Many will appreciate ads and even pop-ups as those elements help them learn more about the products they are interested in. Shopping becomes a learning and entertainment experience.
However, when re-ordering standard consumables like photo paper, toothpaste or hand soap, simplicity and speed are essential. If the shopper wants to browse for equivalent products, the site already lets her do so. If she wants to order something she has ordered before, the software needs to offer a different user experience.
This is where many things can go wrong. The software developers are likely to add the new re-order features to the existing site paradigm. This will include the pop-ups, ads and other design elements built into the site. While technically correct, this will result in a re-ordering process that is slow and cumbersome.
Consider all the angles.
The returning shopper likely wants to see a list of items purchased previously with the ability to select one or more and add them to a new order. As software system experts, we need to avoid the trap of simply doing more of the same. Deliver what the user wants and needs — not more, not less.
Explore new user stories from multiple angles to uncover what really matters. Here’s how:
- In addition to asking what the user wants to accomplish, ask what she doesn’t want.
- Probe for hidden assumptions built into every story. What is the user assuming? What are you assuming?
- Ask for examples of similar functionality. If they don’t exist, go the whiteboard and diagram the story.
Give it try. The key takeaway is to analyze each story from multiple perspectives. The better you understand what’s needed, the better the implementation will be.