Lean UX at Startup Lessons Learned

This week I had the pleasure of speaking about UX at Eric Ries’ Startup Lessons Learned Conference. The event is at the center of the Lean Startup community and was attended by 400 entrepreneurs, developers, product managers, investors, and designers, with a simulcast audience of equal size.

I joined the “Design + Lean Startup = Lean UX” panel with Josh Seiden, Jeff Gothelf, and Zach Larson, hosted by Janice Fraser. We discussed the value of design in defining products and services, and shared techniques for incorporating design into startup culture and organizations.

The startup community is hungry for good UX, and entrepreneurs, investors, and developers alike are recognizing the value and experience designers can contribute to a successful product team. Here’s some highlights of the overwhelmingly positive response:

#leanux is awesome. silicon valley companies both large and small can benefit from it. my learning from #sllconf

Super motivated & inspired! started morning watching “Design + Lean startup = #LeanUX” talk

You could hear a pin drop in here while @clevergirl explaining “test / invest” or “prove / improve” cycles.

Customer dev and UX are the same thing. Epiphany.

@manjeetdadyala Loving the leanUX panel. Eye opening session. #sllconf #leanux +1 Very important to bridge design & dev

And perhaps my favorite, here’s a reminder we designers are not the only ones saying “duh, if you’d listen to what I have to say, things could be so much better!”

Designers and consultancies are starting to understand&embrace #leanstartup. Not only cost of deployment&development has changed

For your viewing pleasure, here’s the Justin.tv archive of the panel (my talk on Product Stewardship starts around 21:30.)

Watch live video from Startup Lessons Learned on Justin.tv

You can find the deck on slideshare here:


I encourage you to watch all the segments from the conference. A few in particular stood out for me:

Brad Smith of Intuit discussed how his Fortune 1000 company runs on startup principles: no teams larger than two pizzas can feed; hire good people and provide an environment for them to succeed; and foster a strong sense of responsibility throughout the team.

Mitch Kapor talked about his transition from old-school entrepreneur to lean startup advocate and how his overnight success at Lotus lead him to believe it was easy: “I gave bad advice for 25 years.”

James Birchler of IMVU detailed lessons his team learned about the limits of A/B testing and the value of developing good hypotheses to validate through testing and feedback.

Finally, please take five minutes to watch Eric Ries’ closing remarks – he does a great job summing up the spirit of the day and highlights the value of design to the Lean Startup movement.

Watch live video from Startup Lessons Learned on Justin.tv

Related Reading

Read More

Lean UX, Product Stewardship, and Integrated Teams

Several emergent themes in software design and development are converging into a new way of working:

  1. Entrepreneurs understand the strategic value of user experience design in the guise of Steve Blank’s customer development and Eric Ries’ lean startup
  2. Management are entrusting designers with product management responsibilities as frustrated designers are seeking them out
  3. Agile teams are coming to recognize the contribution of UX as designers learn to function in agile environments

Each of these ideas have significant impact on the way user experience designers approach their work and how businesses structure their design and development efforts. Together, Lean UX, Product Stewardship, and Integrated Teams define a cross-functional, balanced approach to delivering software and services.

Lean UX

Traditional User Experience (UX) design techniques were developed in waterfall environments. Designers conduct research, develop models, derive frameworks, and specify detail with the understanding that they have to get it “right,” because once the product enters development, changes are difficult and costly.

Lean UX leverages the highly fluid nature of modern lean and agile development practices. It focuses design and development effort on high value users, features, activities, and experiences, and in so doing, reduces the wasted effort and cost of spending time on issues that don’t really matter (or don’t matter right now). Teams work to shorten the time between forming design hypotheses, testing them, and learning from the results, accelerating delivery while improving quality. Designing and building from the core out helps tune your product vision in response to stakeholder, market, and user feedback.

Lean UX is not interaction design shoehorned into agile frameworks. Product vision, user research and modeling, and truly evolutionary iteration are central to this approach. It stresses lightweight, collaborative, right-fidelity UX techniques to generate, test, and evolve the design of your product.

Product Stewardship


The responsibilities of an agile product owner are vast, difficult, and conflicted. Typically a role derived from product management, product owners are tasked with fulfilling business objectives; they’re expected to identify and represent user needs; they must define and drive the product vision; they need to understand and prioritize development efforts and represent the team to business stakeholders. This is not a job one person can do effectively.

Product stewardship relieves pressure on the product owner bottleneck. A UX strategist assumes the role of Product Steward, pairing with a Product Manager to share the mantle of product ownership. The product manager has a bias towards representing the business, the product steward towards satisfying the user, with a recognition that an interplay of these forces drives prioritization of the team’s activities.

Integrated Teams

