Cooper Menu

A blog about design, business, and the world we live in.

Integrating solve and do

Comments (1)

The industrial age divided our world into white-collar and blue-collar workers. Those with white collars went to college, worked in an office, solved problems, and made decisions. Those with blue collars went to high school or trade school, worked in a factory, performed work, and followed orders. “Solve” was separated from “do”.

But in our contemporary world of knowledge workers, very little of it can be teased into separate “solve versus do”. Today, doing is an integral part of solving, and solving is an integral part of doing. We are all “no-collar” workers: smart, well-educated, solving problems, and performing work.

The successes by state-of-the-art practitioners in both agile development methods and UX have given rise to a desire for more effective collaboration. Once a programmer has seen what well-applied agile methods can accomplish, she soon begins to yearn for a better user-facing strategy. Likewise, once a designer has seen what good interaction design methods can accomplish, he soon desires to work with a strong development team open to collaboration.

Many advanced thinkers have already tried a first order solution: agile programmers have requested input from designers, and UX designers have attempted to squeeze their work into the timeboxed cycles of agilistas. The results have been promising, tantalizing, but somehow not quite there yet. It has become clear that while both UX and agile are effective methods, a combined “agile-UX” method will be something different from—something beyond—a simple addition of the two.

This past weekend, in a creatively messy office space in Tribeca, two dozen such advanced thinkers got together for the third installment of a working group dedicated to addressing this worthy challenge.

The group, which calls itself the “Agile UX Retreat”, consists of about 50 people, who borrow time away from work to participate. The group actively seeks and invites promising newcomers, but there is a core of twenty or so who attend every meeting.

At last week’s third meeting, the group shifted into a higher gear and made remarkable progress. They weren’t so much “post-agile” or “post-UX”, as they were “post-doctrine” and “post-hostility”. The thinking, speaking, and exchange of ideas, vision, and practice was not only of a remarkable quality, but it consistently transcended its component pieces. Beyond talk of design or agile, beyond talk of design and agile, the talk was of what the organization can be—and must be—when everyone in it is committed to the principles of user-centered, collaborative, iterative teamwork.

Much of the gruntwork of figuring out how this new organization works is being done by the “lean startup” folks, spearheaded by the likes of Eric Ries and Steve Blank. Lean startup has really only been practiced in tiny little startup companies, where, when you talk to the “product owner”, you really are talking to the product owner. While this is only a microcosm of the larger corporate reality, it is a valuable test-tube in which experiments can be conducted. In other words, we can learn a hell of a lot about how to run a big company by seeing how this stuff works in little companies.

But the core ideas of lean startup aren’t so much new as they are simply the beliefs of agile and UX, brought together effectively in a business context. Half of the lean startup’s principles are bedrock to agilists, while the other half are foundational to user experience professionals.

Not just the designers and not just the programmers, but everyone has to center their work on satisfying the customers. You need to have sublime confidence that the only way to deliver a successful product or service is by first delivering some version that is wrong, or at least, not quite right. That is, success on the first try is not within the capabilities of humans. Iteration and incrementing are integral parts of a post-industrial approach to product development.

At the union of “solve” and “do” we find the definition of the twenty-first-century business. Even though we are still at the beginning of this journey, it’s clear that we are finally on the right track.

Related reading

  • Agile UX? Lean UX? Customer Development? A multiple discovery moment by Josh Seiden
  • Changing the meaning of normal - Agile UX Retreat #1 by Johanna Kollman
  • Thoughts on the February 2010 SF Agile UX Retreat by Jeremy Johnson
  • Thoughts on the July 2010 Grand Rapids Agile UX Retreat by Carl Erickson
  • A funny thing happened at the intersection of Agile and UX by Craig Villamor
  • Why I spent my weekend talking Agile and User Experience, by Jeff Gothelf
  • 7 Principles of Startup Happiness by Marcy Swenson
  • My early thinking about agile development & UX
  • My link round-up from an the first agile UX retreat

1 Comment

All very tantalizing -- but some examples of the discussion would be greatly appreciated!

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment



Sign up to get our featured articles delivered straight to your inbox every month or two.


Follow us

  • Facebook
  • Vimeo
  • Twitter
  • Google+
  • LinkedIn

Cooper topics

  • Tools of the trade
  • Design the Future
  • Designing Culture
  • Design Research
  • Service Design
  • Pair Design

Featured articles

How to Design & Lead a Brand Experience Workshop in 6 Steps


Pair Design and the Power of Thought Partnership


Cooper Authors

  • Alan Cooper
  • Cale LeRoy
  • Chris Noessel
  • Christina Beard
  • Dan Winterberg
  • Doug LeMoine
  • Elisha Cook
  • Emily Schwartzman
  • Greg Schuler
  • Izac Ross
  • Jason Csizmadi
  • Jayson McCauliff
  • Jenea Hayes
  • Jim Dibble
  • Julie Celia
  • Kendra Shimmell
  • Lauren Chapman Ruiz
  • Nikki Knox
  • Shahrzad Samadzadeh
  • Steve Calde
  • Suzy Thompson
  • Teresa Brazen is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.