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!

Tips for Success:

• Resist the urge to accept feedback, no matter how respectable the source, without first understanding how it relates to your goal.
• Resist the urge to brainstorm quick solutions while receiving feedback. This is essentially doing the above.
• Unless the feedback totally and definitively invalidates your goal, never change your goal to adapt to the feedback. That’s backwards.
• Always have a good reason for everything you decide.

Disclaimer: Instructions are based on the personal experiences of a 25-year-old grad student only. Not backed by scientific studies or certified Kosher. Batteries not included. Revisions welcome.

Further Reading: Feedback and the Creative Process by Cassie McDaniel

Holy. Cow. It’s going to be a rough ride from here on out.

But I’m determined to do it.

Because I have a plan.

I started diagramming conversations:

… and imagining what a good user profile for cooking would be:

… and even started coding a rudimentary profile creation page (unstyled, beware):

The undercurrent to all of this was a certain antsyness to just get something out there. I really wanted to give my potential audience something to do as I worked to get things ready. I was thinking back to the advice our department chair Liz had given me in the Fall semester: don’t put up a LaunchRock-esque “coming soon” page—give your users something to engage in right away, rather than just a newsletter signup field. This made sense, and after giving it some thought, I decided the thing I would allow new users to do was to establish an account and fill out a personal profile. That way they can start checking out the other people on the site. And when the site launches, they’ll already have friends on the service who they can cook with right away.

But as I got closer and closer to actually putting up a page where people could sign up to fill out a profile, I got embroiled in this tangle of worries: privacy issues, community building, setting the tone, communicating with users, how to position the project… And that’s when I posted my last entry. I was getting carried away by all that needed to be considered and studied and worked out and made.

Eventually I took a deep breath and realized: I was confusing where I wanted to be with how to get there.

Meaning, I want my thesis to be so many things so quickly that I wanted to jump right to where I wanted to be, but in doing so was ignoring all the foundations I had to build to make it there!

So I got out an empty page and wrote this on it:

That really puts things into perspective.

Looking at the first sentence, I now realize that Paul Pangaro’s advice about where the core of my project lies is still right on: the real-time cooking part. Even though eventually I want the project to answer all these other challenges like getting strangers to meet, facilitating culinary exploration, etc, those things all fall under the phrase “in the process.” This means they would result from, but definitely not exist without, this concept of cooking together in real-time. When all is said and done, I still have to work out the conceptual core first.

So I’ll back up, take a deep breath, and start in the center. Then slowly, one ring at a time, work my way out. And the entire time, I’ll keep the big picture in mind:

Here’s the new plan: In the coming weeks, I will be focusing on building rings 1 and 2, getting it working, and getting people to try that out. And if all goes well, I can begin to mockup and prototype rings 3 and 4. However, if I run out of time to build out the entire circle, that’s okay too. At least I’ll have a solid foundation built and working! Besides, who says one’s thesis project needs to end in when you graduate?

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 response to this worrisome state of affairs, a movement is growing around the concept of “clean food.” Found throughout the US at artisanal food fairs and farmer’s markets, advocates of clean food propose a food system focused on ethics, health and sustainability. They envision a world where good food can be had by all—without exacting grievous tolls on our environments and bodies.

As the owners of free will and wallets, we all have the ability (and responsibility) to choose what kind of food system we want to support: the current one, or an improved, healthier, more responsible one. But it can be difficult getting started, for making such choices requires a tremendous amount of effort: effort to research food origins, effort to read labels, effort to understand food issues… And indeed, there is no joy to all this effort if it’s done just for the sake of ameliorating guilt. It’s simply no fun to do things just because my conscience is telling me so!

Therefore, for my thesis, I propose to address this predicament by creating a simple intervention: a web-based social cooking application.

Why web-based? Because the web remains the most accessible technological platform for users and builders alike, and it allows us to soften the barriers of distance and time. Why social? Because re-framing cooking as a social activity transforms it from a potential chore into quality time with friends. And finally, why cooking? Because cooking has great potential to be a joyful activity: one that indulges the senses, creates community, and develops a skill to be proud of. Furthermore, since cooking engages the intellect in the selection and preparation of ingredients, I believe it can cultivate in anyone a heartfelt love of food that goes hand-in-hand with making conscientious food decisions.

The proposed web app will essentially allow friends to schedule online cooking dates. On the appointed date, they will gather via video chat to cook together. To facilitate follow-through, invitations will be attractively designed and feature a convenient shopping list. The application can be a platform for knowledge-gathering and discovery too. For starters, it will present only high-quality, handpicked, season-appropriate recipes for people to use. These recipes can be embedded with teachable moments: for example, a recipe for roasted corn soup would advise cooks to choose local, fresh-picked corn in lieu of canned corn—and explain the reasons. As the project progresses, I hope to incorporate other simple, elegant ways of helping participants deepen their food knowledge.

Throughout the process, I will be asking the following questions: What does it take to convince non-cooks to cook? What methods can I use to teach people about their food’s origins and about the wider food system? How can I make cooking via live web cam a good user experience? To answer these questions, I will be performing continual user testing on a series of prototypes leading to a final product. Testing will reveal how users react to the parameters I have set, as well as suggest new opportunities for improving the application’s offerings.

Additionally, I would like to find out what it takes to build and launch a minimum viable product—what technologies to use, how to plan development, and, most importantly, how to code all the parts myself. As I am interested in designing and building products in the future, I’d like to use this as an opportunity to learn what it takes to build a real, working web application.

The ultimate goal of my thesis is to actually release a public alpha version of this application for all to use. It is my hope that by putting a working product out into the world and measuring its impact, I can better understand how to shape behaviors for creating lasting change. Who knows, it may even start to make a small but tangible difference in shaping a better food system for the future!