UX has had difficulty finding its footing in agile development. Design work doesn’t always fit the cadence of weekly sprints; designers can feel their job becomes a perpetual state of reactive, tactical design; iterations designers thought meant cycles of improvement turn out to mean a progression of micro-deadlines where “done” means “good enough to move on.”

Integrated teams extend full membership to interaction designers, visual designers, content strategists, and anyone else who contributes to shaping the product. Most importantly, these cross-functional teams work in pairs: often as like-disciplined partners, but also as designer/developer pairs. This format reduces communication issues and documentation overhead, develops cross-functional empathy, and gives the whole team increased understanding of product vision.

What you can do

I’m terribly excited to be part of this movement to bringing balance to software development teams. You can get involved as well and, in fact, we need you to drive this change in your organizations. I’ve posted a deck to slideshare.net of a talk I gave at a side event of IxDA11 in Boulder, CO on Feb 8. Feel free to use it to help start conversations at your office and in your communities about how to improve your ways of working. Join a local meetup to talk with others about the integration of design into lean and agile development. Read blogs and follow the emerging voices in the community of lean user experience and balanced teams. Most of all, trust In the power of user-centered design to inspire, delight, and guide your teams forward.

Other resources

LeanUX workshop recap

In partnership with Janice Fraser of LUXr, Cooper hosted a two-day workshop to share our emerging thoughts around lean user experience and agile product stewardship with a group of designers, developers, and product strategists from Cooper, Adaptive Path, Hot Studio, 500 Startups, and several other organizations.

luxi day 1.jpg

We spent the first day exploring the intersecting arcs of lean startup, customer development, user centered design, and lean and agile development. Each of these approaches to making software look at the puzzle from a unique perspective: lean startup and customer development come from the world of business and entrepreneurship; lean and agile development practices strive to build healthy collaborative teams and coerce order and purpose from the sometimes chaotic world of programming; user centered design emphasizes understanding and empathy for people served by the software we create. Lean UX and product stewardship seeks to weave together best practices from all of these approaches.

Material from first day of the workshop is available on Slideshare.net at


luxi day 2.jpg

The next day, the group put their new thinking to work helping Change.org envision and clarify a new initiative. It was fascinating to see founders of early stage startups and consultants to Fortune 500 companies find common ground in their approaches. Some were learning to recognize the particular value of narrative to provide context around features, others identifying places where their existing processes could be more lightweight or robust. When we were done, the fine folks of Change.org had three promising approaches and everyone understood a little bit more about how to move our practice forward.

I’ll have much more to say about the ideas and practices behind lean UX and agile product stewardship and I’m excited about sharing our experiences and learning from yours. Read More

Announcing LUXi: the lean ux intensive

Every now and then, somebody comes along who helps you look at things from a fresh perspective. They take something you’ve been working at, reframe it in their own way, and return it to you better than ever—and in the process, prove once again two heads are better than one. LeanUX is that somebody.

Entrepreneurs like Eric Riesand Andrew Chenare busily advocating an approach for lean start-upsto take a customer-centered view of their products and services. The argument goes that a focus on identifying and responding to your customers’ needs allows lean start-ups to create better, more successful products faster. This understanding and focus on users as the driver of product development is, of course, the heart of user centered design.

The business community is awakening to the immense, transformative power of UX. The time has come for us to accept the responsibility and use it wisely. Cooper is partnering with LUXr:the lean user experience residencyon a program for designers, product managers, and developers to share tools, techniques, and attitudes of lean and agile user experience. Join us for a few days then bring your newfound energy and experience back to your team—or bring them along!

LUXi: the lean user experience intensive, is a two-day workshop focused around four big themes:

  • Users first! Design is bigger than wireframes and mock-ups
  • Being generative and decisive, and the importance of making things physical
  • Recognizing hypotheses and validating them
  • Rapid cycles of think/make/check

The intensive will be facilitated by Janice Fraser of LUXr and Tim McCoy, Cooper’s Director of Integrated Product Development. If you are a designer, product manager, or developer working in a lean or agile team (or wish you were), come hang with us and reframe the way you think about design, your products, and your organization.

The workshop will be held in Cooper’s San Francisco offices on January 26 and 27, 2011. Information and enrollment is available at



Read More


I’ve been struggling for days to put into words my reaction to the launch of Google Buzz. But the phrase I can’t get out of my head is “HOW could they screw up THIS MUCH?”

Well here’s how: Google took Gmail, one of the most widely used web services on the planet, and modeled a quantum change in its behavior with an insulated, private, corporate, top 1% tech-savvy user base.

Google Buzz creates an instant social network based on your email history. Google engineers wrote an algorithm to analyze years of correspondence in users’ Gmail accounts. At launch, by default, these associations were automatically linked and shared with everyone else in your “network.” [Google has already modified the default behavior twice in response to criticism].

