The Designer-Driven Startup
500 Global Team
PUBLISHED
2011.07.06
SHARE
TAGS
The author, Zach Weiner is the co-founder of Storytree, one of the first d.funded companies. Zach is the product of the Stanford Symbolic Systems program, equal parts computer scientist and designer. This post is the second in a series about the design-driven startup. The first, entitled “The Designer-Driven Startup: Why”, explains the need for a new kind of startup, and it can be found on the Storytree blog. This post details the solution.
First, since design is an overloaded word, a clarification about what design means to us (I’m not talking about making things look good): design is a process* concerned with a product’s meaning, not just its use and usability.
While design in this sense of the word is not yet what people usually mean in the startup world, much of the process is familiar and practiced already. In fact, its key tenet has even been adopted by the popular lean startup movement: fail early and often. Usually manifested through lo-fidelity product testing with users, this serves to eliminate risk in a venture when it is cheapest (early failures cost less and risk falls with each iteration).
Still, there is much more to design thinking, and if “making something people want” is the golden standard, then design may be the perfect tool. The problem is that making something people want is a fairly complex goal, and even if you can build, ship, and test at lightning speed, it is highly unlikely that you happen to hit on that magical “something”. So, we decompose it into three pieces, each of which our process addresses:
1. Who are the “people” exactly? It’ll be tough to convince me that it’s everyone, and saying it’s “people like me” is likely to mislead you, because as you build you’ll think, “I like this so others will too” without realizing how biased you are. So we begin by empathizing with our users and understanding them as complex people. For instance, we discovered that many baby boomers are afraid of losing their family’s stories and felt detached from loved ones spread around the country or the world, and decided to design for them.
2. What do they want? The answer to this question does not yet mandate a particular solution. For Storytree, the need we uncovered was not “an internet service that will record you and display your story privately and prettily with features X, Y, and Z.” The need was “a way to explore meaningful stories with loved ones before those stories are lost.”
3. What can we make that gives them what they want? This is the actual solution, with a feature list. We take the our user + need + insight and come up with ways to answer the questions about our solution. We are especially liberal with the ways we can prototype and test; we may even test with “extreme” users prototypes that barely resemble our product — this way hidden problems become obvious. By setting up storytelling booths for grandparents, we reached a key insight: it’s tough telling a story to a blank slate, so we provide prompts to start people off.
Note that very often the solution has a broader reach than was originally expected — in our case, Storytree can be used for groups of old friends that want the stories behind a semester abroad rather than just the pictures. But our process assures that we do not make assumptions about any of these pieces. As a result, we can all but guarantee idea-market fit. From there, we can iterate on various pieces of the solution until we reach product-market fit.
Ultimately, engaging our users on a deep level helps us build products that inherently have meaning.
The next post in this series discusses the challenges with a designer-driven startup.
——
*The human-centered design process for those new to design thinking:
You start by empathizing with a specific user in order to uncover a core need and an unexpected insight that will drive innovation. user + need + insight define a point of view, which will focus your process. You quickly flare, ideating as many wild ideas as possible based on that POV, before focusing on a few ideas that you can make practical. You then prototype and test multiple ideas quickly with your users, at extremely lo-fidelity (frequently in < 1 hr), meanwhile building a hi-fidelity solution that incorporates your learnings from each lo-fi prototype. At every stage, you loop back to make sure that what you are doing is consistent with your POV, and often change both your POV and your solution (if you want to, I suppose you can call it a pivot).
For methods, see the d.school bootcamp bootleg:
500 Global Team
SIGN UP TO STAY UP TO DATE ON GLOBAL INNOVATION
