From a design standpoint, I’ve been taking a rather risky approach to my thesis project.

Let’s start again with the thing most designers take for granted: that there is an audience from the very beginning. But since thesis is, by its very nature, self-directed and self-driven, I chose not to force a definition on my audience early on. I chose to let the prototype define it for me.

There are definite dangers to the approach of letting the product define the audience. It could be that the things I believed in at the beginning, the very things that drove my prototype, turned out to be false, which would mean I might end up with a solution in search of a problem. And that would be bad, very bad indeed.

One way designers try to prevent this is to research thoroughly in the beginning. However formal audience research is something I did not do, due to a confidence in preexisting knowledge on the subject (I’ve been having conversations with friends on why they don’t cook more for years), and also optimism fueled by early prototypes using Google + Hangouts. Those things gave me the nerve (and now I realize, it was nerve) to move forward as quickly as I did.

Looking back, I think there will always be a part of me that carries some student-guilt for putting off the ‘proper’ thesis deliverables for so long. Competitive review? Nope. Personas? Not really. Concept diagram? Nah. I skipped over those things to the one thing that, in my mind, would validate my idea or disprove it most definitively: the live prototype. (And this has sort of turned out to be true, but more on this later.)

Here in design grad school, projects are treated a certain way—and they all feel like variants on the waterfall method. It seems as though our teachers are saying, This is the way design should be done in the real world, because it builds consensus, unites stakeholders, and—yes—mitigates risk.

But I keep coming back to what it means to do a thesis: to learn something new. Not just to repeat the things we were taught, practicing the way we will perform them to glorious effect in the real world, but to test a new hypothesis, maybe even a meta-hypothesis about the very practice of design in an evolving discipline. So an important test of thesis success, for me, would be whether I learned anything new about how I should design.

Here’s what I’ve learned so far: As it turns out, taking a product from idea to implementation means constantly performing a delicate dance between certainty and forward momentum. By that I mean the optimal approach is to only research as much as you need to feel comfortably certain, then to take a step slightly beyond that field of certainty, and then to repeat the process until the product comes into some kind of fruition.

Okay, that’s nothing new—I just described the core tenets of agile development. But my actual lesson is this: the dance is a lot harder to do in practice, because the boundaries are unclear. How much is enough knowledge gathered? How far beyond the field of certainty do we leap?

The waterfall approach seems to overshoot the neccessary threshold of research by a considerable amount (perhaps for good reasons, because you’re working on a big team or there are very nervous stakeholders), but it’s also possible to severely under-shoot when working alone. Maybe I did in my case—it’s hard to say, I just know I have that sense of nagging guilt for not doing the suggested deliverables in the beginning. In any case, getting this right is the thing that will take years of experience to fully master, and I’m only just getting started.

As for my meta-hypothesis about doing a live prototype being the final arbiter of truth: it turned out to be moot because there never is a final moment of truth in design, is there? It’s never finished, even if your time at grad school thinks otherwise. All I can say is, building the darn thing was worth it. Having a real working prototype will teach lessons in a visceral, immediate, and detailed way that you just can’t get from a paper prototype or even high-fidelity comps. In the coming weeks, I’ll blog more about what those lessons are (need to run more tests and gather more feedback first).

On a final note, I’ll go back to something memorable our program director Liz Danzico said in thesis class one day: “Don’t throw out the baby with the waterfall water.” I think she meant, “Don’t discount everything about any particular approach just because it is the older way of doing things.” She’s absolutely right, and I realize now that I’ve been setting up a dichotomy in my posts between waterfall and agile. In design as in life, very few things are pure dichotomies. The best process is probaby going to be some combination of the two, and that combination would depend largely on the particular project it’s used on. Perhaps that is the key to answering the questions of ‘How much discovery is enough?’ and ‘How far to leap?’

I’ll leave it at that, because I can’t pretend to know the answer after being a professional interaction designer for 0 years. Besides, I have a thesis to finish. Onwards!

