Skip to content
This repository has been archived by the owner. It is now read-only.
Permalink
Browse files

add content

  • Loading branch information...
Nick Brethauer
Nick Brethauer committed Oct 28, 2015
1 parent 2ca96ec commit 1c93c995d1474871c0b76e8c329452259b0786ce
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
@@ -0,0 +1,13 @@
---
permalink: /1-discovery-research/
title: 1. Conduct discovery research
---
Before you go any further, do some research to discover problems that need solving. Consider doing one or more of the following with both stakeholders and possible end users:

>- [Bodystorming](https://methods.18f.gov/bodystorming/)
- [Cognitive walkthroughs](https://methods.18f.gov/cognitive-walkthrough/)
- [Contextual inquiry](https://methods.18f.gov/contextual-inquiry/)[](https://methods.18f.gov/bodystorming/)
- [Heuristic analysis ](https://methods.18f.gov/heuristic-analysis/)
- [Stakeholder and user interviews](https://methods.18f.gov/stakeholder-and-user-interviews/)
Your goal is to identify the challenges both groups face and the relationship between the two groups. Focus on the problems stakeholders have, not the potential solutions.
@@ -0,0 +1,14 @@
---
permalink: /2-problem-statement/
title: 2. Write a problem statement
---
Gather your research and use it to create a problem statement. Describe ways that you will know (or measure) when you have solved the problem.

Your turn: Write your project’s statement in the following format:

>We have observed that **[product/service/organization]** isn’t meeting
**[these goals/needs]**, which is causing **[this adverse affect]**. How might we improve so that our
product/service/team/organization is more successful based on **[these measurable
criteria]**?
If you have trouble writing a narrow problem statement, brainstorm all the project’s possible goals, needs, and measurable criteria first. Then work as a group to select the most important ones and build your problem statement from there. It is likely that this process will reveal multiple problem statements. Your team will need to work to figure out which problem to pursue, and an appropriate way of scoping the statement so that there are some constraints on what the team is taking on.
@@ -0,0 +1,29 @@
---
permalink: /3-identify-assumptions/
title: 3. Identify your assumptions
---
Your problem and ideas about how to solve it are based on a set of assumptions. Lean UX is all about surfacing and testing those assumptions. Before diving into deciding what to test (building hypotheses), it’s important to consider all of your project’s potential assumptions.

Your turn: Thinking about your problem statement, map out all the assumptions you have (everyone should contribute, and no ideas should be rejected) about needs, users, and potential solutions. These are suggested brainstorming questions that help get at some common assumptions:

###Needs and solution assumptions

>1. I believe my users have a need to:
2. I believe these needs can be solved with:
3. I believe the #1 value a user wants to get out of my service is:
4. I believe the user can also get these additional benefits:
5. I believe I will acquire the majority of my users through:
6. I believe my biggest product risk is:
7. We will solve this through:
8. What other assumptions do we have that, if proven false, will cause our project to fail?
###User assumptions



>1. Who is the user?Note: Now would be a good time to conduct a [persona creation exercise](https://methods.18f.gov/personas/).
2. What problems does our product solve?
3. When and how is our product used?
4. What features are important?
5. How should our product look and behave?
@@ -0,0 +1,12 @@
---
permalink: /4-select-assumptions/
title: 4. Select assumptions
---
Now we select the assumptions we need to test. Identify assumptions above that meet one (or more) of the following conditions:

>- **Core assumptions**: Any assumptions that must be true for your solution to fix the problem (as listed in your problem statement).
- **Unknown assumptions**: The ones your team is most unsure about — in order to learn quickly about possible risks.  
- **Risky assumptions**: Assumptions that — if proven wrong — would cause the project to fail.

Your turn: With your team, read through your assumptions above and highlight those that are core, unknown, or risky. Tip: It may be helpful to have each team member do this activity individually, then come together for discussion.
@@ -0,0 +1,49 @@
---
permalink: /5-develop-hypotheses/
title: 5. Develop broad hypotheses
---
When we want to test an assumption, we make it into a hypothesis. Building hypotheses will also help to expose gaps in your thinking.

>Your turn: With your team, take the prioritized assumptions from step four and use those raw materials to start building your hypotheses in the table below. At this point you will need to brainstorm metrics you will use to test whether it is true or false *(Tip: Look at the adverse effects in your problem statement)*. Pay special attention to areas where there are gaps, as these will often indicate hypotheses that need more thought and development.
<style type="text/css">
.tg {border-collapse:collapse;border-spacing:0;}
.tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
.tg .tg-yw4l{vertical-align:top}
</style>
<table class="tg">
<tr>
<th class="tg-yw4l">We believe that (doing/building/creating this)</th>
<th class="tg-yw4l">For this user/persona</th>
<th class="tg-yw4l">Will result in (this outcome)</th>
<th class="tg-yw4l">We’ll know we’re right when we see (this signal / metric)</th>
</tr>
<tr>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
</tr>
<tr>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
</tr>
<tr>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
</tr>
</table>









@@ -0,0 +1,43 @@
---
permalink: /6-prioritize/
title: 6. Prioritize broad hypotheses
---

With your product owner and any other stakeholders, identify 3-5 of your top priority hypotheses. Consider a technique like [dot voting](https://methods.18f.gov/feature-dot-voting/).

Your turn: Copy your top 3-5 hypotheses into this chart.

Top Hypotheses
<style type="text/css">
.tg {border-collapse:collapse;border-spacing:0;}
.tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
.tg .tg-yw4l{vertical-align:top}
</style>
<table class="tg">
<tr>
<th class="tg-yw4l">We believe that (doing/building/creating this)</th>
<th class="tg-yw4l">For this user/persona</th>
<th class="tg-yw4l">Will result in (this outcome)</th>
<th class="tg-yw4l">We’ll know we’re right when we see (this signal / metric)</th>
</tr>
<tr>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
</tr>
<tr>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
</tr>
<tr>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
<td class="tg-yw4l"></td>
</tr>
</table>

@@ -0,0 +1,45 @@
---
permalink: /7-break-down/
title: 7. Break down hypotheses
---
You may have a mix of hypotheses at this point: Some call for building or prototyping software, and some may call for other actions that are not software-related. It’s important to break all of your hypotheses down into more specific, actionable sub-hypotheses that can be tracked in your project, but you may decide to separate your non software-related hypotheses out and track them separately.

>__For example, this broad hypothesis__:
“We believe that building a website will result in better citizen engagement with our program. We’ll know we’re right when we receive more contacts from citizens.”
>__Might break down to:__
“We believe that creating a way for citizens to easily contact our bureau from the homepage of our website will result in better citizen engagement. We’ll know we’re right when our daily contact volume goes up at least 10 percent.”

Broad hypotheses should be broken down enough so that individual team members have a good starting point for generating their own specific solution ideas, but general enough that it isn’t too prescriptive. For example:
__Good:__ “A way for constituents to easily contact their senators.”
__Not good (too prescriptive):__ “A text input field with a button people can click that sends their message to their senator.”

>Your turn: Break your hypotheses down into more specific sub-hypotheses. We recommend bringing your newly-created sub-hypotheses into a new Trello or other story-tracking board as cards in a “story candidates” list (see example below). Keep your broad hypotheses somewhere else where the team can refer back to them (for example in this document or another project management tool).




__Example of Trello board backlog labeling__

<style type="text/css">
.tg {border-collapse:collapse;border-spacing:0;}
.tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
</style>
<table class="tg">
<tr>
<th class="tg-031e">Abbreviated story description on card front</th>
<th class="tg-031e">Full hypothesis on the card back</th>
</tr>
<tr>
<td class="tg-031e"><img src="{{site.baseurl}}/images/trello_labeling_abbr_story.png" alt="Abbreviated story description on card front"></td>
<td class="tg-031e"><img src="{{site.baseurl}}/images/trello_labeling_full_hypothesis.png" alt="Full hypotheses inside the story card"></td>
</tr>
</table>





@@ -0,0 +1,13 @@
---
permalink: /8-groom-backlog/
title: 8. Groom the backlog
---
With many hypotheses to tackle now listed on your issue-tracking board, it’s time to prioritize again. Divide your content in three Trello columns:

1. One column where for incoming feature ideas. This column could be called __story candidates__ (using agile terminology) or __all hypotheses__ (lean startup terminology).
2. One column for features that we would like to see in an “ideal” future version of the product (think two or three releases ahead). This could be called the __product backlog__ or __hypotheses for entire product__.
3. One column for hypotheses to test that would comprise the first release, the minimum viable product (MVP). This could be called __release backlog__ or __hypotheses for MVP__. This should consist of the most essential hypotheses, that if pursued, would deliver value to the primary set of users.

<img src="{{site.baseurl}}/images/groom_release_backlog.png" alt="Prioritizing the stories into groups">

>Your turn: The product owner and project lead should order stories in the candidates column from most important to least important. Then, they need to decide which stories should be moved to the product backlog, and finally which make it into the release backlog.
@@ -0,0 +1,60 @@
---
permalink: /9-plan-sprint-agile/
title: 9. Plan the sprint and kick off the agile cycle
---
__Lean is the “brain” in the agile process__
Agile on its own is good at managing the delivery of working code at the end of every sprint, but it does not help you ensure that you’re building the right thing or solving the right problem. That is where lean comes in and acts as the “brain” on the agile process: Everything you do or build in a sprint is an experiment — with the focus on learning whether the thing you are building gets you the outcome you were expecting. Therefore, your user stories take the form of hypotheses. At the end of each sprint, the team reflects on what it learned, makes an adjustment, and starts a new experiment. The team and client __must__ be willing to adjust, pivot, or discard, or it isn’t really an experiment.


Your turn: Conduct the following steps during each agile sprint:
_For more in-depth reading on 18F’s Agile principles & practices, see [this guide](https://pages.18f.gov/agile/)._

###Just before the beginning of the sprint:

__1\. Groom the backlog__
>Who: Product owner, project lead, team optional.
What: Order hypotheses (stories) by priority in the appropriate backlog.
###At the beginning of the sprint:

__2\. Plan the sprint__
>Who: All! (PO/PM/Team)
What: Bring stories into the sprint backlog. Team defines and volunteers for tasks, and write acceptance criteria (for example user outcomes, basic functionality).
__3\. Hold a design studio__
>Who: All! Including PO. Everyone must sketch.
What: Design studios are a means to iterate through ideas, allow the entire team to have input into potential solutions, build shared understanding, and break down hypotheses.
###During the sprint:

__4\. Build.__ As work starts on tasks in the sprint backlog, move them to a “working” list. When they’re completed, move them to the “acceptance testing” list, to indicate that the story is ready for acceptance by the product owner. In lean UX, we try to define acceptance criteria for a story as a mix of both basic functionality (the thing “works”) as well as the desired outcomes for the user (for example “Users X are able to easily export data into their workflow).  

<img src="{{site.baseurl}}/images/during_sprint_build.png" alt="Work in progress during a sprint">

5\. __Research:__ As the features that test each story are built, get out of the building and test them with users.
>Who: Include team, POs whenever possible.
What: Conduct sprint user research that simultaneously tests against desired outcomes from current sprint hypotheses and explores questions necessary for future sprints. Check out [some of our design method cards](https://methods.18f.gov/validate/) for a variety of ways to evaluate your product’s features with users.
It may be helpful to create a separate Trello board (or document) for capturing — and easily sharing — user research findings. Here’s one example:
<img src="{{site.baseurl}}/images/research_backlog.png" alt="Example of how to capture user research in trello, in a hypothesis format">

###At the end of the sprint:

__6\. Synthesize the results of user research with the team.__
>Who: Include team, POs whenever possible.
What: Ask everyone what did we learn? Do we need to adjust? As insights and new ideas come about, put them into the “story candidates backlog,” so they can be prioritized in a future sprint.
_Tip: To keep track of story candidates that arise from research, it may be helpful to use color labeling, or create a second list of research-driven story candidates in your main project board, like this:_
<img src="{{site.baseurl}}/images/integrate_research.png" alt="Example of how to integrate hypotheses from user research findings into your project board">

__7\. Hold a sprint review__
>Who: The whole team, and any stakeholders who would like to observe.
What: Demo the completed stories, and review the key sprint findings: What was learned? What hypotheses were proved or disproved?  What will we try next?


##What’s next?

Based on what the team learned learned, you may need to come up with new or different hypotheses about how to go about getting the desired outcome. Or, if you’ve achieved your desired outcomes, you may move on to the next set of priority stories in the backlog to tackle. Repeat the sprint cycle, always with the focus on learning.

As the project progresses, its the job of the project lead and product owner to also make sure that the focused hypotheses of the sprint are feeding back up and informing the broad outcomes and goals for the project.

This file was deleted.

Oops, something went wrong.

0 comments on commit 1c93c99

Please sign in to comment.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.