thesisbeans

Questions, possibilities and getting started building something

I had a very productive meeting today with my now-advisor David Womack (as well as a delicious Strawberry Fields Tea Latte from R/GA—they have a rockin’ in house caffeine bar!). We talked about seemingly a million things, and I came away feeling energized and ready to, well, do a million things.

In my last post, I had written about how I feel pretty much ready to start building something concrete. I still do, and David seems to agree that this is a smart way to proceed. Nevertheless, we had an rousing discussion on raising questions and exploring possibilities. You know, where sentences start with “Are you sure about…” and “What if you did…”

For example, we discussed whether I really want to make this a cooking site where people can meet, or a meeting-people site where people can cook (subtle but important difference). We also talked about alternative audiences—what if the product really takes off for single moms? What would their needs be? That was not something I had originally thought hard about, but it’s a very compelling use case. There was even the suggestion of a something akin to chat roulette on channels, like you could log onto the grilled cheese channel and talk to as many people as possible while making grilled cheese.

To me, these discussions and questions comprise the the bulk of what we consider “design work.” It’s not really about wireframes or flowcharts, or even the Sharpie markers and the sticky notes and the whiteboard scribbles – those are only the external manifestations of these things that are going on in our heads. Those just demonstrate to an observer that we are asking these hard questions. And why do we do it? So that we can both stretch our creativity to its limits, but also perform quick and agile menta tests on their viability. Everything from styling a simple scrollbar to concocting a system for strangers to meet in real life consists of asking these types of questions repeatedly in your head. And doing so can reveal brilliant new directions or solidify your current position.

Yet you eventually reach a point where you have to build something. Because mental tests only go so far—they show you how a scenario might pan out according to your expectations—but because we’re all part of the system rather than the system itself, we can’t ever really control what will happen. So you have to say, at some point, “To test out my current thoughts, I’m going to make them real.”

Making thoughts real takes lots of time, during which it’s normal to have more thoughts. These new thoughts could sabatoge your attempts to actualize previous thoughts by changing what it is that you have to make. And so the fun begins: negotiating that tension between thinking and doing, or more precisely not-thinking and doing, vs. not-doing and thinking.

I sense that everyone in our profession struggles mightily with this tension, if not individually then at least as a team. Because it’s a profession that tries to predict the future. When to start making? When to put thinking on hold? (Sometimes the answer is artificially easy: you start making when you’ve finished your Discovery and Concepting phases, as outlined in your Waterfall Project Plan. But when you’re doing a thesis alone……. yeah, good luck with holding yourself to that.) (And why should you? Waterfall models are so 1981. But I digress…)

In any case, I think the answer I’ve arrived at for myself today, after talking to David for an hour, is that you should never put thinking on hold just to start making. And you should also strive never to put making on hold for the sake of thinking.

I’ve already committed to starting the making part, but that does not mean I can’t still wonder about what fun a grilled cheese chat roulette channel would be. Or what would happen if a handful of surburban moms started a weekly cooking challenge where they each cook something different using only the contents of their fridge. That’s certainly not the use case I’m building for, but it doesn’t have to be a use case I’m not building for, either.

There is the possibility that if I wander too much down fanciful paths of thinking-while-doing, I might find myself in a downward spiral of self-doubt, erasing, backtracking and general mortal angst. But there is also the possibility imperative to iterate. And now is the time to use the word Agile in this paragraph. There, I did it.

I really overuse the word prototype in general, because to some extent, everything we build is a prototype. Even if it’s packaged and shipped, sitting on a shelf at Target somewhere, it’s a prototype. Because until you’ve completed the feedback loop with real live users enough times, you don’t know how it’s going to do. And when you do complete the loop, you’ll find there are even more things you didn’t foresee, and you’ll want to put out version 2. As long as you keep releasing versions, each of which reinvents itself for changing conditions and audience needs and whatever, each version will be a prototype. And this will continue onwards, until it ends in the only way it can end: when the product/project expires from neglect.

So yes, my thesis will be a prototype. Because it will soon exist in the world in a very real way (I hope!), but in the meantime I am all for getting ramped up and excited for version 2.