"Lean UX" entries
Towards continuous design
A deep integration across design, development, and operations is critical to digital business success.
I just finished reading Thomas Wendt’s wonderful book, Design for Dasein. I recommend it to anyone who practices, or just is interested in, experience design. Wendt’s ideas have profound implications for rethinking and improving our approach to designing experiences. They also have profound implications for how we think about DevOps, and its relationship to design, and how that relationship impacts the nature and purpose of digital business.
Design for Dasein introduces what Wendt calls “phenomenological design thinking.” This is a new approach to design that expands the designer’s attention beyond creating things that people use, to encompass thinking about the ways in which things influence, interact with, and are influenced by how people experience the world. Phenomenological design thinking reflects two key insights about the role of designed objects in peoples’ lives. First, designers create possibilities for use rather than rigid solutions. Wendt cites the example of using an empty coke bottle to hold open a door in an old, crooked apartment. By itself, the bottle wasn’t heavy enough to keep the door from swinging shut, so he filled it with pennies. At that point, the bottle suddenly had three overlapping uses: containing and drinking soda, holding opening one’s bedroom door, and storing spare change. Wendt’s point is that the designer does not entirely control the object’s destiny. That destiny is co-created by the designer and the user.
Knowing when not to design
Don’t waste time on features that users don’t want.
Attend “UX Design for Growth,” a training session by Laura Klein that will give you the skills you need to design products that convert and retain users.
After many years as a designer, I’ve realized that some of the most important design decisions have nothing to do with what any of us consider design. Instead of designing the perfect version of a feature, sometimes the best thing we can do is learn that we shouldn’t build the feature in the first place.
In my all-day, online workshop on September 15, 2015, I’ll be talking about another aspect of building products: how to make them grow. Potentially fabulous products fail every day because product managers and UX designers don’t spend enough time thinking about how their product is going to be discovered by new users.
The following is an excerpt from my book, UX for Lean Startups, where I give one practical tip for learning whether or not you should build a specific feature for your product. If you’d like some practical tips on getting people to start using all those features you decide to build, please join me on September 15th for my UX Design for Growth training session. Read more…
MVPs and experiments inform design decisions
The sooner we can find which features are worth investing in, the sooner we can focus resources on the best solutions.
Editor’s note: This is an excerpt from our recent book Lean UX; it is part of a free curated collection of chapters from the O’Reilly Design library. Download a free copy of the Experience Design ebook here.
Lean UX makes heavy use of the notion of minimum viable product (MVP). MVPs help test our assumptions — will this tactic achieve the desired outcome — while minimizing the work we put into unproven ideas. The sooner we can find which features are worth investing in, the sooner we can focus our limited resources on the best solutions to our business problems. This concept is an important part of how Lean UX minimizes waste.
Your prioritized list of hypotheses has given you several paths to explore. To do this exploration, you are going to want to create the smallest thing you can to determine the validity of each of these hypothesis statements. That is your MVP. You will use your MVP to run experiments. The outcome of the experiments will tell you whether your hypothesis was correct, and thus whether the direction you are exploring should be pursued, refined, or abandoned.
The focus of an MVP
The phrase MVP has caused a lot of confusion in its short life. The problem is that it gets used in two different ways. Sometimes teams create an MVP primarily to learn something. They’re not concerned with delivering value to the market; they’re just trying to figure out what the market wants. In other cases, teams create a small version of a product or a feature because they want to start delivering value to the market as quickly as possible. In this second case, if you design and deploy the MVP correctly, you should also be able to learn from it, even if that’s not the primary focus. Read more…