Rapid Prototyping for a Spontaneous Product
What I did, and what I’d do differently now.
I spent roughly eight hours working on designs for a new app my coworkers wanted to build in their spare time. That was a few months ago, and I’ve learned a lot since then — enough that if I had those eight hours again, I’d use them completely differently.

What we did.
They’d been forming their idea for a few weeks, so we were able to build off their base quickly.
Here was the idea: You’re sitting alone at home. It’s a Friday night. You know fun things are going on tonight, but you don’t feel like going through the effort of a) finding out who is free and b) agreeing on something to do. You might give up and wallow in your #FOMO, or you might use Who’s Down. Who’s Down lets you organize last minute get-togethers, activities, events, hang-outs, or whatever you want to call anything that involves people getting together. You know a new movie just came out you’ve been dying to see, so you tell your friends on the app that you want to see it. Within a few minutes you have a group of people to go to the movie with, you coordinate plans in a chat within the app, and BAM. Your Friday night is saved.

My coworkers mostly wanted me to whip out a few designs for them (they even had the colors picked out that they wanted), but I took us back a few steps first to make sure we were building a solution that was solving a genuine problem of the user.
Originally, the idea was to be able to get together with friends quickly, or to connect with strangers in the area that wanted to go to the same events. Not a bad start, but that was focusing on the ‘What’ more than the ‘Why’. We figured out that the core emotions this app was connecting with were loneliness and boredom. From there, it was easy to decide that it had to be ridiculously easy for users to join or plan an event. We also assumed if a user’s existing friends were already on the app, they’d be more likely to use and invest in the app up front (hence why FB login is required).
This entire process of fleshing out their idea, empathizing with their users, and creating the initials screens was done in a single work day.




What I’d do now.
I started learning more about The Lean Startup and how to innovate well right after this project. Most importantly, I learned about the Build-Measure-Learn model.
The fundamental activity of a startup is to turn ideas into products, measure how customers responds, and then learn whether to pivot or persevere. All successful startup processes should be geared to accelerate that feedback loop.
— Eric Ries
This idea of small iterations, quick user feedback, and investing as little as possible before deciding whether change was needed perfectly applied to Who’s Down. Here’s what I’d do differently, looking back:
- Meet with the clients AND users. I did do one of those things *self-five*. But in order to follow the Lean Startup methodology, quick iterative feedback is vital to building something the intended users will actually use. The user’s buy-in is just as important as the client’s. Even within such a short sprint, it’s entirely possible to get quick user feedback. Measurable data on whether to persist or persevere can be collected in less than thirty minutes.
- Understand and prioritize assumptions. There are a lot of assumptions involved in new products — that users will want it, that they’ll be willing to change, that the product adds value to the users life. It’s important to identify a Most Critical Assumption — what is something that could make or break your product? — and base an experiment around it to figure out if it’s true or not.
- Quick and dirty tests. I would throw together a few rough mockups (paper sketches even) of what the screens might look like, focusing on flow and user-centered design. This way, users will feel comfortable giving honest feedback because I clearly didn’t spend much time on what they’re looking at and they won’t feel guilty for telling me I need to completely revamp everything. In the Who’s Down situation, I would aim to show each test to three people to keep the feedback loop short.
- Behavior is key. Ideally, the test would include behavioral feedback. What users say and do is disconnected, and the real success is in how users will interact with the final product. The closer I can get to understanding what their actions will be, the more likely I’ll make an accurate assessment of necessary changes.
- Pivot or persist based on that feedback. Each test and new iteration would focus on my current critical assumption, so I’ll know if I need to pivot or persist based on the behavior of my users. At this point, I create non-functional screens in Sketch and InVision, not spending more than three hours putting something together. The idea is still to put as little investment as possible before learning change is needed.
- Test some more. I would test the InVision prototype with three more users, and potentially go back and show the original testers if they’re available to get more feedback.
- Absorb and focus. Based on their feedback, I would adjust the designs and begin building the high resolution screens after several rounds of user validation. At this point, the risk of building something users don’t want has been mostly mitigated.
- One more time… Go through another feedback loop. Testing should be constant, and it doesn’t stop in the design phase. If the feedback is positive, I would go ahead and go through with building the designs or passing them off to the dev team.
The resulting product would be much more likely to succeed than what my clients and I decided what was best. But, the good thing is it’s never too late to start listening to users. They’ve created the MVP using my designs, and now I can come back to them to help them improve their product.
