At Fair Haven Innovates, we are makers. We make for others.


We use our design process to create innovative solutions for our user’s tame and wicked challenges.


This is our process.


design process


Here are the simple rules for using our design process:


-Lead with Empathy
-Test your way to the best answer
-Learn something new when you fail
-Return to the appropriate design stage as needed, when needed


Below you will find the stages of our design process. Use the buttons to go to a specific stage.



Our design process starts with Empathy. Empathy is the ability to understand and share the feelings of another. We lead with Empathy to understand and share the feelings of our users, customers, and clients to ensure we are designing the best solutions possible.


There are four simple rules, that are best followed in order, to help you develop Empathy during our design process:


  1. Observe – View and Shadow users as they live their life.
  2. Engage – Prepare then Interview users. (Remember: Interview Life Cycle)
  3. Immerse – Experience what your user experiences through role playing.
  4. Unpack – Use an Empathy Map to reflect on the insights you’ve gained from the Empathy Stage.



After Empathy, we move to the Define stage. In the Define stage, we will define our user and their challenge.


We define our challenge by creating a challenge statement. A challenge statement should explain, preferably in one descriptive and specific sentence, your user and their challenge. We must make a descriptive and specific challenge statement because it is the starting point for making an innovative solution for our user’s challenge. If we don’t get the challenge right, we can’t design the perfect solution. Your Empathy Map will be important in the define stage. Refer to it often.


As a simple rule, a challenge statement should:


  • Be specific and descriptive.
  • Inspire your team.
  • Capture the hearts and minds of people you tell it to.
  • Fuel brainstorms by suggesting “how might we” statements.
  • Be written in the format:




We write it as (Re)Define for a reason. You will need to revisit the Define stage when the Testing stage doesn’t solve a user’s challenge. If you don’t understand a user’s true challenge, you probably won’t come up with a solution that works for them.


Here are a the simple rules when visiting the (Re)Define stage:


  • Have a completed Testing Grid.
  • Have user feedback on your prototype and experiment.
  • Use the Testing Grid and user feedback to decide if you found the true challenge.
  • If you have to go back to the Empathy stage to get the challenge statement right, do it!



There are two phases to the Imagine stage. During the first phase of the Imagine stage, your job is to brainstorm a lot of ideas and diverse ideas to solve your user’s problems. Ideas are ugly babies; they change and grow more beautiful as they develop, so it’s important that you don’t throw out ideas in this stage.


Here are the simple rules we use when we have a brainstorming session:


  • Do not hate on ideas. Instead, say “Yes, and…” and build on ideas.
  • Ask “How Might We…” questions with constraints to keep the ideas coming.
  • Be visual.
  • Only one conversation about one idea at a time.
  • Go beyond obvious solutions.


Selecting Ideas


Your brainstorm should have generated many, diverse ideas to solve your user’s challenge. During the selection phase, it’s time to harvest solutions to grow into prototypes during the Make stage. But how do you know what ideas are worth turning into prototypes? Sometimes it’s easy and most of the team will agree on the 2-3 ideas to turn into prototypes. If so, Great! You have your ideas for the Make stage! Sometimes, though, it’s hard to pick 2-3 ideas.


Here are the simple rules to help your team select possible solutions to build in the Make stage:


    • Use “I” statements such as “I think” “I feel” “I wish” “I wonder” and “What if…” statements when judging ideas.
    • Only one conversation about one idea at a time.
    • Place ideas onto the How? Now. Wow! Matrix
      • Vote: each team member gets three votes to spend on their three favorite ideas on the matrix
      • Compromise: support ideas you can “live with.”
      • If needed, eliminate, revote, and compromise until you have 2-3 ideas.


Carry 2-3 ideas, preferably one from each How? Now. Wow! Matrix area, forward to the Make stage.

Make for the First Time


Now that you have a few ideas on how to solve your user’s problem, it’s time to get the ideas off of paper and turn them into a prototype. Your prototype is the physical form of a solution for your user’s challenge. Machines, apps, games, pictures, videos, storyboards, etc. are all forms of prototypes.


If this is your first time building a prototype, keep the design and materials simple, make it fast, and keep it cheap because your first prototype will fail. Don’t worry! As long as you learn something from your prototype when you test it, it’s a successful failure. Successful failures are good.


