Learning to dance, a.k.a. what thesis is teaching me about design risk and process

After writing the previous blogpost on audience and reading a post by classmate Michael Yap on minimizing design risk, it suddenly hit me:

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!