Tuesday, June 24, 2008

Constructing a User Experience: The Cost-Benefits Compass

UX cost/benefit analysis described ...

"A common frustration among UX professionals who are employed in the software development industry is the perception that executive-level management gives lip service to user experience rather than supporting specific UX activities by allocating sufficient resources for them.

This perception is seldom a reality. Competent management does realize that the user experience is critical to the long-term health of their company. Unfortunately, when developing software, the temptation to steal from the feature-list cookie jar and try to squeeze just one more feature into the current development cycle by skipping UX work is simply too great for most Product Managers. This strategy, however nearsighted, can and often does make money in the short term by achieving a temporary increase in sales. The only way to win resources in this situation is to bring the discussion back to dollars.

This article tells you how to build a quick-and-dirty UX cost-benefits compass that directly ties persona efficiency to dollars. You can use this compass to focus UX efforts on specific activities that provide the greatest benefit, as well as justify increasing UX activities in general. It is often possible to construct a working UX cost-benefits compass by assembling existing data, and it’s easier than you might expect.

In this article, I’ll present a case study that explores the use of a UX cost-benefits compass in the development of a product called the Customer Portal (CP), which allows organizations to proactively manage customer inquiries by leveraging Web self-service. The CP is Customer Relationship Management (CRM) software that is distributed under the Software-As-A-Service (SAAS) delivery model and replaced an existing system my company, RightNow Technologies, designed about ten years ago.

The following steps outline a general approach to constructing a compass. These steps can work for many business models and industries—though you may need to modify the steps to construct an accurate compass for your organization.

Step 1: Focus on a single product.

My company delivers a single solution that actually includes over two dozen separate products. Rather than trying to boil the ocean and justify UX work to benefit all users of the entire solution, we focused on just one product—the Customer Portal. I recommend you focus on a specific product or project to work on first, because building on small successes is a reliable way of generating larger successes.
Step 2: Understand the persona ecosystem.

A product almost always has more than one type of user, or persona. A UX cost-benefits compass is most effective when you apply it to products employees use within an organization, but you can also apply it to products that have a more diverse audience.

We constructed our persona ecosystem during an earlier phase of the project and were able to reuse it for this analysis. Five personas use the Customer Portal, each of whom has a distinct role:

* user—A current or potential user.
* content owner—A customer-support employee who responds to inquiries and composes pieces of content for the Customer Portal.
* developer—A software engineer who is responsible for the back-end Web programming that supports the CP.
* designer—A graphic designer who is responsible for creating helpful graphics, diagrams, and other visual materials displayed in the CP.
* administrator—A member of the IT or Operations staff who is responsible for configuring the system to support the other personas.

If it is early enough in the planning phases of a project, you might not yet have had—or might not get—an opportunity to construct personas. However, it may be possible to construct draft or provisional personas in the interim that are based on existing data. For those of you in an organization with a more traditional engineering focus, you can use user classes in place of personas. While there are some significant differences between user classes and personas, both will work for the purposes of this analysis."    (Continued via UXmatters, Ben Werner)    [Usability Resources]


Post a Comment

<< Home

<< Home