Capstone Project: Concept Definition

This week, my team put our testing on hold and focused instead on concept definition. Reflecting on last week’s testing and feedback, it was clear to us that our concepts were anything but clear. We needed to define for ourselves exactly what our concepts are by setting a declarative point of view, before going forward to determine whether our point of view has value to our users.

To clarify and define our products, we started with a process of writing down all the things we believe have to be true about each concept in order to take them forward. We then wrote down all the questions we have about each concept, from large questions regarding user adoption – Will users take the time to input information in this app upfront?to small practical questions, such as – How many volunteers would we need to host a storytelling event?

From that long list of questions, we identified a handful of core questions that would need to be answered first, because the concept itself relies on those particular answers. For example, before How many volunteers would we need to host a storytelling event? we need to answer Can we recruit storytellers to sign up to tell their stories to an audience? Without storytellers, there’s no need for volunteers, because we don’t have an event to host.

A key aspect of concept definition is a competitor and market analysis. We needed to see what other products and services already exist in the world that are similar to what we want to create, whether as direct competition or as a similarly structured product for a different audience. From an impact perspective, we want to understand what perceived value the existing products and services provide to users. We also want to know in what ways these products are solving the users’ problems, and what aspects or features, if any, are missing, so that we can integrate or otherwise address those gaps. From a business perspective, we want to understand how similar services operate – what their business models are, how they reach their target audiences, how they’ve scaled, etc. so that we can start to better understand how we can take our concepts and turn them into real, viable products.

Another method we’re taking to help refine and bring clarity to our concepts is to make service blueprints. These are low-fidelity drafts, intended to help us start to make more sense of every touchpoint a user will encounter with a particular product or service over time and what actions are being taken ‘behind the scenes’ as a user makes that journey with our product.

PK-service blueprint 1

From this process, we start to see areas where the interactions are unclear, and which aspects of the product or service need more definition. We start to uncover what work will need to be done on the back end to enable the user’s interactions and what systems need to be in place for a user to have a smooth journey from initial discovery to an ideal future state of long-time use. We can also identify pain points in the user’s journey at this early stage, and work to overcome those potential gaps to make the user’s interactions seamless.

PK-service blueprint 2

You can see in the low-fidelity service blueprint for a storytelling presentation series that we are developing, that we’ve used bright pink sticky notes to call out potential failure points in the service. We can then address these pain points early on, and create structures within the service that diminish them or alleviate them entirely.

We’re currently in the process of answering the core questions that we have about each concept through competitor analysis and research. This coming week we’ll take those answers and test them with potential users in order to validate (or invalidate) our assumptions and refine our concepts as necessary.

We’re also reflecting on our initial service blueprints to determine which areas of our proposed products need more definition and clarity. Through concept definition, we’re moving from a broad, hazy understanding of what we could create to defining exact, definitive boundaries about what we intend to create. We also have a vision of how our users will interact with our products, and how they solve our users’ problems not just through a single interaction, but over time.