We’ve described the importance of a customer’s resulting experiences in defining value. But how do you capture, document, and share an experience so people in different functions across the company can understand how to improve it? If you were defining a product feature, it’s pretty easy to state a specification such as the user interface must support Internet Explorer
9, Firefox, and Chrome browsers. Explaining an experience that is superior to alternatives is harder.

There are a number of methods that provide parts of the answer but it’s very rare for them to be combined into a coherent process. Market requirements are intended to convey the details of a customer’s problem to the designer or developer. When these requirements are assembled, they become a Market Requirements Document. Unfortunately, they tend to be functionally oriented and don’t take into account the user’s circumstances, motivation or emotions. Even worse, they frequently abandon the user’s perspective and morph into a collection of desirable product features.

Use cases are a description of actions between a user and a software system which leads the user towards something useful. Sometimes these are illustrated in the form of use case diagrams. Use cases tend to be very functional, for example, the user clicks on this link and a second window opens. To help take the user’s perspective, some companies write personas. This is the technique of describing fictional characters that represent your different user types. Typically they are given names and an explanation of their educational background, professional responsibilities, skills, attitudes and goals. This makes it easier for people to visualize and empathize with the intended customer.

The broadest technique is a use scenario or a virtual video. This is a written description of situations from the intended customer’s life that are relevant to the company. A virtual video tends to be a long narrative describing an experience, such as having a software problem and exploring the various ways to get the problem resolved. It could include exploring a support site on the Internet, trying to call the support line, and having an on-line chat with a support representative. Virtual videos can describe either a current situation or an idealized situation in the future.

Few companies have templates and processes for documenting, storing, analyzing and sharing some form of a current or desired user experience in a systematic and repeatable manner. Do you have any feedback with methods that achieve this goal in your company?
6/14/2011 02:11:34 pm

Hi Miki,

I don’t have any methods that I can share with you currently, other than the ones you have listed above. (We have found best success, in my opinion, with the use scenarios). But you have hit the nail on the head. MRDs very often are completely devoid of the user’s experience, whether by design for the software developing company to capture a broader slice of the world market (and to do it more quickly, ala the Microsoft paradigm), or by lack of vision for, or insensitivity to, the user’s experience. Understandably, functionality usually trumps usability when pressed to get a product to market first, but too often usability never makes the central spotlight even in subsequent releases. It’s seen as an after-thought, a “nice-to-have” versus a “must-have”, as would be the case for some functionality.

Use cases definitely give a wider vision on the requested functionality, but still lack adherence to common principles of good GUI design. Often, there is not even a suggested UI in these documents, which can lead to software being developed in some tall, ivory tower in a remote corner of our “global kingdom” and its frequently-partitioned workforce: serfs, squires and vassals alike. Good product design comes from having well-connected functionality. Great product design usually involves a “GUI Czar” of some sort, one who oversees the entire software product line and who is intimately familiar with the user experience. Unfortunately, as software development resources are spread across the globe, the ability of one person or team to “herd the GUI cats” into one common usability format becomes more difficult.

We have all seen GUIs developed that are astoundingly clear & simple to use (think Google or Apple), and we have seen horrendous user interfaces that make you wonder: “Have the developers themselves ever tried to use this?!?” Simple GUI ideas like “progressive disclosure”, required fields in bold or optional ones in italics, and reading/using from left-to-right & top-to-bottom should make the world a better place, but even these decisions are at times left to some caffeine-infused developer on a late-night coding binge. Adding insult to injury, when the users complain about the usability factor, companies should abstain from the dreaded “Functions as Designed” response and really take to heart what this complaint means. It is vulnerability, a weakness a competitor could exploit.

The usability gap that opens between developers and customers is often widened by the thankless job of automating test cycles of this software, giving developers a false sense on the usability of their tool simply because they have run thousands of test cases through the functionality. But so far, nothing comes close to sitting down and using the proposed tool day-in and day-out for several weeks. That’s when software developers get religion. Drinking the Kool-Aid they’ve brewed for everyone else. Nothing can turn a software project around like having to do a mundane task manually several hundred or thousand times in a real-world context.

I know, for I’ve been on both sides of that aisle. Beginning my career on the software development side, I was convinced I knew exactly what the customer wanted, occasionally going beyond what the MRD called for. But only when I got out into the customer’s work environment as a software consultant did I really begin to understand how they use (and abuse) the tools.

It’s a fine line to walk, trying to get the functionality out there as quickly as possible but to make the user experience palatable. The Use Scenarios are probably our best bet going forward in trying to collect this information in the pre-development phase, but the explosion of online feedback has also offered very good course correction, provided the software developer is ready to listen and meet the usability needs of his clients as well.

--Rick Cook

5/28/2012 10:37:40 pm

Thank you for posting the great content…I was looking for something like this…I found it quiet interesting, hopefully you will keep posting such blogs….Keep sharing

8/5/2012 01:39:22 am

Nice to be visiting your blog again, it has been months for me. Well this article that i've been waited for so long. I need this article to complete my assignment in the college, and it has same topic with your article. Thanks, great share.

8/14/2012 11:38:34 pm

I really found very interesting about these topic because you have good content and unique thoughts on writing. So this might be useful to everyone. I really look forward some more updates. Thanks for sharing.


Leave a Reply.