Last month at IxDA Interaction 11, we hosted an evening in our office in Boulder full of food, drink and discussion, to bring some of our learnings around Lean User Experience to the larger design community, and in particular to attendees of the annual international IxDA conference.

We had such a great time with it, and started so many great conversations, that we decided we had to do it again at SXSW. This Saturday, at Adaptive Path Austin, from 6-9pm, we're hosting deLUX REdux, and you're all invited. (Register at Eventbrite.)

Since we've been working with Eric Ries on his Lean Startup track this Saturday, we thought an event Saturday evening was a great way to share what we've learned with a wider community. And since we're on the topic, why don't you come see our own Parker Thompson on a panel with Eric at 9:30a, and join Janice Fraser from LUXr and myself on a panel at 12:30p with Dave McClure and Laura Klein.

So what is the event all about?

For the past year, we've been sharing ideas and discussing new ways to approach design and product development, to create better products, make happier customers, and reduce waste. We've been doing this while creating better integrated, more collaborative, more responsive teams. In that time, a number of us have been getting together on a regular basis to really sit down and discuss what works and what doesn't, and to try to distill these ideas into principles and techniques that are repeatable and practical.

We've been itching to engage with the larger design community to start to break down the culture of Big Upfront Design, the Cult of the Rockstar Designer, and the culture of necessary infallability; to fight the blind application of Waterfall and to disrupt the antipatterns we've found so antithetical to effective collaboration with agile development teams; to encourage patterns that allow designers to embrace early customer feedback, and to test hypotheses quickly; and most importantly, to foster a deeper collaboration with the very folks who have the biggest impact on what we build. We've seen over and over that, when done correctly, a light-weight process gives designers more control, not less.

It's out of this series of discussions that I first arrived at a framing of the problem space that I talk about in Enough Design, and it's also through these sessions that we've found a growing community of designers, product people, enterprises and other developers who are working to develop better techniques for integrated product development. We've found the conversation immensely valuable in our practice, and we hope to learn and share with more of you.

So if you're a designer in Austin for SXSW, or just someone who cares about usable techniques for bringing Lean principles into the development of compelling User Experience, come join us on Saturday for deLUX REdux. This is a free event, but space is limited, so please RSVP through Eventbrite.

Thanks so much to Adaptive Path for sharing their Austin office with us, and to everyone at LUXr, Hot Studio, Sidereel, Cooper, IDEO and the Balanaced Team for their help making this happen.

I believe it was in a conversation with Janice Fraser that I first started talking about DRY Documentation. It was certainly she (among others) who goaded me into actually writing this blog post. So I'm taking a moment on my WiFi-free (and generally amenity-free) United Airlines flight to SXSW to put pixel to screen.

DRYness is an age-old concept in the Agile space (to the extent that that's possible in a space that's only 10 years old itself) and it's elegant in its simplicity. DRY simply stands for Don't Repeat Yourself. The idea is that you should only do any one thing in code in only one place. If, for example, you are doing an interest rate calculation, don't copy and paste the code from one place where you need it to another: instead, move that responsibility to an object that reasonably should be responsible for such things, and do that interest rate calculation only in that one place. The reasons for this being important are manifold, but perhaps the canonical reason is so that it's easy to change: When the interest rate calculation changes, you don't have to go digging through your code to find all the places you do it, and make sure you change them all consistently. Instead, you change the code in only one place.

Hopefully this is old hat for most coders now, and hopefully you, gentle reader, will forgive me my oversimplifcations and conflations. The point is one of simplicity.

So now, let's shift focus to design documentation. The idea I'm trying to express when I talk about DRY documentation is one again of simplicity, though the drivers are perhaps a little different.

The mental model for truly DRY documentation is one in which every pixel on the page tells you something you didn't know before. Of course, like DRY code, it's worth being pragmatic. There are times when greater clarity can be gained by a certain amount of contextual restatement. But as a theoretical goal state, it's still quite useful to picture a body of documentation in which every last line tells you something you needed to know about what you're trying to build, and something you didn't know from looking at any other line in the documentation.

