Part 3: Design Phase Kick off
Have you ever found yourself arguing with colleagues about your project getting out of scope? Have you found it difficult at times to incorporate great insights from meetings into the project? Project brief is the single document that can help smooth out a lot of the tensions around what the project is and how it should evolve.
At this point in my project, I was coming out of the exploratory research phrase; I had a persona, and had a good grip over what were the major needs that I was trying to meet. Right before I started designing, I put together a project brief that anchored down what I knew, and where I expected the project to go. I then sat down with my client, and went over the brief to get her input.
Structuring a Project Brief
- Mission: I like to keep the mission lofty, with an eye on the the potential for the project to evolve to something bigger. The mission needs to be uplifting and worthwhile, so it can motivate people to help it succeed. Here is what it looked like for me: “Support artists to access their work material more effectively and hassle-free.”
- Problem Statement: It’s a paragraph that spells out the pains and the issues that I discovered in my research. I also included a link to the persona.
- Project Goal: Unlike the mission, the project goal focuses on the concrete path for the current MVP. Here is the goal I am working toward in this project: “ How might we create a system for artists that use copic markers to keep track of their markers.”
- User Stories: I write user stories usually as a paragraph focused on a single issue that the persona faces. I write them from the user’s perspective, stating what they need and why. Here is an example of a user story from this project’s brief “As an artist I want to know the colors of copic that I own, their type and quantity so I can make sure that I have enough of the colors that I am using in my current painting so that I don’t run out of the colors in the middle of an art project.”
- Scenarios : For this part, I often do a little bit of analogous domain research, to get a sense of how similar needs are being met in other domains. Once I have an idea of the different steps involved, I first write down a paragraph, walking myself through the process. I, then, use that paragraph to come up with scenarios. Here is an example “User needs to be able to adjust (add/remove) quantities for each color code in the system”.
- Success Metrics: In this sections I describe tentative ways to measure the success of each user story. I include a reference to the original user story. Each user story may have multiple metrics. For example, “After viewing the onboarding, user can smoothly create an inventory”.
- Objects (Conceptual Model): This is a vocabulary list of the objects in the project. This way as the project evolves the team has a clear and common language to talk about the different parts of the platform.
- References: This is where I capture important notes from meetings about the project. I usually capture the notes in separate documents. Here I simply include a numbered list of links with descriptive titles.
- Resources: Links to any related material.
A project brief is a great way to keep track of how the project changes overtime. Whether you are adding new features, or changing the success metrics for a user story, you have a place to capture the changes. It is also a great communication tool, because it holds both the “what” and the “why”. So, you have all the information you need to resolve an argument, or onboard a new member.
A Word on Redundancy
Some may be tempted to think of a brief as overly redundant. But remember that you may end up sharing this document with a wide range of stakeholders, and each may really only refer to the section that’s relevant to them. So it is crucial to make sure that each section makes it easy for the reader to understand the “what” and the “why”.
Design Phase Kick Off Meeting
After completing the brief, I set up a meeting with my client with three goals:
- Review the brief
- Ideate the flow
- Ideate the design of User Story # 1.
Brief An important outcome of reviewing the brief was to split a user story into two. My initial user story for how artists find markers focused on finding a specific color. But my client, who is an accomplished artist herself, pointed out that there are times, like when she is at the supply store, when all she wants is to quickly tell what colors are running out.
Flow When you look up flows for apps, it is common to see that the entire flow is shown using actual screens. Some designers like to also ideate the flow of the app using screens. But, to me that means that you are creating actual screens while ideating the flow. I find it much more helpful to focus on one thing at a time in the initial phases of design. So, during our ideation session, I had us use only boxes and labels to capture the overarching flow of the app.
Sketching User Story # 1 The success or the failure of the app really hinges on User Story # 1. That’s why I found it crucial to start there. User Story #1 is where artists transfer their physical inventory into the app, and create their main inventory.
For any other User Story to be meaningfully addressed, the app must successfully collect what markers an artist has. If we make it too difficult to go through that transfer from physical to digital, nobody will bother to use the app. During the ideation session, we came up with a number of different ideas, from entering the color codes by hand, to selecting colors on the color wheel.
The most promising idea, however, was one that made the process of entering items hassle-free by using image recognition. Copic markers carry their name and hash on their cap. This means that an artist can scan in a bunch of colors all at the same time just by capturing their caps. After scanning, artists can see the list view of the markers detected and a picture of them. Markers on the image are connected to rows in the list, so that simply by tapping the image or the rows can check whether everything has been accurately captured.
I will further explore the main features of the app.
Part 1: What’s the big problem? Part 2: Exploratory research Part 3: Design phase kick off Part 4: Exploration of the design through low-fi Part 5: Iterating and finalizing MVP designs Part 6: From mobile to web