# For your toolbox
This is the [FAST](https://futuring-architectures.com/) manual to validating platform propositions. It will be your companion in building a platform's structures and systems: for your current organisation, a strategic partnership, or a greenfield endeavour.
The manual comes with all the instructions you need to start facilitating fruitful platform collaborations. No consultants or coaches, no boot camps or certifications. All batteries included; just add elbow grease.
All contents is available free of charge under a [Creative Commons Attribution-Share Alike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/). Use, share, adapt as you see fit:punch:
# Introduction
This Organise workshop is a follow-up to the [Reveal ](https://reveal.futuring-architectures.com/)and [Position ](https://position.futuring-architectures.com/)platform workshops and the final instalment of the FAST trilogy. It is organised in such a way that teams can either do the Lite or Full version, depending on their goals and time. The Lite version results in a Storyboard with drawn screens and gives a concrete view on what the MVP will be, which is suitable if teams just want to take it one step further than with the Position workshop. On the other hand, the Full version also prototypes and tests the MVP so the team could really start validating their platform afterwards. This last part could potentially also be outsourced to third-parties as the Storyboard should be sufficient to build and test a prototype.
The goal of this workshop is to validate the platform model with a simple prototype, not to build a complete product. It should be run with 4 to 7 participants and preferably at least 2 facilitators.
In this book, we take you on a journey and walk together past all the exercises and see how they are applied to our leading platform example Airbnb. You'll get a full explanation of the exercises to be able to directly apply it to your own context.
The Platform Design Sprint is an adaption of the Design Sprint 2.0 as taught by AJ SMART. Their course is found at . Our aim was to keep the Design Sprint process as unmodified as possible as this enables an experienced workshop facilitator to also be able to facilitate our variant. As such, many of the exercises along the way are the same as what they created. Our adaptations are explained on [another page](/design-sprint-1/link-with-design-sprint-2.0) of this book.
## Minimum Viable Platform
The goal of this workshop is not to build the whole platform. Instead, we aim for a Minimum Viable Platform (MVP), which is the minimum amount of organizing for the maximum amount of learning about future versions of the ecosystem. The definition is inspired by .
## TLDR;
We aim for the Minimum Viable Platform by first formulating the key interaction we want to facilitate in the ecosystem as a How Might We question. Then, we set a 2 Year Goal that states what would happen if the role would no longer be constrained as a means to help us zoom out and investigate what the constraints are that could stop us from that 2 Year Goal. These constraints are formulated as Sprint Questions. These constraints are what the platform aims to take away. Based on the Sprint Questions we determine which role is the most constrained and becomes the focus of this sprint. We draw a map of the journey including touchpoints to better understand it and determine the area of the map that we want to target in the MVP. We sketch possible solutions to reach the 2 Year Goal, taking into account the Sprint Question obstacles, and select the concept that we like most. We add more granularity and details to the Concept through the User Test flow exercise and then collectively create the Storyboard which contains all the MVP details. The Storyboard is converted into a working prototype and shown to our users in an interview to (in)validate the assumptions we started with: does this MVP solve the HMW.
## Before you start
Before you start the workshop, determine who is the Decider, which is the person who has the mandate to make decisions. This could, for instance, be a manager or product owner.
Also be sure to obtain the materials for this workshop: Whiteboards, rectangular yellow stickies, square yellow stickies, alternative color square stickies, green and red dot stickers, sharpies, A4 paper, paper tape, scissors, glue, and a timer for timeboxed activities.
##
# Link with Design Sprint (2.0)
This workshop is based on the Design Sprint pioneered by Jake Knapp and adjusted by [AJ\&SMART](https://aj-smart.teachable.com/). It is based on four core principles: Together Alone, Tangible ideas over Discussion, Getting Started over Being Right, and Don’t rely on Creativity. Our aim is to leave the structure of the Design Sprint intact as much as possible while taking into account two things that make our context different.
## 1. Platform ≠ Product
The original Design Sprint is used to prototype and validate products, but we are working with platforms. However, one could see a platform described in the Experience Board as multiple products (one for each role) interacting in the same ecosystem and that are linked to each other. Therefore, we decide on one role, called the constrained role, and treat its journey as the product for which we want to do this workshop. We provide a structured approach to select the constrained role right after formulating the Sprint Questions. These Sprint Questions can be seen as the constraints our roles deal with, hence the name constrained role.
## 2. Build upon insights of preceding workshops
The original Design Sprint starts from stratch. However, we already learned a lot about the ecosystem and the platform in [Reveal ](https://reveal.futuring-architectures.com/)and [Position](https://position.futuring-architectures.com/). Therefore, ‘Monday’ of the Design Sprint 2.0 is adjusted to use data that is already available. It would make no sense to discover this information again.
# Recap inputs from Position
We apply the workshop to Airbnb to make our descriptions of the exercises more clear. During the [Position](https://position.futuring-architectures.com/) workshop, some crucial steps towards the platform have already been taken. You find the canvases of that workshop below. For more in depth information you can check out the Postion workshop book.
## The main ecosystem relationship from the Ecosystem Portrait Canvas
## The touchpoints, channels and exchanges from the Transaction Engine
## The challenges and services from the Innovation Engine
## The journey of our main ecosystem players from the Experience Map
##
# Phase 1: agree on the challenge
## How Might We facilitate interaction on the platform?
The very first thing we should do is set the focus and scope for the MVP. Take a look at the statements in the middle of the [Ecosystem Relationship Portrait](/design-sprint-1/recap-inputs-from-position#the-main-ecosystem-relationship-from-the-ecosystem-portrait-canvas). What brings the roles together and how might the platform facilitate the interaction? We want to capture this in the form of a HMW (How Might We) question to reframe the problem that we want to solve as a question. Discussion on the HMW also helps the team align on the context.
> **Exercise HMW (40 mins)**\
> Look at the statements in the [Ecosystem Relationship Portrait](/design-sprint-1/recap-inputs-from-position#the-main-ecosystem-relationship-from-the-ecosystem-portrait-canvas) and reframe a key interaction from those statements into a HMW question. \
> \- \[15 mins] Individually, write on rectangular post-its potential candidate questions for the MVP. The question always starts with "How Might We..".\
> \- \[15 mins] Stick all post-its on a wall and then everyone calls out common themes they observe. Work together to cluster HMW’s together and add a blue post-it with the theme. \
> \- \[5 mins] Everyone gets 2 red dots to vote on HMW’s and 4 dots for the Decider. \
> \- \[5 mins] Collect the top 5 and let the Decider select the final HMW.
In our case, looking at the journey of the Host on the Experience Map, we can phrase its journey as:
*“How might we help a host to present its room to the world, set the price and receive the payments?”.*
## Zooming 2 years out into the future
The How Might We is our goal for the MVP. Now we need to find out what is actually preventing us from getting there. To do that, we first zoom out into the future and imagine a world in which we'll face no obstacles at all and everything goes smooth. What will the ideal world look like in 2 years if the constraints would not exist?
> **Exercise 2 Year Goal (20 mins)**\
> Be optimistic and make sure to aim high. \
> \- \[5 mins] Take a look at the [Innovation Engine](/design-sprint-1/recap-inputs-from-position#the-challenges-and-services-from-the-innovation-engine) from Position, and in particular the challenges to stand out. \
> \- \[5 mins] Everyone takes a block of rectangular post-its and writes down a sentence in form of “In two years’ time….” + what will happen to the ecosystem. \
> \- \[10 mins] One person at a time, stick the post-it on the wall and read it out loud. \
> \- \[5 mins] Dot vote (1 red dot each) on the 2 Year Goal that is most clear and inspirational. The Decider cannot vote. \
> \- \[5 mins] The Decider now decides the 2 Year Goal using a green dot.
In our case, if everything goes right then Airbnb becomes such a big marketplace in 2 years that Hosts would be able to make a living off renting out their room, so we set the goal as follows:
*"In two years time we want to provide a stable primary source of income for 25% of our hosts."*
## Naming the constraints through Sprint Questions
Now that we zoomed out, we can more clearly see what could stop us getting to the 2 Year Goal. In other words, what it is that constrains us. The challenges from the [Innovation Engine](/design-sprint-1/recap-inputs-from-position#the-challenges-and-services-from-the-innovation-engine) of the [Position](https://position.futuring-architectures.com/) workshop are of great help here, so we make sure to reuse and build upon these insights. Similar to the HMW, these constraints are formulated as a question in order to invoke a more solution-oriented atmosphere in the workshop.
> **Exercise Sprint Questions (35 mins)**\
> **-** \[5 mins] Take a look at the [Innovation Engine](/design-sprint-1/recap-inputs-from-position#the-challenges-and-services-from-the-innovation-engine) from Position, and in particular the challenges to start out and stand firm.\
> \- \[10 mins] Everyone takes a block of rectangular post-its and writes down 1-3 questions in form of “Can we...” + risky question / assumption that should be answered / validated.\
> \- \[10 mins] One person at a time, participants stick the post-it on the wall and reads it out loud.\
> \- \[5 mins] Dot vote (1 red dot each) on the question that is most important to answer. The Decider cannot vote. \
> \- \[5 mins] The three post-it’s with most dots form the top 3. Then, the Decider decides the top 1 question using a green dot. The top 3 are all preserved.
With our 2 Year Goal in mind we come up with the following three Sprint Questions:
* “Can we offer sufficient primary income to someone that rents out one 2-person accommodation full-time?”
* “Can we convince Guests to become Hosts?”
* “Can we offer supporting services to Guests that make them stay on our platform?”
## Determine the constrained role
The main relationship is formed by two roles. However, for the MVP, we want to focus on one role’s perspective as the Design Sprint is made for products rather than platforms. A platform can be seen as multiple products (one for each role) that are linked to each other. Therefore, we can transform our platform experience into a prodcut by deciding upon 1 role for which we want to do this workshop. We call that role **the constrained role**.
If you either are running this Design Sprint with a problem for a specific role in mind or previously did a Design Sprint for the other role, then continue to the next exercise with that role as the most constrained one.
Otherwise we want to focus on the role that is most constrained. Remember that platforms create value by taking away friction or 'transactions costs' and making it easier for different types of roles to interact and exchange. We want to pick the role with the highest transaction costs as our constrained role in this workshop. Take a look at the Sprint Questions. These are the constraints that we want to take away. Are these constraints clearly more related to one role than the other? If so, then that is your constrained role.
If the Sprint Questions do not have an obvious tendency towards one role, then a tiebreaker method is to count the number of services related to each role on the [Experience Map](/design-sprint-1/recap-inputs-from-position#the-journey-of-our-main-ecosystem-players-from-the-experience-map). More services indicates that the platform offers more to that role to enable interaction. In other words, the role was most constrained before our platform came around.
> **Exercise Determining the Constrained Role (5 mins)**\
> Use one of the three rules to determine the constrained role:\
> \- 1 - If you have a specific problem in mind then pick the related role as the most constrained. \
> \- 2 - Else if the Sprint Questions are clearly more related to one role then that is your constrained role. \
> \- 3 - Otherwise examine the journey of both roles on the [Experience Map](/design-sprint-1/recap-inputs-from-position#the-journey-of-our-main-ecosystem-players-from-the-experience-map) and count the number of services involved in both. Pick the role with the most services as the most constrained role.
For our Airbnb case, we just went through the [Position](https://position.futuring-architectures.com/) workshop and did not do any Design Sprints yet, so rule 1 is not applicable. If we look at the Sprint Questions, then we see that the first is about Hosts, the second about both and the third about Guests. Based on this we conclude that there is no obvious tendency towards one role. Therefore, we resort to the tiebreaker rule number 3. We count the services on the [Experience Map](/design-sprint-1/recap-inputs-from-position#the-journey-of-our-main-ecosystem-players-from-the-experience-map) and conclude that **the Host is the most constrained role**.
## Map Drawing and Target Setting
Now we want to find a particular part of the whole journey to focus our MVP on that we think could take away the constraints. We draw a map in this phase to visualize the journey of the constrained role and agree on the specific area of the journey that is to be the scope of our MVP, which also makes sure thate we all have the same picture in our heads. Below we see the basic outline.
The left arrow contains the role, while the blocks on the right contains an objective based on the 2 Year Goal. In the middle, we will add blocks connected by arrows that describe the process towards to objectives. The middle is divided into three categories: Discover, Learn, and Start. The Discover phase is where the user might find out about the thing/product/service/etc., for example through a Facebook ad. This is a passive step. The Learn phase is where a user might learn more about it, by actively seeking it out, such as a marketing page. The Start phase is a user would take an action to interact with it and 'buy' it.
Work together on a whiteboard with the template below to map out the interaction on the platform from the perspective of the constraining role. Start by drawing the touchpoints and services (green and blue boxes below) from the [Experience Map](/design-sprint-1/recap-inputs-from-position#the-journey-of-our-main-ecosystem-players-from-the-experience-map) that are related to the constrained role. Then, add additional boxes to complete the picture (red boxes below). These boxes are either added to columns that are still empty or are used to put more emphasize on a step that was not so explicit in the [Experience Map](/design-sprint-1/recap-inputs-from-position#the-journey-of-our-main-ecosystem-players-from-the-experience-map). For instance, below we add the 'Set price' in between services.
After the map has been created, the Facilitator takes a coloured marker and the group decides together on an area of the map that will be the scope of the MVP. Keep in mind here the 2 Year Goal and also the touchpoints and services.
> **Exercise Map Drawing (no strict time limit)**\
> \- Draw the structure of the map, including the role names on the left and the objective on the right (see below). \
> \- Take a look at the touchpoints and services from the [Experience Map](/design-sprint-1/recap-inputs-from-position#the-journey-of-our-main-ecosystem-players-from-the-experience-map) and the direction and contents of the transactions in the [Transaction Engine](/design-sprint-1/recap-inputs-from-position#the-touchpoints-channels-and-exchanges-from-the-transaction-engine). \
> \- Draw blocks with the names of the touchpoints in green and blocks with services in blue. Usually, all blocks fit under the ‘Use’ category, but not always. \
> \- In red, draw additional blocks to complete the chain from role to goal (Discover column is still often empty). \
> \- Connect the blocks by arrows. Use the [Transaction Engine](/design-sprint-1/recap-inputs-from-position#the-touchpoints-channels-and-exchanges-from-the-transaction-engine) for details on what transaction takes place around touchpoints.
>
> **Exercise Target Setting (no strict time limit)**\
> **-** After the map has been created, the Facilitator takes a coloured marker. Decide together on an area of the map that will be the scope of the MVP. Keep in mind here the 2 Year Goal and also the touchpoints and services from the [Experience Map](/design-sprint-1/recap-inputs-from-position#the-journey-of-our-main-ecosystem-players-from-the-experience-map).
Below you see the map that we came up with for our leading example. In addition to the touchpoints and services, we added some boxes in the Discover and Learn columns as they were empty. Also, we added a 'Set price' box. As we aim to provide a primary income to our Hosts, we expect that setting the price will be an important step. Then, we decide to exclude the Discover column boxes as well as the 'Book' touchpoint.
##
# Phase 2: towards multiple solutions
In the previous phase we determined which constraints we want to tackle in this Sprint and what role to focus on. We agreed on the challenge we want to solve. Here we want to get to potential solutions for tackling the constraints. These solutions are crude candidates of our MVP.
## Get inspired with Lightning Demos
Before proceeding to the next exercises, take a moment with the group to invoke some creativity and get inspired by existing ideas. With the Sprint Questions in mind we search the Internet for ideas from other products and platforms, from other domains or maybe from within your own company, that solve a similar challenge. The findings are then shared with the others in quick presentations called Lightning Demos.
> **Exercise Lightning Demos (10 + 2\*participants mins)**\
> Draw inspiration from other solutions on how to solve the Sprint Questions. \
> \- \[10 mins] Take 10 minutes to individually look for other platforms that solve the “Can we…” Sprint Questions. These could very well be outside the industry you are looking at for your own platform. For instance, if we make a food delivery service we could look at how postal platforms or taxi platforms solve the problem of ‘delivery’. Write them on rectangular post-its with product name, the idea / learning / solution and some extra details. \
> \- \[2 minutes per person] Present the solutions you found along with how they solve which problem.
## Sketching: a 4-step process
Now its time to make things tangible. This whole exercise is done **together alone**, which is Design Sprint language for individually. There are four steps: Note Taking, Ideas, Crazy Eights, and creating a 3-step concept.
### 1. Note Taking
We get started by taking a moment to inspect all previous findings and write down what we already have. Everyone takes a piece of paper, preferably on a clipboard, and creates an overview of the 2 Year Goal, the Sprint Questions, the Map and your favourite Lightning Demos. This step is really about copying what we already have and not about coming up with new stuff.
> **Exercise Note Taking (15 mins)**\
> Take an A4 paper and write down the 2 Year Goal, the Sprint Questions, the Map and Target area and your favourite Lightning Demos. The remainder of the time is spent on writing down any thoughts or ideas that come up.
### **2. Ideas**
Armed with an overview of all information, we start flexing our creative muscles and convert parts or our notes into visuals. During this exercise we repeatedly pick a part of the notes that we like to explore and then draw a crude sketch of a possible solution until the time is over.
> **Exercise Ideas (20 mins)**\
> Repeat until the time has elapsed:\
> **-** Select a part of your notes from the previous step and circle it. \
> \- Take an A4 and draw the challenge/problem/assumption/solution of what you circled.
You could draw the step-by-step process or a scenario or scene or anything else. It does not need to be detailed or ‘done’ yet. Drawings do not need to be beautiful (indicated by our own not-so-beatiful drawing) as these drawings are not shown to the others. Also, the idea does not need to be clear and detailed yet. We just want many ideas.
Below is one of our drawings related to the first Sprint Question. It depicts the full cycle starting with a vacant home put on Airbnb and ending with the Host receiving money and doing groceries. The thought of this idea is to set the price in such a way that the Host can cover its expenses by subletting its house.
### **3. Crazy Eights**
We now have some ideas on paper and we want to go beyond and make some rapid iterations on one of these. Crazy Eights is a rapid sketching exercise that helps us to do just that. We all draw eight drawings in eight minutes. People tend to get creative under time pressure and one minute per drawing is certainly pressuring, especially if you need to do it eight times in a row.
> **Exercise Crazy Eights (10 mins)**\
> \- \[1 min] Fold A4 paper 3 times in half so that you end up for 8 boxes if you unfold. \
> \- \[1 min] Choose one idea from the previous step that you like to explore further (circle it). \
> \- \[8 mins] Draw your ideas in eight different ways in the boxes (1 min per drawing).
Based on our example idea above, we sketched eight different variants of setting your price. It includes a simple rule-based method and even a solution that is just a text box but also more advanced stuff such as with artificial intelligence or using an auction model.
Don't be afraid of noting down silly ideas and be sure to put the 'Crazy' in Crazy Eights. Solutions do not need to be viable, we just need to get as far out of the box as possible.
### 4. The 3 Step Concept
The sketch that we create in this exercise represents each person's best idea drawn out in three panels, taking into account everything from the start of the workshop until the Crazy Eights drawings we just created. Up to now everyone has been drawing in private and its time to show what we all created.
> **Exercise 3 Step Concept (30 mins)**\
> \- Take 3 A4 pages and tape them together into a bigger paper. On each A4 you tape an A5 in the middle.\
> \- Draw a 3-step story of a solution that solves the target area of the map. \
> \- Post-its can be added for annotations and explanations.\
> \- At the end, hang all 3 Step Concepts on the wall.
While creating your concept you can keep in mind the 5 principles of the 3 Step Concept: Self-explanatory, Anonymous, Ugly is Okay, Words matter, Catchy title.
The drawings usually represent screens of the platform with buttons and images, but it could also be more abstract. As long as the idea is clear. In our case, we drew a Concept that allows a Host to set the price of its estate based on accounting and a bit of artificial intelligence. Airbnb would look into the Host's bank transaction data (through PSD2 or other Open Banking solutions) and extrapolate earnings of a room based on the number of days the Host wants to rent out its room. The artificial intelligence compares the expected income with the bank account expenses to come up with a suitable price that allows the Host to sustain itself.
.jpg?alt=media\&token=1baa4fc7-c712-46d0-8c50-1b9be1950b1e)
At the end of this phase we have a set of Concepts, each carefully crafted by a participant. Each represents an opinionated hypothetical solution for solving the challenges at hand.
# Phase 3: putting the selected solution on paper
The previous phase left us with a set of Concepts, each carefully crafted by a participant. Each represents an opinionated hypothetical solution for solving the challenges at hand. Ideally we create prototypes and test each of these Concepts, but as that would take a bit too much effort, we instead align on 1 'winning' Concept that we then collectively work out further. This phase is all about deciding on a solution to test and work out all details needed to build the prototype.
## Concept Voting
Humans have limited short-term memory and limited energy for decision-making, which is why an unstructured debate is not the right form for selecting a 'winning' Concept. Instead we'll follow a structured approach that Jake, inventor of the Design Sprint, refers to as "unnatural but efficient". All Concepts of the previous phase are hung onto the wall and everyone inspects them in silence. Afterwards, a 'winner' is selected through dot-voting.
> **Exercise Concept Voting**\
> **-** Reread your notes from the Note Taking exercise and inspect all the Concepts on the wall. \
> \- Take as *many red dots as you like* and stick them on all parts of all concepts that you like or you think is a good way to answer the Sprint Questions.
The above exercise is performed to create a heat-map that helps making the real decisions later. It's about registering interest and not about making commitments, so dont be frugal with your dots. Below we see an example of dot-votes on our Concept. In our case, the team saw value in the price recommendation as well as the graph that visualizes progress towards your earning goals. Also, showing how much the Host still needs in total this year even got two dots.
The Facilitator now presents all Concepts with a focus on where the dots are. Tell the name of the Concept, the general idea and the parts with a lot of heat. It is recommended to appoint one Volunteer that writes down 1 – 3 sentences on rectangular post-its for each presentation that the Facilitator gives in the next task, which are added above each Concept. After explanation of a Concept, anyone who voted on this concept for a different reasons can speak up as to prevent misinterpretation.
> **Exercise Synchronized Voting and Decision (15 mins)**\
> After all presentations, all take a good look at the concepts and dots. \
> \- Decide in your head which concept you think should be prototyped and tested. \
> \- Take a rectangular post-it. Write down the concept title and reasons for your decision. \
> \
> \- Everyone takes a green dot and writes their initials on it. \
> \- Then, at the same time, everyone sticks the dot on the feature or Concept they selected. Everyone presents their decision to the group and the Decider. \
> \- Finally, the Decider selects one of the Concepts as the main Solution and optionally also parts of other Concepts that are really interesting.
As you can see it is finally up to the Decider to pick. What is great about the structure of the above exercise is that the Decider can also optionally take parts of other Concepts. Even though we are selecting a 'winner' we wouldnt want to throw away good ideas or elements. For our leading example we assume that the Decider picked our Concept and did not take with it any other parts.
## User Test Flow
> **Exercise User Test Flow**\
> Everyone takes the square post-its. Look back at the ‘winning’ concept. Write 6 story steps that you think are a good way to guide a user through the solution. Tip: start your sentences with verbs.
For our Concept we came up with the flow below in which a Host selects to set the price of its room and indicates to Airbnb that this should become its primary source of income. The platform looks into the Host's bank transaction data (through PSD2 or other Open Banking solutions) and extrapolate earnings of a room based on the number of days the Host wants to rent out its room. The artificial intelligence compares the expected income with the bank account expenses to come up with a suitable price that allows the Host to sustain itself.
Such User Test Flow is created by each participant individually, after which we put all flows underneath eachother to prepare (you guessed it) for dot-voting a winner. In our example below it is Person 2 whose User Test Flow is selected by the Decider.
> **Exercise User Test Flow Voting**\
> \- Put up the purple post-its as shown below.\
> \- Participants stand up in turns and read out their post-its and stick them on the grid. \
> \- Every participant votes on the row they think is clearest using a red dot. The Decider makes the final decision using the green dot.
## Storyboarding
Now that we decided on a concept and detailed the steps further, we should ensure to not leave any open questions for the prototypers. The Storyboard details the proposed solution to the platform experience of the most constrained role and gives us a means to test and validate the role's participation in the platform. It is recommended here to appoint a Volunteer that draws the story board so that the Facilitator can focus on facilitating.
> **Exercise Storyboarding (60 mins)**\
> Arrange a big whiteboard and draw 8 cells on it. \
> \- \[10 mins] Take the 6 post-its from the winning User Test flow. Stick the post-its in 6 of the cells (see below).\
> **-** \[10 mins] Jointly look at all the Concepts and find drawings you can re-use and stick into the cells. The focus should be on reusing the winning Concept, but feel free to borrow from other Concepts that better represent it. \
> \- \[40 mins] Complete the cells by drawing around the Concept parts and add all details. Advice: start with the first, then the last, then the rest.
First we take our post-its from the User Test Flow and put them in the cells where we plan to draw them out. Of course there is always room to shift a bit so dont spend to much time.
After working collectively for the past hour we arrived at the Storyboard below. As you can see, it is really as detailed as web application screens would be including all buttons. We also added the mouse pointer to indicate what part of the screen is clicked to jump to the next screen.
The Storyboard tells the tale of a Host that wants to set the price of its rental house in such a way as to provide a primary source of income. Airbnb requests insight in the Host's transaction data to estimate the expenses that should be covered by the rental income. After asking for additional information, the Host is presented with a recommended price. Creating a prototype of this Storyboard enables us to test various hypotheses, such as whether a Host gives Airbnb access to its transaction.
# Phase 4: creating and validating the prototype
The previous three phases offered a very structured approach to get from the challenges to a concrete Storyboard of the proposed solution. In this final phase we convert the Storyboard into a working Prototype and use that to test with users. It is recommended to invite someone with experience in prototyping and interviewing. This phase does not have many structured exercises but is meant to provide you with tips and guidance that we learned in the [Design Sprint 2.0 course by AJ SMART](https://aj-smart.teachable.com/).
## Prototyping
The Storyboard is in this phase converted into a Prototype, which is an early stage model of the intervention built to test its design. The word comes from a Greek word for "primitive form". After a recap of the previous day, and especially the Storyboard and Platform Questions, it is time to get to work. There exists no 'together alone' anymore in this phase as it is all about teamwork. It is recommended to assign two roles:
* The Prototyper, who is in charge of constructing the prototype and delegates and assigns tasks to the others.
* The Supporter who should arrange all things that could distract the others, i.e, ensures that there is always enough snacks, coffee, lunch, etc.
It is wise to prioritise two or three screens at first. If you start with them all at the same time then focus is too spread out. Moreover, screens often share common layout components and if you want to make a change you have to change them all. Therefore, it is better to get these right for a small set of screens and then just copy them over. The team works quite decentralised so it is advisable to do two stand-ups of 15 minutes during the day, for instance one just before lunch and one just before entering the final hour.
### Recommended tools for prototyping
A prototyping tool is at the core of each prototyping kit as it allows you to add your designs and create links between them. A good prototyping tool is able to create the feel of a real web application or mobile app without actually coding it. It is also the place where the appointed Prototyper combines everyones work into the actual prototype. The most well-known option is to use InVision which is a freemium product. If you have sensitive information on the screens you can opt for desktop application Adobe XD and if you are on a budget then Presentator.io or Origami Studio are good options.
Once you decided on a prototyping tool you also need a design application to draw your screens in. Established options are Sketch and Figma, although a simple and free tool such as draw\.io would also suffice. Finally, we need some graphical resources for our screens. Icons can be obtained for free from NounProject or FontAwesome, while free photos are found on Unsplash.
Note that the above are just recommendations and you are free to go with any set of tools depending on the capabilities you have in your team.
## Interviewing
After the prototype has been created, we can start having interviews. For this we recruit five people from the platforms target group. Why only five interviews, you ask? Jakob Nielsen found already in the nineties that the best results come from testing no more than 5 users and running as many small tests as you can afford. He summarized his findings in the graph below. More background information about the research can be found on [Nielsen's website](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/).
The interviews are preferably conducted by two participants from the previous parts, where one is the Interviewer and other is Note Taker. Be sure to make clear to the interviewees that you are not testing them, but testing the prototype. Nothing personal.
Starting at the first screen, let them examine each screen and think out loud. After they indicate to be done with a screen, guide them towards the next screen (they might try to click on stuff that do not work in prototype which breaks the experience). Instead of a notepad, the Note Taker has two sets of post-its: green post-its for positive or affirming statements and yellow ones for writing down misunderstandings.
The findings of the interviews can be structured by creating a table with on the horizontal header the names of the interviewees and on the vertical headers the names of the prototype screens. After the interview, stick the post-its into the cells for the corresponding interviewee and screen. As post-its are in two colours, you can immediately see where are a lot of misunderstandings.
# Community
No-one is an island. We love to hear from your impressions, experiences and any other feedback. There are several places to get in touch and meet the FAST community.
Follow the development of the tools on [Trello](https://trello.com/b/mRrJ1xr3/fast-development) as it happens and help steer the course.
:book: Witness the ideas as they form on the [Development Blog](https://fastplatforming.com) and take part in the discussions.
Fork this manual on [GitHub](https://github.com/futuring-architectures) and update text and images, add missing parts, or fix the typos.
:mailbox\_with\_mail: Drop a message in the [Mail](mailto:hello@futuring-architectures.com) and tell us your story. No-one is an island.