Apparently, Google tested Buzz internally for months prior to public launch last week. Unfortunately, the controlled conditions of corporate email are a poor stand-in for conditions “in the wild” of a public email service.

You could imagine that the post-launch backlash could have been anticipated with a bit of forethought, even an afternoon meeting that went something like this:

1. What types of people use Gmail?
2. What do they use it for? Who do they communicate with and why?
3. Does our internal beta account for those types of uses?
4. If not, how do we introduce this service to people who aren’t like us?

At a bare minimum, identify a set of people who represent a cross section of users: A grandparent who switched from AOL; a high school junior with an active and evolving social circle; a struggling factory worker in a hostile political environment; a professional with a secretive private life.

Then, just as a sanity check, ask “Is there anything problematic with mining the history of their person-to-person emails and creating a single transparent group from that list?”

For many things, Google’s approach—develop, internal beta, release, measure, adjust—is an adequate way to stumble towards a better experience. That approach takes good ideas, puts them in play, then sands down the rough edges and suggests enhancements. For something as significant as combining email and social networking, it’s toxic. Read More

Interviewing Kids

I recently had the opportunity to return to a place I hadn’t been for quite some time–the principal’s office. My last project included interviewing 11-17 year olds about their homework habits, and I needed a hall pass from the secretary. In preparing for the interviews, it occured to me that I hadn’t spoken to many ‘tweens since I was one myself. Would they call me Mister? Ask to trade Bakugan? And the high school kids–would they be too cool to talk to me, answering every question with nothing but a yes, no, or dismissive smirk?

hall pass.jpg

As it turns out, interviewing school-aged children isn’t too different from interviewing adults. But as I learned, there are a few do’s and don’ts you might do well to keep in mind.

Have an adult introduce you to the child
Allow a parent, teacher, or guardian to make initial introductions. This establishes your credibility to the child and communicates the adult’s consent for conducting the interview.

Treat kids like regular people (that is, like adults)
Kids can tell if you’re being patronizing and will adjust their own behavior accordingly. Treat them as you would any interviewee, thanking them for their time and explaining what they should expect from the session.

Interact with them at eye level, but don’t get too close
Minimize physical power dynamics by sitting in a chair or kneeling alongside kids when you conduct the interview. At the same time, be aware of their personal space and don’t give them a chance to feel vulnerable or uncomfortable with your presence.

Be specific with your questions
Kids tend to be quite literal in adult conversations, so be direct with the questions you ask and the responses you give. Don’t be surprised when you point to a toolbar and say “what do you think these do?” and the response is “save saves, print prints, open opens, and delete deletes.”

Avoid technical and professional lingo
You’ve picked up a career’s worth of acronyms and jargon that your interviewee will not be familiar with. Also, look for the words kids use to describe things, and use those both in your interviews and when designing for your young audience.

Don’t ever take pictures or video without parental permission
There are many legal and ethical issues around photographing and videoing minors, and if you don’t have a clear need for it, don’t bother. If you do ask, be prepared to take no for an answer without any further discussion. Put parents/guardians at ease with things like “we only use these internally for reference” and “don’t worry, this won’t end up online or on TV.” When appropriate, set up your video to capture the session without recording the child’s face, for example by training the camera on the screen when discussing software.

Don’t crack jokes or be sarcastic
Kids won’t be prepared for casual joking, for as much as you work to set up a peer relationship they are still talking to an unknown adult. Jokes will often be misinterpreted as serious comments. As an example, I was running a feedback session with a powerpoint deck that ended with a blank screen. When one child clicked past the last prototype slide and into the blank screen, I remarked “OH! You broke it!” then spent the rest of the interview making him feel better that he hadn’t just busted our computer.

Recognize when an interview isn’t going well and finish it quickly
This happens with adults too, but sometimes you’ll get a kid who just isn’t able to converse with you. Spend a minute or so looking for an opening, and if you can’t break through, let them out of their misery and end the interview quickly. Don’t abort it or say it’s not working, just ask a few easy, obvious questions, thank them for their participation, and move on.

What else?
I’d love to hear more about other people’s experiences interviewing children and involving them in user feedback sessions. What advice do you have?

Read More

Is Interaction Design a dead-end job?

IDEO’s Bill Moggridge made a comment last week after a screening of Objectified that hit close to home. To paraphrase, he said interaction design has become pervasive, that anyone and everyone can be an interaction designer, and so the role of professional interaction designer is (or is becoming) unnecessary.

So, is Interaction Design a dead-end job?

As an expertise, no. But as a discrete service offering or a career path, I say absolutely.

This position has not made me any new friends around the office, but to be clear, I’m not suggesting our profession is akin to flipping burgers at the mall. Instead, it’s that interaction design has reached a point of maturity where growth is constrained. I see three major factors behind this and hope that by acknowledging them we can find a way forward. Read More