The first person I showed this to (Frank) thought this was rather promising. The second person I showed this to (a developer at a startup) laughed and said to build in an extra 10 months, just in case.

So… I guess we’ll see how this goes. But here it is!

October (what remains)

• final research/development proposal

• final thesis proposal

• learn how to build a web app with Python and MongoDB

• “Hackathon” weekend to jump-start buildout of MVP (front end)

     - define base feature set

     - wireframe sketches

     - final aim: develop working website with basic video chat/recipe viewing interface

November

• Continue building MVP (back end)

• Recruit 10 testers (from my network) to begin using site so far

     - goal: have each person use the site with their friends at least once within the month

• Interview testers to understand their reactions

December

• Continue building MVP

• pinpoint 3 candidates for advisor

• recruit 10 more testers (again from my network)

• interview testers

• create “coming soon” page to gather email addresses for a bigger test pool

January

• Finalize MVP (bare minimum, core features) over winter break if possible

• work on product branding and design, refine interface

• send out up to 100 invitations to email addresses gathered from “coming soon” page

February-March

• gather use metrics from all the new users (surveys, site analytics)

• bug fixes & work on tweaking site based on user feedback

• 10 more user tests / interviews (via Silverback)

• analyze results from user tests 

April

• write thesis documentation

• produce promotional video / demo?

• bug fixes, further tweaking as time allows

• prepare for public alpha release at thesis final presentations

May

• done!

• sleep for, like, 72 hours straight

Design is not just a noun, it’s a verb; it’s not merely what the result is, but how you arrived at it. To this end, time and attention has been devoted to devising the perfect design process.

But in truth, there are as many processes as there are people in this world.

Here is what I know about myself: I love to make things, and I have this crazy, largely untested idea. Who knows if it will survive? Prosper? Save the world? But people seem to enjoy using it. I know that it has added, in the span of 2 short prototypes, a small amount of happiness and enjoyment to the world. But it’s something.

Despite all that I’ve been taught at SVA IxD about time-tested stakeholder-approved professional design processes, I’ve decided to pursue my own, iterative approach. In lieu of a well-traveled road to success paved with concept maps and KJ Analyses, I’ve just decided to take the plunge.

There will be very little wall-of-sticky-notes brainstorming from here on out (not that there was much to begin with… oops). Expect to see a lot of really quickly written code that only sort of works, and a lot of complaints from people who have tried to use it.

Hooray!

For my thesis, I would like to use commonly available technologies to increase dialogue around and awareness of the foods we eat. To accomplish this, I would like to build an online social cooking experience to help people cook more, and through this, engage more deeply with their food. 

Increasingly, people in the US are opting for prepared, ready-to-eat meals rather than preparing their own food. This is especially true in New York City, where people are bombarded with takeout options and are often too hurried to pay much attention to what they’re eating on a daily basis. I believe that through this loss of food-preparation knowledge, we are moving one step further from knowing (or caring) where our food comes from. This is a problem because consumer choice is the main driver of our food economy, and current consumption habits overwhelmingly support a food system that is inefficient, wasteful, environmentally harmful and even detrimental to public health. I believe that one step to learning more about our food, and making the right decisions on what to buy, is to learn how to make it ourselves: discover ingredients, really read labels, look for things fresh and in-season. Under the right conditions, cooking can even spark a lifelong interest in healthy eating and increased knowledge of our food system, too.

In a sense, my target audience could be anyone who eats food, but in particular I would like my idea to reach those who currently don’t spend much time cooking. This means people like me, who live in NYC, subsist on takeout and usually too busy to cook.

The proposed service would work by allowing people to schedule virtual ‘cooking dates’ with friends (or strangers!). Then, they would meet up via video and chat over the web to prepare a dish together. Dishes can be taken from the website’s weekly curated list of seasonal recipes, or it could be one of the member’s own making. As the date approaches, the system would also provide alerts for ingredient shopping. The hope is that the fun of cooking together will keep people coming back to cook more, so that they can build skills and confidence to cook more themselves. And over time, through dialogue and experience, users will develop a closer relationship with their food. Social cooking could also be a great way for friends who love cooking to convince their less enthusiastic, far away buddies to join.

So far, I have done a great deal of general landscape research, trying to understand the complexity of the food system in the US as well as staying abreast of current food & technology endeavors through the blog foodandtechcnnect.com. I still have much to learn and will perhaps never know enough about our relationships to food, but I feel that I am ready to start designing and prototyping this idea. 

The ultimate goal of my thesis is to release a working product to the public. Therefore, I’d like to create wireframes and build rapid prototypes as early as possible, so that I’ll have time to gather feedback and iterate several rounds. This month, I’d like to interview people in public spaces about their food practices, prototype the experience of cooking with friends online using Google+ Hangouts, and begin creating wireframes & user flows for site experience.

What’s a food system? And why does it need hacking?

The term “food system” refers to a complex network of processes and relationships that serve to bring food from producer to consumer. This encompasses everything from politics to cultural beliefs to the natural environment to technology to our own individual senses of taste. A regulatory bill, a Thanksgiving dinner, a few million plankton, a plastic bottle, and a person’s choice to be a vegan are all part of the food system.

So is a government-subsidized, corporate-sponsored school lunch; an animal in a Confined Animal Feeding Operation; an overweight stroke victim on a hospital bed; a bunch of grapes laced with pyretheum; an illegally immigrated meatcutter whose hands can no longer move; a lake filled with nitrogen where no fish can live. These are all reasons that the food system needs hacking.

All these things, taken together, are a lot to tackle, far too much for a tiny little one-year project. So my first task is to learn as much as I can about the various ways I can effect change. And then choose one to chisel away at, in hopes that it’ll make a bit of positive difference.