Good Sh*t

Sprint 1: Design Week 0 🤔

For Design Week 0, we started our project with the Lean UX Canvas. While this step doesn't always occur, it provides designers a week to create a layout before sprints begin. This allows them to get into the process of building, testing, and measuring our assumptions.

According to Gothelf and Seiden, the writers of Lean UX: Designing Great Products with Agile Teams, the Lean UX canvas is a set of exercises which enables a team to declare what their assumptions are about a product, and it allows them to determine the current state of the product to its desired future (33-35). Using this canvas, it helped our team build a foundation of assumptions for our product, and it will give us a sense of direction that will soon be validated in the future.

Lean UX Canvas 1: Business Problem

The first step in the canvas is to determine our product problem statement. To do so this, we had to make assumptions as to how the company, Good Sh*t, would work. This allowed us to determine a vision for the product, pinpoint the domain we are working in, identify the current state of health tracking apps, how these current apps have failed, how we can address this gap with our product, and who our target audience might be.

Lean UX Canvas 2: Business Outcomes

Next, we identified our success metrics. We did this by determining what our impact metrics and outcomes would be. This meant making assumptions to how the product would work. As a team, we completed an “outcome-to-impact mapping” exercise where we made assumptions about how we will know if our designs are “successful”. To be specific, this means first determining what business-oriented impact metrics we might have (e.g., profitability, growth, customer satisfaction, customer acquisition and/or retention). Next, our goal was to figure out the kind of behaviors that we can observe/measure which will indicate if we were going to achieve our impact goal.

Our Metrics 📏

During this step, we determined the first (lagging) and second (leading) order metrics to determine how it may lead to those business-oriented impact metrics that we would hope to achieve with our product. For instance, we determined that to gain Revenue from the app, customers would apply for our annual subscription features and/or request online doctor consultations.

Lean UX Canvas 3: Users

Afterwards, we needed to determine the types of users and customers we should focus on. During this stage, we created 2 proto-persona, which is a persona that is based on the team’s collective assumptions, of who will use our product. However, these proto-personas were created without much research/evidence, and they are subject to change as we gain more knowledge. Essentially, they are living documents that lists the user’s goals and needs, and they will continue to change throughout the course of our research.

Our Initial Proto-Personas

Lean UX Canvas 4: User Outcomes & Benefits

Once we established who our users will be, we determined why they would want to seek out this app. This will give us an idea of what our users will hope to gain from our product, and we identified behaviors that would help indicate whether or not they achieved their goal. The following are some examples of how we did this:

Lean UX Canvas 5: Solutions

Now that we identified the problem statement, determined our users, and what our users hope to gain out of this product, we are seeking solutions for them. To do this, each of us wrote solutions on sticky notes in FigJam, and we looked for patterns between them. Ideas that were similar would soon be grouped together. While these are all assumptions, we brainstormed solutions that could potentially serve our proto-persona and create the desired outcome for our app.

Thinking of Solutions 🧠

While looking at the information we had, we thought of some solutions and saw patterns amongst our sticky notes. For example, some of our clusters consist of: calendar logging, potential diagnoses/tips for users, customization features, and more.

Lean UX Canvas 6: Hypotheses

We would now take all of our assumptions from the previous steps to create hypotheses that make sense. While these will not be accurate, we can make them accurate over time. This is to help us test assumptions. We can turn these hypotheses statements into a product backlog, which is a list of features we would add to our project, that will help us determine what we need to do.

Creating Hypotheses Statements 🔨

For instance, we essentially used the following structure: We believe that [business outcome] will be achieved if [proto-persona] can achieve [a desired user outcome] with [this feature].

To help visualize this, I included an image of what some of our statements look like.

After we created our hypotheses table, we mapped each hypothesis based on how risky they are with a hypothesis prioritization canvas. This allowed us to assess which features we felt like should be prioritized with its associated risk.

Lean UX Canvas 7: What do we need to learn first?

Afterwards, we took our hypothesis statements, and we prioritized them based on most to least amount of risk and value. This was important to identify the riskiest hypothesis statements because it would determine which ones we needed to work and learn about first.

Prioritizing Our Hypotheses 💭

An example of prioritizing our hypotheses was how we felt that the riskiest feature to implement into the app was our users receiving doctor treatment and prescribed medications.

We felt that it might be risky because it will be difficult to get involvement/permission from doctors as well as complications with insurance. There is also a greater liability with treatments and prescriptions involved.

Lean UX Canvas 8: MVPs and Experiments

Now, with our hypotheses, we need to create Minimum Viable Products (MVPs). MVPs are experiments to learn a particular thing, and it’s the least amount of work that we need to do to learn that thing and move forward. During this step, we had to figure out some potential design experiments that we can use to learn fast whether or not our riskiest assumptions would work. Thus, for each hypothesis, we would state what we would design and how we will test it. For instance, with allowing our users to receive doctor treatment and prescribed medications, we determined that we should create a doctor consultation tab that contains: schedule an appointment, view past prescriptions/treatments, and past visits (including documentation from the appointment). We would measure the success of this feature by the users’ activity on these sets of screens.

Sprint 1 Backlog

With the completion of our product backlog, we narrowed down our focus and selected several hypothesis statements from it. We selected these based on the risk, value, and whether or not it was feasible to create within our timeline. These statements would then form our sprint backlog, which will determine what we will be working on for our first sprint.

After the Sprint 1 backlog was set, my team and I delegated each other various tasks to complete from it. I took on the doctor consultation feature which includes the medical screen, scheduling, and editing an appointment with a doctor. However, we also had doctor treatment and prescribed medication, so my team member decided to work on that feature. We took into consideration that our two features are likely to overlap, so we built our screens to accommodate it.

Sprint 1: Design Week 2 🔎

As we modified and updated our wireframes, we wanted to primarily focus on usability testing. This is to ensure that before we move onto the next sprint, that the elements on our prototype for Sprint 1 are functional and if it aligns with our users’ mental model for the app. We reached out to one participant that we had from the previous week and two new participants. During these testing sessions, we gave our users the ability to roam around the app, and they would tell us their initial impressions and thoughts. We would base our questions based on their impressions, how they interacted with it, and what they liked/disliked. This information allowed us to test out our assumptions and if needed, it determined whether or not we should pivot from the direction we were heading.

Sprint 2: Design Week 1 🏃‍♀️

For this week, we started to work on tasks from our Sprint 2 backlog. Additionally, similar to the previous sprint, we continued our stand-ups and conducted usability tests with three new participants. Following each interview session, we did affinity maps to look for patterns, and we continued to modify our low-fidelities.

Final Design 🎨

My team and I were able to create Good Sh*t, a gut health tracking app, within 8 weeks. After conducting research and designing this app, we created a project that we are all proud of.

Screens I Designed

The following are the screens and sections that I've designed for the prototype: