During my time as a UX professional, I’ve worked on a number of new products. All of these products began with an idea, and when we were smart, we spent some time defining and refining that idea to build clarity and to make sure we were all on the same page. But a good idea alone wasn’t enough. We needed a vision – a picture of how this product would make the world a better place for our customers (and for us).
But what is a vision? Visions are nebulous – unlike wireframes or comps or specs or code, they don’t have a clear form. There’s lots of advice out there on what qualities make up a good vision (Simplifying! Engaging! Unequivocal! Unifying!) but not much on what you need to actually make.
Great product visions are usually composed of three types of artifacts. They are the business case, the proof of concept, and the context scenario. Usually, all three are required for a successful vision.
The business case describes why customers will want this product and how it will help your business. Some successful business cases contain lots of market research results and projected revenue. Others make no revenue claims, but instead describe how the product will put the business in a stronger position to make money through other means. The goal of the business case is to define how the product will create new business opportunities.
The proof of concept is a technical prototype that proves that the vision is feasible. It explores some of the biggest technical challenges to implementing the vision and demonstrates how those challenges will be overcome. After seeing the proof of concept, stakeholders and team members should be convinced the vision can be built.
The context scenario describes the product as the user sees it. It focuses on the parts of the experience that make up the product’s core value. It aims to be realistic, but deliberately avoids secondary workflows and edge cases. It can take many forms – full-fidelity prototypes are usually best, but storyboards, comics, wireframes, and even prose scenarios can work for some visions. After seeing the context scenario, stakeholders and team members should understand how the product must feel to the user.
When visions I’ve worked on have fallen short, one or more of these artifacts was weak or missing. In the past, teams often overlooked the context scenario, although with user experience’s rise in visibility and influence this is fortunately changing. But all three are equally critical. A vision without a context scenario often leads to an undesirable product. A vision without a proof of concept may be seriously compromised when it encounters engineering realities. And a vision without a business case may never make enough money to justify its continued support – in smaller companies, it might even cause the entire business to fail.
Folks often try to combine the proof of concept and the context scenario into a single artifact, usually a super-high fidelity prototype. Although there are cases where this can work, in general it’s a mistake. Both artifacts may be prototypes, but they have very different goals – a context scenario must accurately portray the user experience, while a proof of concept must realistically engage with the biggest implementation challenges. Including debugging controls or placeholder artwork is perfectly acceptable in a proof of concept but is unacceptable in a context scenario. Likewise, faking the results of complex algorithms is perfectly acceptable in a context scenario, but may be unacceptable in a proof of concept.
When building a product vision, consider whether you have all three of these artifacts in place, and whether each has received the time and attention it deserves. In some cases, you might be able to skimp in one area – perhaps the technical risk is minuscule, or the business value of the product is obvious. But all too often I’ve encountered the opposite problem, where a little more investment in the business case, proof of concept, or context scenario in the visioning stage would have headed off big headaches down the road.
