Paper Prototypes

You should have several ideas from your brainstorming session.

• Group any similar ideas together.
• Take one idea (or group of ideas) per person and spend 5 minutes building a paper prototype.

How to build a paper prototype

It's simple! All you need is a piece of paper and something to write with to draw out your solution.

No one expects it to be pretty, don't worry! Add as much detail as you can around how your solution might look or work.

• Login Page
• All events page (Add date selector - closes #31)

Closes #33 - added event/{id} end point
Closes #26 - added 404 page

Each User Group Registration should probably have the following information

• Event Details
• User Group Details
• List of all users in group

Setup Backend (or AWS Lambda?) to allow for CORS headers in the request.

Should you Pivot or Persevere?

What feedback did you receive from potential customers?

If the feedback confirmed that you're solving the right problem, for the right people, in the right way, awesome! Let's move forward.

If you received feedback that makes you want to rethink your problem, customer segment, or solution, now's the time.

• Update your lean canvas, and consider going back to the brainstorming and paper prototyping phase to take another shot at it.

Keep iterating until you get feedback that tells you to push on! Keep track of your pivots to share how you arrived at your end solution during your pitch.

This will prevent the first empty usergroup from each card from showing up / spinning.

• Add Event Date
• Add if user is not going to event

• Dev Setup Locally
• Need to setup Habitat for Humanity account for production application

• Server Type
• How to Setup Mongo
• How to build and run express server
• How to setup production login credentials

Start date needs to be filled in on the home page. I think this returns an error currently if this is not filled in.

Look into making selector for date and time of event query.

Set max users to 50, and loop through pages until group is found

• Add a progress bar to show how many user groups are remaining to load.
• Determine how to loop until an array of 0 is returned. (May need redux thunk?)
• Do initial rendering based off of usergroup ID and populate name after. (Completed as part of #35)

Does this project exist?

Have you found solutions for the same challenge that exist already? Are there apps or solutions out there that are already being used to address this issue? If so, how do they fall short of meeting their goal, if at all? Be honest with yourself. Is it worth our time to build something that competes with what’s already out there? Are there ways we could improve on existing projects to be more impactful? If there’s nothing already out there that addresses this challenge, ask yourself why not. What barriers exist that inhibit progress in this area? Does this challenge call for a technical solution? Maybe the issue is at heart an organizational or physical one, rather than something that a tech approach can solve.

Identify existing alternatives

Take time to discuss as a group how people solve this problem today. Document all of the existing ways people solve the problem you want to solve.

Look into api endpoint for event/{id}

• Add action creator
• Add reducer
• Update components/UserGroup.js to use new event action creator

Pick a solution

Which of the paper prototypes is your team most excited about?

• Decide as a team on the top 1 or 2 prototype(s).
• Add the solution(s) in Box 4 of your lean canvas.

Remember to ask yourself: Does this solution solve the problem (Box 1) for your customer (Box 2)?

Form a team of 2 to 5 people

Gather with at least one other person to create a team around an idea or a problem that's interesting to you.

Spend a few minutes asking these questions:

• What's our shared vision?

  • Talk about what goal you want to accomplish as a team.

• What's in it for me?

  • Talk about each individual's motivation - what do you as an individual want to learn or accomplish?

• What talents do we bring to the table?

  • Share a bit of your experience and skills

• Set working agreements

  • What agreements do you, as a team, want to make for the time you are spending together?
  • Suggestions:
    • Show Up On Time
    • Agree on when you'll meet
    • "Art of the Possible" - no idea is stupid, let's consider everything.
    • Be Present - when you're here, you're here, be intentional with your time.

That's it! Now you have a clear goal for your team to accomplish and you know why each of you are here.

Questions:

• Pulling from api - see: https://www.benlcollins.com/apps-script/beginner-apis/
  • Auth headers - https://developers.google.com/apps-script/reference/url-fetch/url-fetch-app
• Custom function in a cell - https://developers.google.com/apps-script/guides/sheets/functions
• Refreshing the data - https://stackoverflow.com/questions/31659186/how-to-refresh-a-sheets-cell-value-in-google-apps-script
• Storing secret keys for auth

Is the problem worth solving?

When deciding on what projects to build at Code for Denver, one of our primary concerns is the impact a given project will have on the community. This is why we emphasize the user aspect of the project: does this project benefit an identifiable group of people? Can you find real persons to test prototypes and the MVP? If you can’t identify who will benefit, and this project can’t be quantified in terms of users and user-testable MVPs, then this project might not be a good fit for Code for Denver.

There is no ego associated with a project, so it’s not a personal reflection on you or your interests if the problem isn’t a good fit. It’s entirely okay to do some research and determine that a project isn’t worth solving or not a good fit for CFD.

Try a lean canvas model

A lean canvas is a great way to lay out key components of your project success model so you can start testing your assumptions and get to building something customers want as fast as possible.

To create a free digital version of a lean canvas, go to Canvanizer. Alternatively, you can print this lean canvas

How to write a problem statement

Choose one of these two formats, and write down your problem:

• I believe [type of people] experience [type of problem] when doing [type of task]
• I believe [type of people] experience [type of problem] because of [limit or constraint]

You can have more than one problem statement, but no more than 3.

###Testing with Users
Great! You've created something for your project!

Now we want to get user feedback to make sure our assumptions match customer expectations. Hopefully by now, you have a relationship with a partner or partners to which you can throw your newly-developed software.

Be sure to put the product in front of them to how they use it, and incorporate feedback into your next iteration. Validate that you're solving the right problem, and check to make sure you've reduced any friction involved in the user experience. Pivot as necessary.

This cycle of refining after demoing should go a long way towards injecting life into the project. That should translate into the customer getting a lot of value from our efforts!

For more information on UX research, see this presentation given at one of our Code for Denver Meetups.

Copyright 2016 CA, Inc.

Who is your customer?

Fill in Box 2 of your lean canvas.

Ask yourself:

• Who do I think this problem (from Box #1) is most painful for?
• Who do I think my "early adopter" will be?

Be specific! For example, instead of saying "Teenagers," narrow it down to "Female high school students who own cell phones."

Pitch for Active Development

If you have gotten this far, and have completed all the previous cards you should be confident to move this into the Active Development phase and build a minimum viable product. (If you don't feel this way, it is totally fine to not move forward with the project)

To pitch for active development to the group, coordinate a time on the weekly agenda to take five minutes to update the group on the state of the project (this does not need to happen on standard 1st Monday of the month pitch night).

The purpose of this pitch is to present the state of the project, and pitch that it is worth putting the effort in to develop the MVP.

There are a few specific things that we'd love for you to preset:

• who is the partner organization
• who are the users
• MVP mockup
• show overview of research
  • what already exists
  • how do you know this solution will be valuable

Similar to the original pitch, there might be a call for further refinement, and a request to hold while work in progress is wrapped up before moving forward.

Hope to get your MVP developed shortly! 😄

Research Potential Partners

• Teams should identify at least two potential project partners.

• Potential partners should be non-profit, government, or quasi-governmental organizations, community-based organizations or other community groups or organizations consistent with the CfD mission.
  Teams should identify if the initial idea is consistent with potential partner organization mission and goals.

• Teams should be able to clearly identify how potential partners could used the built solution, how they would maintain the end product and partners overall role in the built solution product live cycle.

Do we need to add a calendar view to the online version?

https://www.sitepoint.com/comparison-javascript-calendars-schedulers/

Currently if two events are looked at back to back it is possible for users from both events to get added.

Ideas:

• Make a new event specific array that holds the users and can be passed to the download excel container.
• Clear out the user store when a new event is looked at.

Test your Guesses

By now you should have:

• Boxes 1-4 filled out on your lean canvas
• A paper prototype of a solution

So far we've made a bunch of guesses. What problems we think exist, what customers we think have that problem, and what solution we think would solve it.

Before moving on, we need to test those assumptions with some potential customers.

• Spend 1 hour trying to find people who fit your customer segment and talk to them. Call your friends, find people on twitter, even pick up the phone and call businesses. The more people you can talk to, the better!

• User Group Registrations
• Users

This connects to #38.

• Front end must authenticate based on usergroup/event.
• Allow front end to get event by ID
• Download all usergroups on a schedule
• Allow front end get usergroup by ID.
• Allow front end to get users by ID.

What is your Unique Value Proposition?

Fill in Box 3, the "Unique Value Proposition."

What is a UVP?

Your unique value proposition is the promise you're making to your customer that's compelling enough for them to jump on board.

Writing a UVP

Here are two suggested formats:

1. Ask yourself: "If I solve the problem [by doing this] for my customer, is that compelling?"

When you can substitute [by doing this] with something compelling, that's the Unique Value Proposition you're proposing.

2. Complete the statement: "I can promise [the customer in Box 1] who faces [the problem in Box 2] that I can give them [unique value proposition in Box 3]."

Lastly, don't forget to fill out the High Level Concept! This serves as a clear way to describe who you are. For Uber, this would be "Order a taxi with your phone." It can also be an 'x for y' concept like "Instagram for Pet Lovers."

Let's build something!

You should now have a backlog of cards on your board representing what you need to do to build and test your MVP. Let's get to work!

For best results, timebox your development into 20-30 minute mini sprints using a timer to continually check on progress and give you the best chance of reaching your goals by the end of the event.

• Add local strategy with pin code generation

merged #22

Some phone numbers are XXX-XXX-XXXX while others have no dashes XXXXXXXX

Go through flowdock and add the endpoint documentation and links to the members site.

Ideas:

• Pin Code
• Project Hash as URL

Define a testable Minimum Viable Product

An MVP is the smallest possible increment of your solution that delivers enough value for you to be able to ship it and learn from customers as quickly as possible.

• Agree as a team: from your paper prototype and lean canvas, what's the riskiest assumption you're making?

For example, if you were building a device that would automatically pour beer for you, the riskiest assumption might be technical - how do you know how much volume of beer to pour? If you were building AirBnB, the riskiest assumption wouldn't be tech, but instead would be trust - will users rent out a bedroom in their house to a stranger?

• Take your riskiest assumption and figure out the smallest increment you need to build to test that assumption.

• Take that increment and create cards on your board to represent what your team needs to get done in the next Sprint to build that iteration. Think about what it will take to test your MVP - it's not just about building something, it's about building something you can use to learn from as fast as possible.

This backlog of work can be used in your pitch too, to answer "What's next?"

Brainstorm Solutions

• Using a timer, take 5 minutes to write down as many rough ideas on sticky notes as you can.

• Go around as a team and put your sticky notes on a wall as you say what you wrote.

• Group similar ideas together.

When you're finished, you're ready to move on to creating paper prototypes!

Currently if two events are looked at back to back it is possible for users from both events to get added.

Ideas:

Make a new event specific array that holds the users and can be passed to the download excel container.

• Clear out the user store when a new event is looked at.
• Don't add user if they have removed themselves.

https://github.com/heroku/react-refetch