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:

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

@dshdle
Super motivated & inspired! started morning watching "Design + Lean startup = #LeanUX" talk

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

@ClintonWu
Customer dev and UX are the same thing. Epiphany.

@rickperreault
@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!"

@geoffclapp
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: http://goo.gl/o5nVB

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

• Take the Design Collaboration and Communication class
• Better together; the practice of successful creative collaboration
• Lean UX workshop recap
• Lean UX, Product Stewardship, and Integrated Teams
• Integrating solve and do

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

• Balanced Team blog http://www.balancedteam.org
• Janice Fraser's luxr: the lean user experience residency http://luxr.posterous.com/blog
• Eric Ries' Startup Lessons Learned blog http://www.startuplessonslearned.com
• Brant Cooper and Patrick Vlaskovits' Entrepreneur's Guide to Customer Development http://www.custdev.com
• Andrew Chen's Lean Startup blog http://andrewchenblog.com
• Steve Blank's Four Steps to the Epiphany http://steveblank.com
• Startup Monthly Idea Accelerator http://www.meetup.com/StartupMonthly
• Twitter hashtags: #leanux #aux #leanstartup

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.

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 http://goo.gl/aJwdm

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.

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. Lean UX is that somebody.

Entrepreneurs like Eric Ries and Andrew Chen are busily advocating an approach for lean start-ups to 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 residency on 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 http://www.brownpapertickets.com/event/139435.

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:

AGENDA
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.

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?

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?

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.

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.

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?

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.

How important is it for interaction designers to be well-versed in the technologies they are designing for? Does good design spring from a firm understanding of the underlying capabilities and limitations of the technology? Or is it helped by an indifferent stance towards how a design is ultimately produced in order to consider the issues from a fresh perspective?

There are good arguments on both sides of this issue, and there’s no one right answer.

Many successful product design models rely on designers being fluent developers. Notably, 37signals can rapidly develop and iterate their products because the design thinking is intertwined with its technological manifestation. A firm like Stamen delivers such compelling visualizations because they can ingest and process data like developers then exploit their tools to consider and present the information and interactions like designers.

Other models feature greater role specialization. At Cooper, we have designers with varying levels of technical expertise, from ex-programmers to design-school grads with no development experience. We work to keep the consideration of technological possibility or constraint at arm’s length early in the design process in order to envision the best experience for our personas. As our designs progress, we work closely with the client’s development organization to vet feasibility and adjust the design in response to developer and business stakeholder feedback.

Several factors have made the question of this design/develop relationship more complicated than ever:

• Agile devlopment methods that stress iteration and feedback
• Development tools that make it possible for non-programmers to build prototypes, demos, even shipping code
• Increasingly dynamic interactions that are difficult to design and communicate without experiencing
• Increased awareness of goal-directed design methodology by software developers

Where do you and your team fall on this spectrum, and how are you dealing with these issues?

There's been a lot chatter around the office and internet about Chrome, the recently launched (or leaked) Google Web browser. I've got to say that much of it misses the aspect of the application that I find most inspirational. Google Chrome exists for one reason and one reason only: To provide a framework for web-based applications to look, feel, and act like desktop applications.

It doesn't seem that Google has real interest in replacing IE or Firefox as the dominant web browser. (The tech business press can't see beyond this point). Instead, Google wants to see the technological underpinnings of Chrome adopted by mainstream browsers. The Chrome team is explicitly inviting other browsers to use their code base — they've open sourced everything — and they have explicitly acknowledged adopting best-of-breed UI features from others.

So how does Chrome elevate web apps to desktop app status? Six ways: Separate processes for each tab; Google Gears for local storage, offline functionality and "native app" behaviors; application shortcuts; a modern JavaScript virtual machine; and minimal-to-absent browser interface, aka "chrome". Let's look at each one in more detail, with snippets from Scott McCloud's fantastic graphic novella product tour.

Many a software app has gone down the dead-end of attempting to recreate physical controls and affordances. (See the rich sub-genre of notebook apps with spiral binding and turned-up corners.) But sometimes the clarity and familiarity of a physical analog is just the thing. The key is to use it as a starting point, not to slavishly recreate the physical experience in its entirety.

A good example of this is the new audio capture app, TapeDeck. Modeled after an 80's-era cassette recorder and its collection of tapes, TapeDeck addresses a key issue in audio recording — the difficulty of distinguishing audio tracks in a visual world. Each recording is represented by a separate cassette tape, organized by date in a slide-out drawer called the Tape Box. It also gives a clear indication of state, running the tape spools in sync with the big push-button controls. Plus, it's just fun to use.

Aza Raskin has released a wonderful new toy, Algorithm Ink. As he states in his introduction, it really lowers the bar to exploring the creative mathematical beauty of fractals. Aside from the images themselves, there are two things I love about this site.

First, the less-is-more UI design really lets the canvas be the focus of attention by keeping tools out of your way until you need them. Second, and more fundamentally, is the “view source” ethos and the direct manipulation of the visualization-generating code that really makes the experience compelling (if not addictive).

Here’s what happens to me: select an interesting image and watch it play out. Click open the “edit” panel to expose the surprisingly few lines of code that make it tick. See all the pretty numbers. Change one. Click “draw” and see the effects of your change. Repeat about a thousand times.

Before I realize it, I’m copy-pasting functions from other drawings, following the logic in code to reverse-engineer how an effect is generated, musing on the power of weighting the randomness of my results. Like writing HTML on the Web 1.0, I’m learning by example and trial-and-error. Sure, there’s a manual for the syntax somewhere, but the experience of seeing and affecting the code in action is so much more fun.

We’re always on the lookout for engaging ways to communicate the patterns we uncover in our research. What factors cluster into significant groups? What are relevant attributes and relationships? What trends do we see?

Shan Carter and Amanda Cox at the New York Times recently produced a fantastic interactive chart highlighting the voting patterns along several demographic factors in the Democratic primaries. (You can read more about this graphic from Shan Carter here.)

I love the idea of starting with this approach and overlaying additional factors to draw out relationships and relative importance. In the Times example, imagine the squares drawn in relative proportion to the number of delegates in play; color and saturation representing the percentage of Democratic votes in the 2004 presidential election. Combining multiple factors does complicate the visual, so care must be taken to preserve the clarity that makes it so effective.

At Cooper, we often do something similar, with behavioral variables of interview subjects plotted along major axes, combined with demographics like age, organization type and role, to paint a picture of the interrelated web that helps us make meaning of a diverse human population. We always try to walk through these visualizations with a story that ascribes meaning to the observations, but providing clients (and ourselves) with an opportunity to interact with the data in a well-curated way really emphasizes the relevant factors and helps everyone understand the patterns we use to drive decisions and take action.