But the more I code, the more I’ve come to realize that that there is probably a false dichotomy here. I find that coding, as a brain-requiring activity, is far from the antithesis of design. Nor can it be considered a “non-designerly pursuit” as designers might see it. Instead, I’ve come to see coding as a form of design.

I subscribe to Paul Pangaro’s definition of design as simply making purposeful decisions. And coding, especially in the early stages of a project, feels a lot like just that: you have to do things with intent, you have to be very methodical and critical about why you are doing things a certain way, why you are using x technique instead of y, even down to why you are naming certain variables the way you did. It’s because the decisions you make now will impact what follows—and you also suspect that these things aren’t easy to change later, so you’d better put some good thought behind it.

So, in short, coding does a good job of putting you in a very purpose-driven, very “designerly” frame of mind. When I’m coding, I find myself constantly asking myself things like, “Are you sure you want to call that database collection ‘recipes’? Or maybe we should use a different word because that’s not what the site is about…” Asking these questions gets me to consider possible outcomes, determine strategy, and clarify goals. And the amazing part is, these seem to be the same things that wireframes, userflows, and comps were made to do, too…

The ‘recipe’ database question was actually something I chewed on for a very long time as I stared at my code. And through all the marathon staring sessions, it finally hit me that I do not want to use the word ‘recipe’ at all on the website (that is, unless absolutely necessary, to refer to an actual recipe). Not only are there enough recipe sites on the web already, recipes are really not what the Hotpot experience is about. Rather, it’s about an intimate shared experience with other people, built around food-as-social-object (or rather, food-prep-as-social-process). The recipe, insofar as it’s a standardized, formalized and usually terse set of instructions for getting from point a to point b, misses the point entirely. With Hotpot, it’s not so much about the “How?” of food, as it’s about the “Who with?”

I decided to name that database collection ‘meals’ instead. It connotes togetherness, conversation, shared experience… all those things I strive to create for the users of Hotpot.

Perhaps I could have arrived at the meals-not-recipes conclusion some other way, through more traditional design means like a competitive analysis or through making charts like this. But at the end of the day, I still managed to make that decision, while actualizing that decision in the form of written code too.

That was a pretty simplistic example of code catalyzing design, but there are others too. Like figuring out data hierarchy leading to the idea of capturing and presenting a timeline of cooking memories, similar to the one on Path. Or discrepancies in logic leading to the realization that ‘badges’ (awarded at the end of cooking to an awesome partner) play a fundamentally different role from ‘stamps’ (added during cooking to mark a notable occurrence)—they were originally thought to be the same thing.

Could it be that coding isn’t all just about executing a pre-determined plan, thought up while ‘designing’, but that it actually is a part of the design process? Perhaps this is not the case in big honking companies that believe in employing people just to be code monkeys, but when you’re on a small team of multi-disciplinary members, or you are on a solo project, I think writing code could totally be part of the designer’s toolkit. It’s a great way of coaxing the brain into a sharp, questioning state, so one can be intentional and purposeful with every move; in other words, so one can design.

There's a person here wearing bright pink who isn't me!

I think we can safely say that, gatherings with food are my favorite type of event. It seems that whenever there is good food, there is comeraderie, laughter, “mmms” of satiated contentment, and all-around good cheer. Even when people in the group do not know each other that well, food always seems to bridge the gaps of different lifestyles, unfamiliar cultural backgrounds or just general strangerdom.

I told myself this weekend would be a brief break from thesis, for clearing the mind and regaining a sense of perspective. But whenever there are these gatherings of people around food, I can’t help but be reminded of what I’m working on. Every great dinner, surrounded by friends old and new, is a quiet little cheer for my thesis.

I had set off in September to change the troubled American food system for the better, by making people more sensitive to the origins of their food. This turned into an exercise in trying to convince people to cook. Efforts to do so revealed a sense of closeness created by the shared act of food preparation. And now, gradually, I am becoming more intrigued by this magical effect that food has on groups of people. It catalyzes conversation, builds a sense of kinship, even generates good humor. And with the advent of video chat, it’s so easy and accessible to cook together.

