On Friday, Dec 2, Janice spoke at the Warm Gun conference in San Francisco. The conference focuses on measurable design, and designing for happiness. This year the crowd ranged from designers, developers & entrepreneurs to startupy folks and seasoned practitioners.
Here’s the presentation from Janice, with (IMHO) the best title of the bunch. Enjoy!
Last week, Jason and I went to Tokyo to do a one-day workshop for 120 entrepreneurs, hosted by the Open Network Lab at Digital Garage. If you’re not familiar, DG was founded by well known angel investor Joi Ito. Today Digital Garage is the hub of startup action in Tokyo. The company provides venture investment, operational support for American imports like Twitter, and incubator services for seed-stage startups.
We were surprised to learn that Tokyo has a voracious appetite for Lean Startup and UX thinking. We initially set up the workshop for 80 people. When it sold out quickly, we upped the capacity to 100. When that sold out, we knew it was going to be a very interesting day!
In the end, we had about 120 people in the room for a hands-on Lean User Experience all-day workshop.
You’d expect, by reputation, that the Japanese startup community would be reticent—a little unwilling to dive into the radically collaborative, selectively uncontrolled Lean UX process that we advocate. Turns out, you’d be wrong.
Throughout the day, we used sketching, collaborative critique, dot voting, and assorted other techniques. Participants dove into the mock customer development interviews and translated their learnings into new product ideas. It was an active, engaged, crowd filled with people I’d love to work with. Having simultaneous translators helped (arigato gosaimas!).
Most impressive was the gratitude that participants expressed for our visit to Tokyo. We’ll be going back and heading on to other countries. In the next several months, LUXr coaches will be visiting Jakarta, Singapore, Chile, Mexico…keep an eye out for announcements.
If you’re anywhere in the world and want to bring a LUXr workshop, please drop us a note.
I’ve been working closely with Pivotal Labs over the past month. Each week I get together with designers and management to map out how design works in this cathedral of XP-flavored agile.
It was during one of these days that I had an epiphany. I felt like I had discovered the Rosetta Stone…a mars/venus split between design an development. Here it is:
To developers, “iteration” means incremental release of working code.
To designers, “iteration” means a chance to do something again.
Iterative Design
Designers have been talking about the practice of iterative design literally for decades. This practice calls for designers to test designs and to immediately change and refine them, and then launch again.
In his notoriously declarative style, Jakob Nielsen wrote in his 1993 paper Iterative Design,
Even the best usability experts cannot design perfect user interfaces in a single attempt…[making] at least three versions of the interface is recommended.
For Jakob and generations of design professionals, an iteration is a do-over (and over and over). It’s a presumed part of the process.
Iterative Development
To agile developers, though, the word iteration means “increment,” as in ‘a small chunk of working code that can be released in a brief period of time’. Iterative, in this context, means that the software grows piece by piece.
Agile developers do believe in going back and doing things again — “make it green then make it clean” is a motto at Pivotal, and refactoring the software is a routine practice. But it applies only to the code; not the interface or interaction.
Overlooking the Obvious
Consider the implications of this misunderstanding: Betty the designer approaches agile with an open mind. She finds comfort in the “iterative” approach of agile — iterating (revising) her work has been core to her practice for years, and she’s excited to work with developers who share this belief. Betty comfortably accepts limitations on her design process because she thinks that she will get a chance to revise, to do it again, and better this time.
But the design do-over doesn’t ever get added to the the iteration plan — there are always new features to launch, bugs to fix, refactoring to finish. Eventually, Mary falls back into waterfall methods, because it feels like agile doesn’t really work.
How have we misunderstood each other for so long?
It seems obvious in light of this realization that design needs the equivalent of refactoring, and it needs to happen routinely. “Make it green then make it clean” applies to everyone.
Given this realization, it should be a relatively simple thing to devise a solution — perhaps new story types? Design refactoring? More design input to the iteration plan? At some point, we will figure this out, but until then, understanding will go a long way.