Given my experience designing products, I couldn't help but notice the parallels between Real Options theory and what I think is a good design approach. Both have a certain level of "strategic humility" - admitting that the future is a complete unknown and that uncertainty should be accepted and embraced. Like Real Options, a good design process produces artifacts that help a design team understand an uncertain environment or market, thus reducing potential risks of delivering unwanted products or services. Note that I'm referring to a "design-centric" approach, and not necessarily an approach for designing aesthetically-pleasing products (although I would argue the latter should come from the former). This method is generally known as "Design Thinking" and has grown in popularity in recent years thanks to the highly innovative strategic design consultant, IDEO. I highly recommend Tim Brown's "Change by Design: How Design Thinking Changing Organizations and Inspired Innovation" for more information on this topic.http://www.amazon.com/Change-Design-Transforms-Organizations-Innovation/dp/0061766089
The following are my quick thoughts on some of the most prominent uncertainties in a product development process and the ways that a design approach can help manage them. This is certainly not an exhaustive list, just some of my favorites from my own experience.
Uncertainty 1: Ideation ("What do we do next?")
Most product or service producing organizations spend a great deal of time planning ahead for what's next. It could be a completely new product, an updated version of an existing product, or even just a new market for a product that's been around a while. But how do we best determine what that next product should be? It's been well established that asking potential users what they want will only lead to incremental (i.e. boring) improvements. People point to Apple saying that they don't need to talk to users at all, and it's some internal "magic" that makes them great. That's all well and good, but it doesn't help much when you're tasked by your manager to plan the next version of your flagship product.
This is the point where design helps de-mystify the ideation process. I've been in countless user interviews over the past decade, and I can honestly say there's no greater waste of time for the designer or the potential user to sit there face-to-face and ask "what do you want"? Instead, translate your undeveloped ideas and untested hypotheses into "visual ideas". These may be concept sketches of potential products, diagrams of new user experiences, or even just a drawing to attempt to represent the user's mental model. Note that these DO NOT require even the slightest bit of artistic ability. In fact, rough and sketchy is often better as it conveys a sense of early-stage flexibility. The point is that the sketches provide a common frame of reference or "anchor" for the conversation with your user. They can force the participant to think in new ways, or even just to tell you that your thinking is completely wrong. In fact, going in with an "incorrect" diagram or sketch is completely fine if it allows the person to point out what they don't want - this can be just as helpful. Finally, an perhaps most importantly, graphics provide a common language that everyone can understand, it breaks down the barriers between technical jargon and non-technical speech, and it reduces the ambiguity that can come from speech-based language interpretation.Uncertainty 2: Product Vision ("Are we all on the same page?"
Once the idea for the next product or iteration has been determined, a development team can just start crafting a requirements document and project plan, correct? Not exactly.
Even the most clear product ideas have some level of ambiguity at this early stage. While some objectives or expectations may be in place, the expected output is often undefined. Let me first say that this is a great thing - projects should not only allow but promote exploration and iteration. However, the problem is that individuals on a team often have their own personal vision of the expected output of the project. This problem is then compounded by the fact that those individual visions are often clearly defined in the minds of those folks. The reason for this is that vision for products are often communicated in words, which is highly vulnerable to conflicting interpretations (e.g. "Version 1.2 is going to be net-centric and integrated!") What results from this approach is a situation where project members work on diverging or conflicting paths without realizing that they don't share the same viewpoint of a final end state. Team members debate endlessly over detailed technical decisions, not realizing that the source of their disagreement is not on the decision itself but the fact that they have conflicting views of a desired end state.Project managers attempt to establish consensus with daily check-in's, agile development processes, and related practices. However, in my opinion, these approaches always fall short of optimal without a visual or design-centric approach.First and foremost, a design-based approach clarifies vision and establishes consensus. This is what is so powerful about the Design Thinking approach. I cannot recommend enough the act of visualizing a project's vision before any engineering or "production" related work even begins. Again, this doesn't require a lick of design skills. Instead, all that is needed is a series of wireframe sketches or diagrams of the expected product, underlying architecture, expected workflow or user experience, and supporting services. On top of that, build one simple visual depiction of the system you're building (e.g. people, products, services, technologies) of which team members can point to and say "we're building that". If you have the ability, try creating a rough 30-60 second video or animation of your vision for the product or service you want to create. You may be surprised how much internal clarity this provides.
Uncertainty 3: Requirements ("What should it do?")
Now that the product vision is clear, it's time to determine requirements. Personally, I prefer a completely experience-driven approach, although I know it can drive engineers crazy (so tread lightly here). My favorite approach for this is to simply get in front of a whiteboard and walk through the expected experience of using your product or service. Stay within the bounds of reality, but ignore detailed technical constraints at this point, as they may unnecessarily block a path to a good idea. In other words, exploring bad or impossible ideas often leads to good ideas.
As the team visually draws out the expected user experience, a great deal of clarity is often formed. It is here that a sense of a "system" is developed, which is far more effective than building a fragmented list of requirements. In fact, by going with a requirements-driven process, you're more likely to result in features that only add to the user experience and not improve it. I don't think I would want to pay the production cost to have those built.
With this visual, systems-based, experience-driven approach, the requirements become a byproduct of the user experience, as opposed to the driving factor. What results is a more holistic, efficient set of requirements. In fact, many great ideas for services or features are often prompted by this process as unexpected paths or relationships are often revealed.
Uncertainty 4: Market Demand ("Will people want it?")Once the product and all its bells and whistles are imagined, there's still one question to answer before production begins: "Will people want it?". Of course, this is a slightly different question than "will people buy it?", but this is a design blog and not a marketing blog, so I won't get into the process of determining viable pricing points, etc. This point here is to use design to test the waters in the outside world. Internal consensus has been developed, but how do you know that your assumptions and expectations are accurate without talking to people outside your organization? This is where a great prototype or concept animation can be incredibly valuable. Have someone review your storyboard and see how they would react. Perhaps you've developed a perfectly thought out idea based on incorrect assumptions.
Be careful here not to overreact to people's opinions. As mentioned earlier, it's difficult for people to think beyond incremental improvements in their daily lives. As a result, they may react to your idea as being "strange" or "crazy". That said, pay close attention to the types of responses you get, the emotions it evokes in people (e.g. boredom, excitement), and the "between the lines" messages you might receive.
Uncertainty 5: User Experience ("Will people enjoy using it?")
Tim Brown strongly conveys the importance of being "fast to failure". This means that the goal of a product or service-producing organization should be to develop a prototype of their system as quickly as possible to figure out whether or not it's worth producing. This is most commonly done to rule out bad ideas. As mentioned in the introduction, this design process is really about strategic humility, and this is never more true than in these later stages. I strongly suggest that you not be overly confident in your ideas or your designs, as they are likely wrong..or more accurately, not as good as they could be. What you should have confidence in is your ability to get them right. This shift in mindset is critical for the "fast to failure" approach and will allow you to learn from and improve upon the flaws in your product.
Perhaps the most important lesson of addressing this uncertainty is the incredible return on investment that can come from fixing usability-related issues at an early stage. The cost of fixing a flaw in the design may seem signficant, but it's nothing compared to the compounding effects that will come from releasing a difficult-to-use product or. poorly designed service. For more on this topic of the ROI of User Experience, check out Dr. Susan Weinschenk's video presentation: http://www.youtube.com/watch?v=O94kYyzqvTc I hope this overview of designing for uncertainty has been helpful to you. Your thoughts are greatly appreciated!
No comments:
Post a Comment