The story of Vera and Fred painted a cute picture of one thing what Hotpot could help with: bringing love into people’s lives. But what if it could go beyond that, and build relationships spanning continents? I am reminded of the wonderful San Francisco startup Culinary Culture, whose stated goal is to bridge cultural divides with food. Their model is to invite immigrant families to hold cooking classes, showcasing the richness of their cultural heritage and building cross-cultural dialogue. Of course, you still have to be in San Francisco to join in. With the Internet however, physical location would no longer be a barrier for participation. People from Mumbai could cook with expatriats from France from their homes. An Iranian student could swap chicken-and-rice tips with a Manhattanite from their dorm. Imagine the conversations they’d have, the friendships they’ll build.

Maybe they'll even get married! (She's Polish, and he's Iranian)

It’s a big dream.

Originally, I had wanted my thesis to change the world of food for the better. But now I can’t help but think… what if I could use food to change the world for the better?

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.

In the weeks that followed, I had a chance to think long and hard about this. I also had some really good conversations with my thesis group leader, David Womack. He said the following:

The magic for me is being able to meet strangers and share this really intimate experience of cooking together. I would want to automatically be able to find cooking buddies based on foods I like, things we have in common, etc.

Thinking back to the story of Vera and Fred, my idealized cooking buddies, this is exactly the hope I inadvertently expressed in this story. This project is not just about the act of cooking together in real time. It’s about who you’re doing it with: whether it’s a friend who lives far away or a stranger you form a connection with, it’s the people who make it so compelling.

A fellow student, Kristin Breivik, also disagreed to some extent with Paul’s assessment. She says:

There is so much around [the cooking experience] to even get people to go to the cooking part. You need to get people excited from the very beginning. and once people get to cooking, it might not even matter if the technology sucks.

She brought up a good point, because I realized that when Clint and Yang prototyped together, Clint was adamant that we actually cook despite initial technology troubles on both ends. This may have had to do with all the built up anticipation, prep and “framing” I had done beforehand to get him excited. So even though conditions weren’t ideal, they persisted and found a way to make it work, and the reward was an incredibly satisfying experience for both of them. Clint, reluctant cook that he is, was even enthusiastic about doing it again. And again I think the fascination was in the interaction with Yang, another human being, not with the “cool” technology that made it all happen.

Of course, this doesn’t mean I should completely disregard the technology driving the cooking experience, but I think it’s clear by now that it doesn’t have to be my one and only obsession. In any case, now I think it’s time to gather together all I’ve learned into one big ball and roll it out the door.

Which means: this week, I will be making wireframes! Stay tuned!

A character study is not the same thing as a persona. Personas exist to help us envision an entire demographic at a time, and the end result is often a rather bland portrait of Pure Averageness. This is a pleasant exercise and convenient for the designer, but the end result is wholly uninteresting, and worse, unrealistic. We create personas because they are supposed to give us an actual human being to empathize with while designing. But how many human beings do you know that have perfect teeth/skin/hair and only wear one type of clothing all the time? Personas are the iStockphoto of imagined people.

A character, on the other hand, is far more like a human being: idiosyncratic, unpredictable and contradictory. They can only be understood as individual accidents of nature/nurture, not as constructed, idealized stand-ins for an aggregate. This helps us get out of the mindset of Perfect Design Land into Messy Real Life Land. It might even help us understand & anticipate some surprising (mis)uses of a designer’s intent.

So here’s my first stab at a character study:

***

Vera Applebottom is thirty-one years old and lives in Orange County. She works for a pharmaceutical firm as director of HR, hiring and firing people and listening to them complain about their jobs in between. She used to be an elementary school English teacher. Now she earns twice as much, but it’s debatable whether or not this was an improvement.

In fact, going to graduate school to study management might be her biggest life regret. She used to wear socks with pumpkins on them for Halloween, to match her witch hat. She liked spending time with children, especially liked being one of the “fun teachers” that all the other teachers’ kids wished they had for homeroom. Now she wears white socks and no hat indoors, all days of the year.

