(This was originally published on Playwell, Alan's personal blog.)

Elisabeth Hendrickson has recently opened a new test-and-development training facility in Pleasanton CA called Agilistry. It’s bright and airy, well-lit and well-stocked, and it feels like home the minute you walk in. In order to publicize her new facility, she very generously hosted a week-long intensive learning exercise.

She invited eleven different people with widely varied skill sets, backgrounds, and interests. She challenged them to build a website in five days using the best practices of interaction design, agile programming, and test-driven-development. We christened it “AgileUpToHere” (#au2h) and it exceeded everyone’s expectations (you can see our results here).

Since it was my 15-year-old homophone web site that was being rebuilt, I nominally played the role of product owner, but I was an observer, an instigator, a goad, and a participant. It’s hard to remember when I had so much fun or learned so much. If you want to learn to be great, I strongly recommend Elisabeth and Agilistry.

Things I learned:

1. After 25 years, it’s time to lose the Windows computer and get a Mac.


2. Good agile developers are self confident; confident enough to trust interaction designers to do interaction design without distrustful oversight.


3. There are lots of programmers who understand that relational databases are not the only approach to solving problems.


4. It is time to build software.


5. Test-driven-development isn’t fully understood. In fact, software testing isn’t fully understood.


6. When even the leanest developer in the room sees really high quality BDUF (big design up front) for the first time, they get all woo-woo and want some for themselves.


7. Getting good software built demands the contributions of many different personalities, competencies, and roles, most of which are new and as-yet ill-defined.


8. Two programmers pairing can create more and better code in less time than one programmer can (I already knew this, but it’s always good to see it in action).


9. Even this jaded old fart can still get excited about changing the world.


10. There are many undiscovered and unfilled product niches on the Web, and one of them is “quality”.


11. People want a leader with a vision.


12. Elisabeth Hendrickson (@testobsessed) is a magical woman. To paraphrase Tom Robbins, “she’s been around the world eight times and met everybody twice.” Like a great chef or symphony conductor, Elisabeth knows how to combine the unexpected to create the sublime. She brought together a dozen people from all over the country, each with different skills, background, desires, and expectations, and then she blended them together into a cohesive, happy, effective team.


13. The pre-written code I arrived with was called “legacy” with a grimace, and was quarantined until discarded. Moral: Non-TDD (test-driven development) code is properly regarded like a ticking time bomb.


14. For interaction design, you can’t have too many white boards, made from porcelain-coated steel, firmly mounted to the wall. For agile development, that isn’t such a big deal.


15. Story-mapping is a major component of the bridge between interaction design and agile development.


16. Story-tracking software isn’t quite there yet.

Last night, our own Kim Goodwin presented her talk "Designing a Unified Experience" at the IxDA NYC, generously hosted by our friends at LiquidNet.

(Click the button on the bottom right of the "screen" for a fullscreen view.)

About the talk

Interaction design, visual design, and industrial design are distinct disciplines for good reason: Each excels in different ways. Interaction designers must be good at imagining structure and flow, which requires strong analytical skills and a high degree of rigor, especially for complex systems. Visual designers and industrial designers are masters of visual and physical usability but are also masters of emotion: They know how to evoke caution, attract attention, and instill desire for a product at first glance. Users have just one experience of a product, though. All three aspects of the design must work in concert, or the product will fail to satisfy. Integration of the three disciplines is a central theme of Kim’s new book, Designing for the Digital Age.

Behavioral economist, Dan Ariely’s delightful first book, Predictably Irrational, heaps yet one more shovel of dirt onto the fresh but deep grave of traditional, rationalist assumptions about human behavior. The book is a simple, personal, easy-to-read account of Ariely’s research conducted over the past 15 or so years. This research was conducted at his various host universities; all of them paragons of ivy-covered scientific rigor, including MIT, Stanford, The University of Virginia, and The University of California at Berkeley.

The clear and inevitable conclusion of his dozens of research papers summarized in this book is simple: humans don’t make rational decisions. What’s more, the irrationality of their choices isn’t random, but can be predicted and measured. While many of the experiments deal with choices regarding cash, several of them cleverly divorce themselves from money to clearly demonstrate that the goofy human behavior is human-related, not cash-related.

He identifies several predictable forces that act upon humans during decision making, causing them to make irrational choices. These include the distorting effect of similar, but slightly inferior, products offered for sale; the distorting effect of simply thinking about numbers; the distorting effect of items offered for free; the distorting effect of sexual arousal; social norms, ownership, procrastination, self-control, clinging to options, expectations, and being observed.

In his newsletter article last month, Ryan Olshavsky outlined an overall process for defining new products and services, taking a look at the start of that process. But how do you get from understanding your users to a vision for an innovative product which will appeal to them?

Developing a new product or service is tricky. When everything goes well, the product can redefine a market or even create an entirely new one, to the benefit of its manufacturer and its consumers. When the product doesn't click with its audience, though, the costs—development, employee, manufacturing—can be staggering. How do you ensure that your new product doesn't flop? One effective method is to conduct a requirements definition phase before developing a new product.

Requirements definition simply means "figuring out what to make before you make it." This process is not unique to software products. Architects, for instance, go through a requirements definition phase before they start construction on a home. They talk to the future home owner and determine how many floors and rooms will be in the house, where the bedroom should be, if there's a deck, and so on. Similarly, in the product development world, requirements definition enables you to make appropriate decisions about the functionality and design of a product before you invest time and money developing it. By bridging the gap between the needs of the market and those of your organization, requirements definition significantly reduces guesswork in technology product planning, and helps ensure that business and engineering are working on the same product.