Teaching UX: Creating a Killer Proof of Concept (Part 1)

by Ryan Medeiros, Director, School of Web Design & New Media, Academy of Art University, San Francisco, USA

In this article series, I will explore the utility, structure, and design of the Proof of Concept through examples, stories and practical advice. I will also attempt to reveal tips and tricks about creating Proof of Concepts that my students and I have discovered over my 15 years of teaching User Experience.

In Creating a Killer Proof of Concept (Part 1) we will :

  • Define the Proof of Concept as a blueprint for your interactive project.
  • Introduce the need for a persona, or example person from your primary target audience.
  • Show how a user scenario sets up the background story and the current context for the Proof of Concept.
  • Define task statements that lead to desired results.

So let’s get learning!

A Proof of Concept is a Blueprint

It’s often said that “Rome was not built in a day,” and neither were any of the top mobile apps we use today. Like buildings and cities, interactive experiences need planning and a clear process for execution. And in the same way buildings need blueprints, mobile apps need a Proof of Concept.

The term Proof of Concept has a range of meanings. In a general sense a Proof of Concept is any representation that demonstrates how an interactive project will work. This can include sketches, diagrams, wireframes, prototypes, and coded experiments.

Here is an example of low-fidelity Proof of Concept.

For the purpose of this article, I define a Proof of Concept as a step-by-step sequence of images that represents how a user moves through a particular interactive experience. Other words for this are task flow and user flow.

It starts with a Persona

A persona is an imagined representation of a primary target user (for examples, do a quick Internet search for “User Persona”). Remember that the persona is a fictitious character. It's a common mistake to use a real person for your persona. This can cause confusion as this person often has specific characteristics, or needs, that fit outside of the model persona you're trying to create.

Think of the persona as an aggregate of the most important needs and characteristics of your primary target audience. Of course, you can, and you should, create personas that have different needs from your primary target audience (including some personas that have outlier characteristics). But in the beginning, focus on creating a persona that represents the most basic needs and core tasks of your project. Move on to more complex personas later. Add the persona to the beginning of the Proof of Concept.

Next, define the Scenario

Once you have your persona, next you want to create a user scenario (or story) for that persona. The scenario is a short story that sets up the background and the current context. The scenario should say why your user is interacting with your project.

Write 3 to 5 sentences of backstory and provide the current context — in terms of time and place, and the reason (or rationale) for using your project. Remember to keep it short, and pick your words wisely. From reading the user scenario, your audience should understand who the persona is, why they want to use the project, and what the context is for using it.

Every Proof of Concept needs a task

For a Proof of Concept to be effective it must be based on a task. A task is a series of steps that a user takes to achieve a goal. For instance, a user may want to search a list of restaurants, or check in balance on account, or update their profile information. Whatever the goal they have in mind is, that is the task. Ultimately the Proof of Concept is the visual representation of the task, showing how a user moves through particular task step-by-step.

It is important to connect the scenario to the tasks. Therefore your scenario should set up the context the tasks, and the tasks should reflect the scenario.

When starting a new Proof of Concept, it helps to define a small number of core tasks. I start students off by having them define only three tasks. I ask them to focus on identifying the most important task based on the user’s goals.

One of the best ways to capture tasks is to write them down in the form of a flowchart, or write each step in sharpee marker on a separate sticky note and then combine them to create a sequence of steps.

Defining “The Task”

Now that you have defined your core tasks, you want to write them down in simple statements. For instance you might write out the first task as “Task 1: search internships in my city,” the second task as “Task 2: select design internship, $25 dollars an hour,” and the third task as "Task 3: tap the more info button.” Notice that the wording of these tasks is very clear.

Avoid any vague task statements, as these will confuse your audience, or send them down complex paths without a clear goal in mind. Examples of unclear task statements include “Login and complete the first level,” or “Search for restaurants close to you.” While these statements seem reasonable at first glance, if you think deeply you'll notice that they leave a lot of information unexplained.

A Proof of Concept is a primary tool for user testing, so clear tasks will help your user testers understand exactly what you want them to do. The more clear you are about the tasks the easier it is for you to define, and visually represent, the step-by-step screens in your Proof of Concept.

Every Task needs a “Result”

There has to be a specific result for each task. While it might seem like overkill, I require students to write a sentence underneath the task statement that defines the result of each task. This reinforces the clarity of the task and allows your audience understand what exact results are desired for a particular task. For instance, if we were to write out the task statement “Task 1: search internships in San Francisco,” the result statement below it would read “Result: user arrives at the Internships/San Francisco list page.”

The “Proof” in the Proof of Concept

In a sense, the degree to which your task statements and results match up is the “proof” part of the Proof of Concept. When a particular task achieves a desired result it proves that the Proof of Concept is accurate.

User testing your Proof of Concept will reveal if your user testers can actually achieve the results you have defined for each task. It is almost never the case that your tasks achieve the correct results the first time. Or the second, or the third! And of course it should be like this. You create a Proof of Concept for this exact reason: so that you can test the tasks and results over and over, until they prove your concept.

Summary of Part 1

In part One we defined the Proof of Concept as a blueprint for your interactive project. It starts with defining an example person in your primary target audience, also known as a persona. This persona needs a scenario which sets up the background story and the current context. And every Proof of Concept needs a task (or series of tasks) which define the steps that user will take to achieve a desired result or goal.

In next installment

In Creating a Killer Proof of Concept (Part 2) we will :

  • Learn the importance of starting out with a low-fidelity design.
  • Understand the utility of clear page numbering and descriptions.
  • Use visual indicators to show where the user has tapped or clicked.

So let’s get learning!

About my column “Teaching UX”

I’ve been teaching web design for over 15 years, and I have helped hundreds of students develop interactive projects, mobile applications, and interactive art installations. And now I’m helping them define Internet of Things projects (wearables, physical computing, etc.) and expanding into VR/AR and Automotive UX/UI.

My students and I have experimented with the full range of User Experience design methods, techniques and models. And through this first hand knowledge, they have helped me develop and hone some core principles and methods of teaching, evaluating and designing exceptional User Experiences. I’m writing them down now in order to illustrate what has worked, and what hasn’t, over 15 years of teaching.

I don’t pretend to be the single expert on User Experience design or even that my methods are better. I only seek to illustrate what I have arrived at as a generally effective way for teaching UX. I also aim to demonstrate a successful process that students and instructors are welcome to apply, modify, or dismiss. Much of what you read here will be familiar as I owe so much to so many other teachers, authors, students, mentors and designers. Please feel free to point out references or sources if I fail to do so, or if you have something to add.

Happy designing,

Ryan Medeiros.