Software is a movie, not a building

In a previous post I suggested that film making is a good analogue for discussing software design and development, that lessons learned there could help us think about better ways to approach our own projects. I established the similarities like this:


Much beer has been spilled over comparisons of software to physical architecture, and while the analogy is interesting it is inherently flawed. For the industrial-age activities of designing and constructing a physical building are vastly different than the post-industrial process of designing and building a digital artifact of conceptual ideas, where cost is measured by time rather than materials and success measured by consumption and desirability.
Read More

Goals! Prototypes! Action!

A thread in comments on a post from Michal Migurski got me thinking about the analogy of film making to software design and development. The more I explored the idea, the more multi-faceted the analogy became.

Movies and software are both very creative and very custom-craft intensive. They are both extremely collaborative — moreso than almost any other endeavor. Both encompass a wide range of styles, audiences, scale, and budget. For each there is a relatively subjective determination of completeness, that point at which the product is ready for release. And history is littered with spectacular successes, and failures, both within and outside the formal “system.”

We can learn a lot by looking at parallels between film making and software, if only to recognize the issues we face around budgets, timelines, clarity of direction, conceptual and tactical authority are not unique. We can recognize that there are numerous models to adopt or avoid as the situation demands. It allows us to examine the interplay of money, talent, ego, authority, collaborative energy, role specialization, and market forces at a comfortable distance while learning lessons applicable to our own work.

To begin, let’s establish a basic model that compares the film making process to the software making process. In a loosely time-based perspective, consider these parallels:


Naturally, there are countless variations to this flow, with more or fewer steps, multiple feedback loops, things happening in parallel, and so on.

Moreover, countless questions that fall out from this comparison:

  • Is there a parallel in the world of software to a screenplay?
  • How do the roles in film making relate to the roles of software?
  • Which types of movie productions are similar to the various types of software projects?
  • How are feedback, iteration, and evolution handled in film vs software?
  • Who exerts creative control, assesses market viability, predicts audience acceptance?
  • How is technology changing established ways of working?

I’ll explore more of these in subsequent posts, but for now, I’m curious to know if this analogy seems useful. Are there other lessons that can be drawn?

Read More

Meeting the expectations of the design

At Cooper, we’ve historically advocated a clear and explicit separation of interaction design and software development efforts. Underlying this position is the assertion that the job of interaction designers is to serve as user advocates. We approach the design problem not by asking “What can we deliver?” but “What do people desire?”

We’re guarding against the urge to focus on the development and delivery of software, hardware, and services before we understand its value to the humans using the system. By no means does that suggest our designs should ignore business and technological factors, only that our designs should be influenced primarily by our the motivations of the users represented by our personas.

The design must meet the needs of its users, and it follows that the product’s creators (designers, business folks, developers, etc.) deliver a product that meets the expectations of the design.

But how to design so that those expectations can be met? It’s a delicate balance. Ideally, there is a healthy interplay of possibilities and limits between the business factors, technology issues, and design motivations. Each group shares the goal of delivering the best product possible with the time, budget, and expertise available.

Here are some ways to keep a user-centered focus without losing sight of the factors that influence development:

Understand the business situation

Get a clear sense of the breadth of the design mandate: Is management pulling out all the stops to create a category-killer, or have they set a firm cap on the time and resources available to the project?

Know your medium (but not too well)

Understand enough about the technologies underlying the product so you can leverage things it does well without falling into the trap of designing to technical capabilities rather than user needs.

Listen to developers’ concerns and ideas

Recognize that every one of your design decisions impacts the work developers will need to do to implement and support them. Solicit their input on the design’s feasibility and seek their advice on ways to make the design more achievable. Your concern should not be that you’re signing developers up for hard work (after all, solving hard problems is what being a developer is all about)—it’s signing them up for unnecessary hard work.

Don’t concede your personas’ needs to business or technological limitations

If you’ve done your homework, you know what the product needs to do (and not do) to satisfy its users. If technical or business issues are in conflict with a persona’s needs, speak up. Demonstrate the value of your design to business and technology stakeholders to help them see the merits of accommodating the design intention.

Pick your battles

Be comfortable with letting some technology and business considerations trump design ideals. There are situations where a less-perfect standard implementation of one feature means more time to develop a custom feature that truly delights your users. Too many of these is death by a thousand cuts, but everything doesn’t have to be ideal for the things that really matter to be fantastic.

The reconciliation of technology, business, and user-centered design is ultimately a business decision. The most fabulous design will never see the light of day if it doesn’t meet business objectives or isn’t technically feasible. By understanding the business and technical landscape, working across disciplines, advocating for your users’ needs, and knowing when to compromise, you can produce successful designs—successful because they meet the needs of users and the needs of developers and business stakeholders. Read More