Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • start by writing out a simple description of the idea, and then create a separate fleshed-out version of that description.

  • start by writing out a simple description of a single user and use-case, and then add additional user types and use cases.

    • start by writing out text descriptions, then use those to create wireframes.

  • maintain separate descriptions of the vision for 1) the full-featured version of the app and , 2) the (possibly-multiple) minimal version(s) that could be used as a starting point (MVP) towards that ultimate vision, and 3) intermediate versions between the MVPs and the full-featured version.

The process

  1. Start with just considering just a single user-type (or multiple user-types if the app is connecting different types of people) and a problem they have (aka a use-case).

    1. Yes, the full-featured version of your app may handle many different types of users and many different types of use-cases, but when getting started it’s better to keep things simple.

    2. If you got this idea from a problem in your own life, you can use yourself as the initial user.

  2. Write out a simple description of the problem that user-type has.

    1. “I want X but can’t because Y.”

      1. Question: There are two elements here: first, what the person wants, and second, the thing keeping them from getting what they want. I feel like it’s important to keep both of these clearly in-mind but it’s not clear to me yet why.

        1. Answer: I think it’s important because your solution has to both allow the user to bypass the problem (“Y”) and also do so in a way that allows the user to get what they want (“X”). If you lose sight of what the user wants, you can end up in situations where the “solution” isn’t really a solution.

      2. Examples:

        1. Rhymecraft:

          1. Writers: “I want to write rap songs to the same level of quality as Biggie / Tupac / Eminem, but can’t because I don’t know how to write rap songs.”

        2. Uber:

          1. Riders: “I need a ride, but I can’t find one because there’re no taxis driving past me and no easy way for me to communicate with the taxi drivers.”

          2. Drivers: “I have a car and want to use it to make money by helping people get around, but I don’t see any customers around me and I don’t have a way to communicate with customers who aren’t around me.”

        3. Facebook:

          1. Students: “I want to know about the other university students in my class and find out whether I have any shared friends with this person I like, but can’t because that information isn’t stored anywhere.”

        4. Upwork:

          1. Clients: “I want to find someone to work on this short project but it’s a huge amount of work sorting through resumes I get from Craigslist and then interviewing people to try to figure out who is going to do a good job.”

          2. Freelancers: “I want to find work but it’s really hard to build a good reputation when I am hopping from gig to gig, and the application/interviewing process is so much work it’s not really worth the trouble.”

  3. Optional: Write out a simple description of any existing solutions and why they’re not ideal.

    1. Explanation:

      1. This provides useful context for people who aren’t already familiar with this space.

    2. Examples:

      1. Rhymecraft:

        1. I could pay a rapper/writer to help me, but 1) it would be more expensive in terms of my time and money than using an app, and 2) they probably wouldn’t do a great job.

  4. Write out a simple description of the user’s journey with your app that would allow them to solve their problem.

  5. Start to build out a fleshed-out text version of that simple user story.

    1. The idea here is to try to specify exactly how it would work, what information would need to be gathered, etc. while maintaining the simple description as a north star.

  6. Use that fleshed-out text description to create a list of necessary views/pages.

  7. Create a new Balsamiq project and within it create a mock-up that contains simple box-only representations of the different views in your app that would be necessary to implement that user journey.

  8. Now that you have one user journey complete, think about whether the users might ever want to do anything other than what you’ve just mocked up. Follow the same steps as above for those other user-actions / use-cases.

  9. Maintain a separate bare-bones Balsamiq project that includes the views from all the different user journeys but this time have the links able to be clicked on to bring up different views.

  10. Once you’ve done this for your minimal version of the app:

    1. follow the same process to consider additional user-types and use-cases as a way of fleshing out the full-featured version of your app and/or planning out a subsequent-release.

    2. start from scratch on a new, different app-plan if you want to plan out a different starting point/MVP: a limited-feature app that would have the same full-featured version as its ultimate aim.

      1. Examples:

        1. Facebook: I can imagine Facebook having started not with its ‘Friends’ use-case but instead with its ‘Facebook Groups’ or ‘Facebook Marketplace’ use-cases, and then expanding later into letting users add friends.

        2. Uber: I can imagine Uber having started with its ‘Uber Eats’ use-case instead of its ride-sharing use-case.

...