Her most prized possession is a pair of antique pruning shears given to her by her late aunt. Her aunt was the only person who empathized with the fact that she had any regrets in life. Everyone else, especially her two sisters (both housewives), admired her independence and ability to generate income. Her mother, especially, liked to brag that her daughter was a modern woman with a mind and job of her own. Forget that, at her eldest sister’s wedding last year, Vera was so jealous she wanted to grab the limo from the driver and use it to run over the groom. Or at least a bridesmaid or two.

She consoles herself with cooking every night. Domestic, feminine joys seemed beyond her reach for the most part, but she could make fabulously, unnecessarily sophisticated one-person meals for herself in her two-bedroom condo while watching Family Guy. She wonders if/when she gets married, whether the man would be okay with the fact that she delighted in crude humor. She wonders if she would actually marry someone as obese and… unpolished as Peter Griffin. She’d love him though, she’s sure of it. She just couldn’t tell anyone this, ever.

It’s too bad, because poor rotund Fred from the clinical trials division was madly in love with Vera, and though everyone else at work knew she’d reciprocate in an instant, they enjoyed watching the small awkward dramas between them far too much to clue either of them in.

***

Well, that was fun. (Now I know not to quit my job and take up creative writing.) Writing non-stock characters is MAD HARD, and I’m not sure how much I’ve succeeded. I do know I really like Vera though, and wouldn’t mind spending more time with her. Maybe, if I’m patient enough, she’ll tell me exactly what she needs my thesis to do for her? That would be a start.

• Connections on the so-called social graph, as represented by a line with a label, are woefully inadequate for describing the nuance and complexity of real-life relationships. In fact, the harder we try to represent how we relate to one another using dots and lines, the more we end up with “a social version of the Uncanny Valley,” 
• Relationships require maintenance. Without it, they degrade over time. Social graphs do not reflect this—if you do not prune your friends list fastidiously, they will quickly grow inaccurate.
• Unfortunately, creators of social networks failed to understand that the act of pruning one’s account is a social act. “Unfriending” your ex is not really about you dispassionately updating your profile to reflect real-life changes. It sends a him message that you might be bitter, or hung up on him, or whatnot.
• Having all your social activities tracked and remembered is not just unnerving, it’s something that historically only sociopaths would do. There is something about social experiences that seems to require impermanence; otherwise they take on a sinister tone, as if there were some ulterior motive at play.

I’m going back to the start

All this got me thinking about what it means to be “social” nowadays. I’ve been describing my project as “social cooking” from the very beginning, but do I really know what that means? Lots of sites claim to facilitate such a thing, from GroupRecipes, a community recipe site, to RecipeRelay, a cooking blog. But am I doing the same thing as them, or something different? It’s time to find out.

To me, “social” can be boiled down (sorry, I couldn’t help it) to just an interaction between two or more people. However, not all interactions feel equally social. Handing my credit card to a cashier or a sales rep feels somehow “less” social than dinner with my friends on my birthday. Likewise, viewing a friend’s Facebook profile (without leaving any comments) feels less social than engaging in a heated discussion on an online forum. What separates these different forms of “socializing”?

It seems that there are at least 3 things:

1. receptiveness: both parties must be open to the fact that the other is trying to communicate something
2. acknowledgement: both parties must signal to the other that they are listening
3. meaningful content: the exchange must carry a payload of meaningful content. This is probably the most subjective point. What constitutes meaningfulness—is the cashier’s signal that I should sign a receipt not meaningful? Maybe not, compared to my best friend confiding in me.

If we go by these criteria, I can see why so many “social” interactions on the web these days leave us feeling empty. The ubiquitous “Like” button, for instance, often exists devoid of any sign of receptiveness or acknowledgement. (Is anyone listening at the other end? When they find out I Liked this, will they care? How will I know?) Furthermore, the meaning it conveys is indistinct at best, nonexistent at worst. (What does it mean to click the “Like” button? Does it mean it made me crack a smile for a split-second? Or that it profoundly changed my day?)

