Prototypes are early, basic versions of the way you expect your product to look and how you expect it to work. Building them brings your imagination into manifestation. But when reality isn’t strong enough to capture the complicated mess you have in mind, making hard decisions becomes a large problem.

Our messy idea first uncovered itself when the public discourse team set out on Wednesday to user-test our prototype. We had already built a physical prototype of the card game and begun testing it with users. We’d also created a storyboard of the app version of the game using Prezi presentations.

The 2thoughts team met with Professor Dianne Pozefsky of the Computer Science Department to present their ideas and receive feedback on the ability to build their product.

The 2thoughts team meets with Professor Dianne Pozefsky to get feedback about their prototype. Photo by Justina Vasquez.

My team was excited to get out of the basement of the journalism school where the Lab is located, but just as we readied to head for the most populated area on campus, we realized we didn’t understand where the card game, targeted at families, ended and the app, targeted at college students, began.

How were we supposed to explain the similarities and differences between the two products? What features does one have that the other doesn’t? Which cards give players points and which don’t? For the cards that do, how many points should they be worth? We frantically considered all these questions, paralyzed and unconfident in our position to let anyone see our underdeveloped prototype.

John Clark, the director of the Lab, often rants about how we don’t talk to enough people. According to him, it’s the best way to differentiate between what we know and what we assume about our product and prototype. So with that in mind, we made decisions on the more pressing matters like which cards give players points. We decided to give them point values and survey players during testing to make definite decisions later. We would also survey players, to brainstorm solutions later, on more complicated problems like where the mobile and physical game platforms intersect. If we hear enough recurring feedback from users, then we change the prototype accordingly.

Honestly, it’s weird to write about decision making. It’s something people just do, and we do it so often everyday that many of us don’t realize we’re doing it. Really, simply considering whether to make a decision now or wait until we know more is a decision.

On a trip to a nearby convenience store with my teammates this week – the four of us all suffering from our “three o’clock syndrome” of tired, blank-minded laziness – I told one of them that I admired her for being the only person I’d met after a year of working at Reese that didn’t have total faith in the Lab’s process. Her view forced me to be skeptical of every next step we took, every decision we made even though it was uncomfortable. I didn’t cancel my subscription to the “You’re not prototyping fast enough!” mantra, but I decided to begin playing devil’s advocate for the way I interpreted it.Instead of sulking about how confused we are about the way our product works, I’m learning to see the potential around us for absorbing product feedback and advice from potential customers, professionals in the gaming industry, and others willing to help make our prototype grow stronger.

These decisions help us progress. If we never decide to put some things off until later, or never decide for once and for all that the “debate-in-a-foreign-accent-while-hopping-on-one-foot card” is worth two points instead of four, then the prototype and, consequently, the team will not advance.

To keep your mad experiment from blowing up in your face, make decisions and do so frequently.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.