What would we notice about a set of documentation that adhered to these principles? Well, first, and most obviously, it would probably be a lot shorter than the documentation we're used to seeing. And that in itself is a benefit. Why? For a number of reasons. First, shorter documentation is in general easier to digest, and it's generally easier to find the relevant bit of documentation in a shorter corpus, all else being equal. (And of course, document structure and readability play just as big a role in a short document as they do in a longer one.)

Shorter documents are also easier to revise and maintain. And it's easier to find changes between versions, all else being equal. I talk sometimes about the 500 page PRD we got when we were developing one product, complete with two sets of revisions, also 500 pages each. Guess how easy it was for the developer to find the 2% of information that changed in each revision, and understand its implications to for the site? Guess how easy it was for the designer to be sure she'd changed everything consistently? In a DRY design doc, changes are more obvious, and more meaningful. Things jump out when they're inconsistent. And they tend to be more consistent, because the designs implied are applied more consistently across the product in question.

This brings me to another favorite topic: Principled design. DRY documentation is a lot easier to develop (and it's a lot easier to tell when your documentation is DRY) when your design is motivated by specific principles. For instance, when you decide, in the banking app you're designing, that all checking account features will use Cerulean Blue for their accent color, and all savings account features will use Prussian Blue, a lot of nice things happen. First, design questions become much easier to answer. The new Maximizer Account we've just added is a kind of savings account. Great! We know it's going to be Prussian Blue. (Or we can make a better informed decision that there should be a new point in the color family.) Second, it suddenly becomes a lot easier to document this fact. A one page style bible can capture this information, and when some new feature is implemented, it doesn't take any intervention from the VxD to make sure the new bits have the right color choices. Third, when some new feature comes along, developers roughing it out can come up with a reasonable early approximation of what it should look like, because they have principles to apply, instead of PSDs to pore over, looking for a non-existent visual treatment for the new thing they're just embarking on. This lets said VxD (and the IA) spend time tuning something that's close, rather than restating the design principles they've got in their heads, in the form of some new PSD file.

A fourth virtue is that suddenly all these color choices (or typography choices, or IxD choices,) have consistency, a consistency that our dear End User can actually pick up on. They don't end up feeling lost in a jumble of pretty colors, but start to associate the Prussian Blue with savings accounts, the Cerulean Blue with checking accounts, and, assuming the designer goes in this direction, that blue in general means cash accounts; green, stock and security accounts; reds and oranges, loans and credit accounts, or similar.

They may not be able to articulate why they know this, but they will perceive a solidity and purpose in the VxD, one that makes them feel safe and comfortable, and one that helps them use the application more effectively.

When coupled with a good domain model and a good information architecture, it suddenly gets a lot easier for the whole team to keep the design princples top of mind, and answer basic questions without having to consult a 500 page document, or even a 20-30 page set of wireframes and interaction designs. Hopefully they can answer most questions from a one or two page style bible, and by consulting the wireframe describing their grid system, and the one for the kind of module they're working on.

Again, the point is not to pursue this ideal to an absurdist end, but rather to continually ask oneself: Could this documentation be simpler? Did I cover this already? Could an existing design concept apply to the new area I'm covering? Restatement in the service of clarity is always to be lauded. Unfortunately, in practice, most restatement in the form of long design documents is just waste: Waste in that the documentation must be produced; that it must be maintained; that it must be read; that it must be understood; and waste in that it tends to obscure the princples of the design in favor of the surface of the design.

And of course, another agile principle comes into play: Refactoring. Often a second use of a given design treatment exposes new boundary cases and new pressures on the design, and the initial design needs to be modified slightly to accommodate both the new and the old use case. This is usually a simplfying force, and one not to be resisted. Let the documentation live, and reflect the deeper underlying principles of the design you're trying to express. Applied well, this rigor will help you to simplify and clarify your designs, and expose their essence.

When practiced well, DRY documentation will set you free, give you control and clarity, and communicate your design vision efficiently and clearly. It will also free your development team to do things more or less right the first time, and give them more time to work on the bits that need more love and attention.

An example of a one-page style bible, describing text treatments, spacing, backgrounds and grid structure in one digestible page.

This Friday at Pivotal Labs Boulder, we're hosting an evening of food, drink and discussion, to bring some of our learnings around Lean User Experience to the larger design community, and in particular to attendees of the annual international IxDA conference.

We, in this case, is a group of smart folks I've had the privilege to work with over the past year, a working group called the Balanced Team. This particular event is the result of the hard work of people at Cooper, Hot Studio, LUXr, SideReel and Atomic Object.

For the past year, we've been sharing ideas and discussing new ways to approach design and product development, to create better products, make happier customers, and reduce waste. We've been doing this while creating better integrated, more collaborative, more responsive teams. In that time, a number of us have been getting together on a regular basis to really sit down and discuss what works and what doesn't, and to try to distill these ideas into principles and techniques that are repeatable and practical.

We've been itching to engage with the larger design community to start to break down the culture of Big Upfront Design, the Cult of the Rockstar Designer, and the culture of necessary infallability; to fight the blind application of Waterfall and to disrupt the antipatterns we've found so antithetical to effective collaboration with agile development teams; to encourage patterns that allow designers to embrace early customer feedback, and to test hypotheses quickly; and most importantly, to foster a deeper collaboration with the very folks who have the biggest impact on what we build. We've seen over and over that, when done correctly, a light-weight process gives designers more control, not less.

It's out of this series of discussions that I first arrived at a framing of the problem space that I talk about in Enough Design, and it's also through these sessions that we've found a growing community of designers, product people, enterprises and other developers who are working to develop better techniques for integrated product development. We've found the conversation immensely valuable in our practice, and we hope to learn and share with more of you.

If you're a designer in Boulder for IxDA, or just someone who cares about usable techniques for bringing Lean principles into the development of compelling User Experience, come join us on Friday for deLUX. This is a free event, but space is limited, so please RSVP through http://pivotallabs.com/landing/deLUX.

We're pleased to be sponsoring the Open Source Women's Leadership Summit this Friday. We think the work that the RailsBridge community has done is critical to making the Ruby community more diverse and more welcoming to everyone. We know women are significantly under-repesented in the development community as a whole, and in the Ruby community specifically, and we choose not to accept this as inevitable. It was Grace Hopper, after all, who developed this whole idea of programming languages.

Pragmatically, we also see this as an opportunity. Women hold up half the sky, but until recently held down only 3% of the seats at conferences. In a market where everyone is searching for developers, we ignore this large segment of potential developers to our great detriment. Where else are we going to find the potential to double our Ruby community?

And, as our economy slogs its way out of the deepest downturn since the Great Depression, we also see this as an opportunity to even out what has been a very uneven recovery. We have at once deep unemployment and many many unfilled jobs. The jobs are there but they have moved. We are hiring as fast as we find good people and we are certainly not alone. We see RailsBridge as a way to help people develop the skills they need to move to these new jobs, and they're high-paying jobs, too! What better community to enter than one where employers fight to pay you above the median San Francisco income?

The work that RailsBridge started is very important, and is far from done. The work takes a great deal of effort. To that end, we want to celebrate the people who are making this happen. Pivotal Labs is honored to be a sponsor, and to continue to support these fantastic programs with space, time, money and our voice.

Those of you in the San Francisco area, we encourage you to attend and help us celebrate these inspiring leaders, and those of you elsewhere we encourage you to get involved: help get the word out about this exciting movement.

Event Details on EventBrite: OpenSource Women's Leadership Summit

RailsBridge Blog Post

We're honored and excited to announce that TechStars will be launching their inaugural class at our shiny new Union Square office this January.

We're big believers in getting the smartest people you can into the same room, and the TechStars mentors certainly qualify. They're a who's who of the New York tech scene and beyond, not just names but people with incredible insight, who will clearly have a lot to share with their startups.

We can't wait to see what develops in the new space, and think the cross-pollination of people and insights will be significant.

Applications to TechStars are still being accepted. Check out past results from TechStars companies - they're impressive! It's easy to apply: Just answer 15 short questions about your team and your business on the TechStars web site: http://www.techstars.org/apply

Applications for the New York program close on November 21, 2011, however, early applications are strongly encouraged and they receive get additional consideration. Applications received prior November 15, 2011 are eligible to attend TechStars for a Day to learn more about the program. However, this event often fills up quickly so it's best to apply as early as possible. You can update your application at any time, so don't wait until your application is perfect, ship it!

As already tweeted, we have a winner in the Pivotal Tracker GoGaRuCo Haiku contest. It was a tough choice, with lots of awesome submissions. The ultimate call went to Sarah Gray, with her entry below:

Bloom and iterate.
Each story a fragment of
the pivotal whole.

Below are the three runners-up:

Icebox, Backlog, Done
Righteous Fall stories sorted
Tracker guiding flow

Don Smith

Tracker has arrived,
transparency is blooming,
the team uniting.

Gustin Prudner

heisenberg was wrong
I know both where I am and
my velocity

Dav Yaginuma

The runners-up will be receiving a Pivotal Tracker mug. Thanks to everyone who participated!

Missed your chance to sign up for GoGaRuCo? They just sold the last ticket over the weekend. It's looking like an awesome line-up. But have no fear, you still have one chance to win a ticket!

It's the Pivotal Tracker GoGaRuCo Haiku Contest!

We're giving away one ticket to GoGaRuCo, the Golden Gate Ruby Conference happening here in San Francisco September 17th-18th.

Rules: Submit your Pivotal Tracker-related Haiku to tracker-haiku-contest@pivotallabs.com by one minute to Midnight Pacific Time, this Thursday night, September 9th. Multiple submissions are allowed, but of course only your best one's going to win, now isn't it.

We'll pick one winner, at our sole discretion, to be announced here. What are our criteria? I'll mostly be looking for awesomeness, but adherence to standard North American 5-7-5 form does count. (It would take a lot of awesomeness to overcome divergence from this style, and no submission without at least a little awesomeness is going to make it.) References to season a plus.

All submissions are licensed to Pivotal Labs to use however we see fit, and you retain the ability to use them as you see fit, under the Creative Commons commercial attribution share alike license. The winner will be granted one ticket to GoGaRuCo. Your travel is of course up to you.

Valid entries must include name, telephone, and email. Name will be used in attribution, but neither the telephone number or email will be made public.

So have at it! Give us your Tracker haikus. Don't know Tracker yet? Really? Check it out!

It's been great building the National Lab Day website, and it's also wonderful to have the site recognized on whitehouse.gov. This makes two sites we've worked on that have gotten attention in the Innovations Gallery, since Peer to Patent was similarly recognized.

The video from whitehouse.gov (below) does a better job explaining the project than I can:

And yes, the voice on the video clip is our own Mike Grafton.

pre|central.net has posted their picks for Best Apps of 2009, and they've picked both of the apps we developed internally as must-have apps in their categories, with Tweed at the top of the list in the Social Networking category, and Scoop being edged out by The New York Times in the News category. (We will concede that they have a little more experience in the News world than we do. ;-) The AP Mobile app also gets a shout out in the News Category, which some of you know is another app we developed, in this case on behalf of a client.

Thanks to the pre|central folks for picking our apps, and to all our users for installing those apps, and for all your feedback.

President Obama today announced the establishment of an annual National Lab Day, a nationwide initiative to foster scientific and mathematic experimentation and invention in young Americans through collaborations between volunteers, students and educators. He also announced the opening of the National Lab Day website, a site that we had the honor of building with Jack Hidary, chairman of the National Lab Day and the Jack D. Hidary Foundation. The site connects scientists and engineers with students and classrooms needing their mentorship, their enthusiasm for science, and their spark.

National Lab Day will take place every year in the first week of May.

We are pleased to be able to contribute to this effort, designed to foster the kind of inquiry that brought us all into the world of technology. We encourage scientists and technologists across the country to sign up to volunteer. In the words of President Obama, "I want us all to think about new and creative ways to engage young people in science and engineering, whether it's science festivals, robotics competitions, fairs that encourage young people to create and build and invent -- to be makers of things, not just consumers of things."

Recent coverage:

• Wired Magazine: Making Science Cool: Educate to Innovate
• The New York Times: White House Begins Campaign to Promote Science and Math Education
• The National Science Teachers' Association: President Obama Announces National Lab Day Initiative
• ReadWriteWeb: Obama, Kids, & All Tomorrow's Web Apps: President Focuses on Tech Education
• Or see all Google News coverage

We hope that this initiative plants the seeds of innovation in the next generation of young scientists and entrepreneurs.