But one could argue, surely, that the only reason a “Like” button press feels un-received and unacknowledged is that there is a significant delay between the pressing of the button and the recipient of the “Like” checking their Facebook Notifications. So there’s definitely a fourth element at play here…

My working hypothesis: “social” appears to exist on a spectrum from “less social” to “more social,” and the controlling factor is time.

A scribbly little continuum diagram is born

To get my thoughts in order, I drew this (click to view large version):

Different forms of communication plotted along an axis. Not too sure about the labels at the ends right now, but also didn't want to spend 20 minutes in front a thesaurus to get this blog entry done with.

It seems that the more synchronous the interaction (the less of a time gap between responses), the more “social” it feels. This makes sense, because that kind of continuous, immediate feedback is what allows us to build up our relationships with others. Conversely, the gaps of silence in between responses can gradually degrade relationships over time.

True social experiences allow us to strengthen our relationships; superficially social ones merely keep our relationships from dissolving away completely.

In working on my thesis these past few weeks, I realized that the project is not really about changing the US food system anymore. That may be what I spent so many hours trying to say in my proposal, but that’s so far not factored hugely into my prototypes. Instead there is this new idea of creating a truly social, relationship-enforcing experience using cooking as the pretext and the Internet as the conduit. Maybe that’s where I’m headed?

If so, I think I am okay with it.

Some capital letters

Two nights ago, right when I was falling asleep thinking about thesis stuff, a very important thought occurred to me, but I didn’t write it down, and I couldn’t remember in the morning. Then I was folding laundry today, and it came back (can anyone explain how my brain works?). This time, I’m writing it down:

The Internet is a powerful platform, and in the past few years it has brought us a plethora of new tools for social engagement. These tools were all designed to enhance our natural faculties for developing relationships with one another—our mouths, eyes, faces, bodies, minds. With the Internet, we can now traverse time and space to interact with our friends! With Facebook, we can “remember” the contact info of hundreds of people! With Twitter, we can always “know” what our friends are up to at any given time!

But it also seems that lately, more and more of these tools are replacing the activities we’d normally engage in to keep in touch. A 1-sentence wall post replaces an hour-long phone call, a glance at someone’s profile replaces an email asking “What’s up? I haven’t heard from you in a long time.”

In taking advantage of the power of the Internet, I believe we should do our best to make tools that enhance our abilities to build strong and lasting relationships, instead of replacing them with a bevy of more superficial social interactions. Perhaps cooking online with your friends is just one of the ways we can do this. Either way, there is certainly a lot to be explored. And I’m excited to keep going, even if I’m not really going to save the world from factory farming. At least not this year.

I recall back in October, I had described my thesis idea to him and he said it would be a miracle if it could get him to cook. Now it’s November and he has officially cooked! Not only had he cooked, he enjoyed himself! So this first bit of feedback is very encouraging and gives me even more momentum to push forward. But there is a lot of work ahead, too:

Clint noted that one of the reasons this worked so well was that he happened to be cooking with someone with endless reserves of patience. Because he was a first-time cook, he had to be walked through the recipe step by step. He wondered if other, more experienced cooks might get impatient or bored. Is there something I could design so that people with different experience levels can all have fun and not get bored? Or would the inherent sociality of the experience ensure fun, no matter what? It would be good to test this out with more prototypes where there is that student-teacher dynamic.

He also noted opportunities to incorporate more “mindfulness prompts” into the experience. For example, on a certain step, text could appear saying “Now smell the onions as they are frying—doesn’t that smell great?” Perhaps people could tag steps with certain sensory words as they go through. All this would allow everyone to enjoy cooking as a sensory experience, rather than just the tedious following of instructions.

The language of the recipe itself could be tweaked a bit, too. I had used the standard, rather terse and formal-sounding recipe language, albeit lightly reconfigured for maximum helpfulness for novice cooks. Clint pointed out that it’s pretty soulless, and could be pushed even more to sound like it has a personality. It could even include reasons for why a certain step is what it is: “Now you are adding chicken broth to start turning this into soup.”