You will come back and rebuild your prototype using the insights you discover in the Testing stage, so your goal is to get out of the Make stage and into the Test stage as quickly as possible.


Here are the simple rules to follow when making for the first time:


  • Make only the 2-3 ideas from the Imagine stage.
  • Make even if you’re not sure yet.
  • Prototypes are meant to fail, so make them simply, quickly, and cheaply.
  • Scout and Sketch before building.
  • Build with your user in mind.
  • Build with the Test stage in mind.


Make after Testing


After gaining new insights during a Testing phase, you will most likely return to the Make stage to improve your prototype.


Here are the simple rules for making after testing:


  • If your prototype was a total failure, revisit the right stage of our design process and move forward from there. If you don’t know the right stage, go to the Empathize stage.
  • If your prototype was a successful failure, rebuild your prototype with your new insights.
  • Bring your prototype closer to a final product as simply, quickly, and cheaply as possible.



Testing is an opportunity to get feedback on your solution and learn more about your user by engaging users with your prototype. The feedback and learning about your solution and user comes from observations, interviews, surveys, and experiments.


Here are the simple rules for testing with users:


  • Show, don’t tell
    • Put your prototype in users’ hands. Don’t explain everything (yet). Watch how they use (and misuse!) what you have given them, and how they handle and interact with it.
  • Create Experiences.
    • Don’t explain your prototype. Test your prototypes in a way that feels like an experience that your user is reacting to.
  • Ask users to compare prototypes.
    • Bringing multiple prototypes to test with users gives them a chance to compare them. Comparisons often reveal insights.
  • Observe, interview, and survey as many users as possible.
  • Fill out a Test Reflection grid after testing.


Designing an experiment


Often, you will need to design an experiment to know if your solution is working. This is especially true if you have many users that you can’t personally interact with. Designing an experiment to test a prototype is a lot like the Scientific Method.


Here are the simple rules for designing an experiment:


  • Design an experiment for one solution at a time.
  • Turn your challenge statement into a hypothesis.
  • Identify a Key Performance Indicator (KPI) – the key variable that you will measure to know if your solution is working.
  • Collect data that shows what the KPI was before the experiment.
  • Collect data on the change in the KPI during the experiment.
  • Interpret the data and feedback with your team.
  • Decide to Persevere or Pivot:
    • Persevere: If your hypothesis was correct and KPI improved during testing, press on with the same prototype. Return to the Make stage and improve your prototype for retesting. 
    • Pivot: If your hypothesis was incorrect and KPI didn’t improved during testing, return to the Empathize stage and rethink your assumptions about your user, their challenge, and its solution. 



After you finish the design process by solving your user’s problem, it’s time to tell their story. Storytelling isn’t as hard as it might seem. Stories are simply a person, in a place, who has a problem they want to solve. 


Here are the simple rules for storytelling:


  • Make your audience see themselves in your main character. Find shared experiences. 
  • Make your audience root for your main character. Empathy Maps will help you paint your user’s story.
  • Our design process makes a great story guide: use what you’ve learned during the design process to tell your user’s story.
  • Inspire your audience and leave them with a call to action.
  • Storyboard before filming.


How to shoot video


If a picture is worth a thousand words, a video is worth a thousand pictures. Planning ahead, but staying open to possibility, will give you the best chance of making an awesome video. Know what you are trying to do and be aggressive about communicating it in the frame. If it’s not in the frame, it doesn’t exist.


Simple rules for shooting video:

  • Video:
    • Shoot video close up.
    • Be conscious of light sources & shadows on your subject.
    • Follow the rule of thirds and frame off-center.
    • Get more footage than you think you need.
    • Longer takes make it easier to create transitions.
  • Audio:
    • Keep the mic close to the subject.
    • Point mic away from undesired noise.


How to edit video


Editing can make or break a video: the story is supported or ruined by the way a video is sequenced, paced, & scored.


Simple Rules for editing video:


  • Shorter is better. Simple is best.
  • Make a rough cut of the whole story then go back and edit it again.
  • Avoid unnecessary animated transitions.
  • Transition on words or actions, especially to edit out mistakes.
  • Use voiceover and cut to action for longer scenes (a lot of other good tips here).
  • Music is powerful: use it wisely.
  • White text with a black outline can be read on any background.