User Experience

Recent work on business plans and business cases refocused me on the need to document for a wide audience the purpose and design of a product, within the context of how it would be delivered to market and how it would prove profitable.  As I reflected upon this, it occurred to me that a concise package could be assembled that delivers all the information needed to evaluate a product.

I’m sure someone has thought of this before, and there’s probably a formal name for it, but I thought I’d document it while it’s in my head….and before I delete the email in which I decided to capture it.

1) What Problem is Being Solved: The overarching product summary should start with a definition of the problem(s) being solved.  From this definition, anyone reading this package can evaluate whether the proposed solution addresses the problem or problems stated.  Much expense can be saved by not delivering a solution to market that doesn’t address the intended problem.

2) Buyer and User Personas: Who is the primary user for whom a product is to be built, and who is the buyer actually responsible for the decision to purchase?  Often times these are not the same people–a proper user persona can identify the user’s tendencies and the typical person who will be using the product, whereas a buyer persona can help to keep the buyer’s motivations in mind.

3) Value Proposition: A succinct explanation of how the product can provide tangible, financial benefit to the user.  One method is to show the value of the time saved by elimination of manual steps, which can show the value of efficiency.  Increased revenue may be harder to validate, but using reasonable estimates can help to show the exact amount of value that a user will obtain by using the product.  This evaluation is helpful when it comes to pricing the product for the market, and should take into account how the solution solves the stated problem for the buyer and users defined above.

4) Solution Workflows: For a software product, no presentation of the proposed product is complete without a robust set of wireframes weaved together with a good story.  Packaging this all together helps answer “what are we building, exactly?” and helps build the case that the solution proposed is indeed the best one, for the conditions in items one and two above.

There are other items packaged in a business case — in particular, one that comes to mind is a pricing proposal — but the items listed here are enough to deliver to business people within a large software company to make the case that a particular product is solving a real market need for real users, and to explain exactly what product is proposed to meet that need.