Lean UX: Getting Out Of The Deliverables Business. Advertisement User experience design for the Web (and its siblings, interaction design, UI design, et al) has traditionally been a deliverables-based practice. Wireframes, site maps, flow diagrams, content inventories, taxonomies, mockups and the ever-sacred specifications document (aka “The Spec”) helped define the practice in its infancy. These deliverables crystallized the value that the UX discipline brought to an organization. Over time, though, this deliverables-heavy process has put UX designers in the deliverables business — measured and compensated for the depth and breadth of their deliverables instead of the quality and success of the experiences they design. Designers have become documentation subject matter experts, known for the quality of the documents they create instead of the end-state experiences being designed and developed. Engaging in long drawn-out design cycles risks paralysis by internal indecision as well as missed windows of market opportunity.
Enter Lean UX. Chill the fUX out. Lean is here to stay - We Love Lean | Lean UX, Lean Startup. Is There Any Meat on This Lean UX Thing? By Jared M. Spool Originally published: Nov 30, 2011 Out of nowhere, Lean UX is now a hot topic for UX professionals, generating the complete range of responses, from complete buy-in to calling it complete bulls**t. Is there really something to this? Or is it, as I've heard several times now, an attempt to rebrand what we already do in the name of selling more workshops? I was very curious about all this, so I set out to learn what Lean UX was all about.
I've talked to dozens of folks in all areas of the UX field and dug into what people mean when they talk about it. My conclusion: There really is something here. Step Into the Wayback Machine, Sherman To get a solid handle on why I think Lean UX is now important, we have to go way back into the past—to the 1960s and 1970s. However, as people found new uses, the size of the software projects grew. For these initial mainframe applications, the SDLC brought a ton of order to what otherwise was a lot of chaos. Moving from Hundreds to Millions. How to Get the Team Behind Your Product Idea by ZURB. You have an idea for an awesome product, but your team isn't bought in.
You need them behind you or else your idea will die a quick death. How do you turn the tide in your favor? Over the years, we've had this very problem and learned some hard lessons from it. We learned that internal advocates, people who share your passion, can help rally the rest of the team behind your idea. Get Early Feedback, Build Momentum Soliciting feedback as early as possible gets buy-in from the team, building momentum for your ideas. Take for instance the early stages of developing Verify. Bryan, however, wasn't just soliciting the team's feedback on Verify.
Build A Crude Prototype, Show Value Quickly One way to showcase value in an idea is to build a crude prototype. Sure, we've all heard the story of Art Fry's "Aha moment" when he struck on the idea of marrying Spencer Silver's "weak adhesive" concept to a bookmark when his own mark fell out of a hymnbook. When management ran out, they asked for more. Fucking Ship It Already: Limited Products vs Shitty Products. In our second installment of Fucking Ship It Already, we deal with a common problem for startups: shitty products.
Look, I know that building a product with one or two engineers and no money is tough. As an entrepreneur, you almost certainly have far more ideas than you have resources to create those ideas. And it doesn’t help that you have people like me screaming, “Ship it! Ship it!” Who could possibly blame you for shipping a product that is, frankly, kind of shitty? I could.
Let’s take a step back and try to understand the difference between a shitty product and a limited product. One big difference is that I wholly endorse shipping a limited version of your product. A limited product is something that may not do much, but what it does, it does well. It is not half a big product. Most importantly, a limited product is just big enough and good enough that you can learn something important from it. But a limited product probably doesn’t do anything else. And they did it really well. Making Sense of Minimum Viable Products. Minimum Viable Products–what does this mean? If you read any article or listen to any talk about minimum viable products, you will notice that the word “confusion” shows up early and often: Steve Blank: “This minimum feature set (sometimes called the “minimum viable product”) causes lots of confusion. Founders act like the ’minimum’ part is the goal. Or worse, that every potential customer should want it.”
It’s not just that the concept is confusing. MVPs are born from confusion: the “extreme uncertainty” that Ries defines as a fundamental condition of a startup. Making Sense of MVPs Rather than trying to definitively make sense out of MVPs, I stress that “making sense” is what MVPs are about: MVPs are mechanisms to create meaning where little or none currently exists. It doesn’t matter if it’s actually a product in the traditional sense. What is a meaningful set of features for customers? Meaning as visionMeaning as learningMeaning as method Meaning as Vision Meaning as Learning Final Thought. Quick, Visual, Collaborative & Continuous. 2012 feb 25 agile ux nyc, seiden, requirements to hypotheses. Fucking Ship It Already: Just Not to Everyone At Once. There is a pretty common fear that people have.
They’re concerned that if they ship something that isn’t ready, they’ll get hammered and lose all their customers. Startups who have spent many painstaking months acquiring a small group of loyal customers are hesitant to lose those customers by shipping something bad. I get it. It’s scary. Sorry, cupcake. Do it anyway. First, your early adopters tend to be much more forgiving of a few misfires. Still nervous? The Interactive Mockup A prototype is the lowest risk way you can get your big change, new feature, or possible pivot in front of real users without ruining your existing product. If you don’t want to build an entire interactive prototype, trying showing mockups, sketches, or wireframes of what you’re considering. Get on a screen share with some users and let them poke around the prototype. If your product involves any sort of user generated content, taking the time to include some of the tester’s own content can be extremely helpful.