There is also the possibility of a metaphor for the entire interaction: “everyone throwing their ingredients in the same pot.” This could give rise to a special visual treatment of the interface, or influence the service’s content/features.

At some point, the conversation turned to game mechanics and badges. Clint’s reaction initially was one of guardedness, as we all know what empty meaningless gamification looks like (and it ain’t pretty). But in this case, if the badges could actually stand for something meaningful, it could be super gratifying for the user. We discussed the possibility of awarding badges every time you have a cooking session, so what they represent—good times with friends—would give them positive meaning. Also, the idea of letting friends award one another badges (“World’s Most Patient Teacher,” “First Time Cook,” “Master of Bacon”) could be lots of fun.

He concluded his feedback with advice to focus on the aesthetic layer and the charm, not the technology. “Technology will catch up; don’t worry about the video quality too much.” And I think this is true. Part of what made the evening so fun and engaging was that cooking is actually a very charming activity when done with friends. I definitely need to focus on what would enhance this quality more.

Whew. A lot to chew on. So to speak.

In any case, all this feedback made me realize that I had gotten very caught up in the technical implementation of things for the past few weeks, and now it’s time to zoom back out again and reconsider the reasons and meanings behind what I’m doing. What value am I creating, really, beyond just a suggestion for a new way to use video chat? How can I take it to new places?

For those of you unfamiliar with the work of Paul Pangaro and Hugh Dubberly, this is basically a “stack” of simplified cybernetic diagrams. Each unit or layer shown is a “cybernetic system” – a feedback loop that has a stated goal, an actuator (that carries out an action to achieve that goal), a sensor (that measures the impact of that action), and a comparator (that compares the sensor’s input to the goal and determines what to do next). In my diagram, each layer can be considered a “sub-goal” of the one above it — it represents a set of requirements that must be achieved in order for the goal above it to be possible. These “sub-goals” are called methods in official Dubberly-Pangaro-speak: they describe how the goal above will be accomplished, e.g. the “method” via which it will be accomplished.

To read the diagram, start at the bottom and work your way up. Step 1 is where my thesis is situated: getting people to cook. This diagram then explains how this simple intervention could potentially lead to a positive change in the US food system…

Hardly a week passes in Designerland without this phrase (or some form thereof) being uttered. And yet, I haven’t talked about the target audience for my thesis yet. I haven’t been avoiding the question so much as wondering if it’s possible for an audience to emerge, organically. After all, Facebook was intended for college students; it tapped into the collegiate desire for hallway gossip. Who knew that today, everyone from grandmothers to business directors to taco shops would be using it for essentially the same thing: getting information about other people?

I wonder if the idea of defining your audience too clearly limits you.

That said, it’s still important to have some idea of the type of person who would use an online, video-based social cooking service. So here goes, roughly:

My audience consists of home cooks and friends who have an internet connection and a webcam.

There, I’ve gone ahead and put some (somewhat tautological) limits on my audience, and a rather hard one at that: a technological constraint. Now the big issue that emerges is this: will my audience have to be within a certain socioeconomic class to use this thing I make?

If the answer is yes, I can accept that.

The question of food and cooking as it relates to poverty is complex. It’s not merely about lacking a fully-equipped home computer; it’s about not even having a home kitchen, or heating, or pots and pans to even cook with. And what about the money to buy food? To make choices? What if you live in a food desert and don’t have the mobility to reach slightly further afield for even a fresh head of lettuce? Policy, geography, distribution… those are all things that affect food issues for those who are less well-off. It is far from a simple matter of consumer choice (and by simple, I actually mean difficult-enough-as-it-is). These things would be a whole ‘nother thesis. A whole ‘nother 100 theses, in fact. I am comfortable with not spending this one year tackling those issues, because I have the rest of my life to.

Problem solving requires outlining the problem clearly, and therefore deciding which problems not to solve. For my MFA thesis I’ll tackle the problem of convincing non-cookers to cook, paving a road to more conscientious food consumption habits.

And if that means my audience needs to have webcams, that’s where I’ll start.