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

The biggest problem in software today is that programmers and designers simply don’t work well together. They certainly want to, but each craft sees the problem from their own point of view and, with the best intentions, each tries imposing their methods on the other group. But even agile developer’s sharpest tools aren’t going to work well for designers, and likewise, even the designer’s sharpest tools aren’t going to help programmers.

The solution will be to find some common ground where each craft is open to the best contributions of the other, without either side being forced to sacrifice their inherent strengths.

I believe that the solution, like most big things, will be relatively simple in concept, yet getting there from here won’t be easy.

Today, most of the pathologies of both designers and programmers can be traced to their mutual lack of experience working together. Most programmers will tell you their biggest problem is coping with rapidly changing requirements. Most designers will tell you their biggest problem is unresponsive programmers.

In the modern, agile world, programmers defend themselves against changing requirements by showing customers the program as often as possible, and by being able to make rapid changes to suit the customers expressed needs.

Interaction designers defend themselves against uncooperative programmers by doing ever more detailed design and documenting it with greater accuracy, detail, and precision.

But modern, agile programmers can work so flexibly that they don’t need all of that detailed and precisely written design. If designers could just blend into the development team, they could communicate their design directly without the overhead of documentation. They could provide a kind of just-in-time design service to the programmers.

On the other hand, interaction designers can master the driving principles of even the most complex domain so that programmers don’t need to make all of those changes. With a comparatively brief and inexpensive field study, designers can vanquish the changing requirements problem almost completely.

Ironically, the common ground for agile developers and interaction designers is one where the major problem faced by each craft separately is largely solved by the simple presence of the other craft, working collaboratively at a peer level.

That’s really good news for cost-conscious business people (now that’s redundant). Having designers and developers collaborate is very economical. Most of the cost of interaction design is incurred in the documentation and communication of that design. Similarly, most of the cost of software development is incurred in traversing blind alleys trying to elicit useful guidance from the stakeholders. Effective collaboration simultaneously discards the need for the two most expensive parts of product development, while driving quality—and user desirability—through the roof.

Dave Hussman, one of the leaders of the post-agile movement, recently hosted a one-day conference on the topic of “Redesigning Agility”, and invited me to give a plenary talk. The focus of the conference and my talk were how to integrate agile development with interaction design. I was very pleased with how things went.

Here you will find the complete text of my talk, entitled “An Insurgency of Quality”, along with all of the slides I showed. I made a few ad libs, but mostly stayed with the script in order to assure that my message not be misunderstood.

The conference, called “Code Freeze” (due to it being January in Dave’s home town of Minneapolis), was sold out and the audience was razor sharp. The attendees were developers; that is, mostly programmers, but with lots of designers, coaches, testers, and managers, and not a few who wore several of those hats.

This talk is a complement to one with the same title I delivered at the IxDA's Interaction08. That one was directed at designers; this one is for developers.

As you may know, Alan Cooper, our fearless leader and co-founder, is the creator of Visual Basic (or at least the visual part-- Bill Gates is the one who decided to marry it to Basic). MSDN has recently put together an interesting series of interviews around the history of Visual Studio, including this one with Alan.

Regardless of the countless poorly designed applications that have been brought into the world by Visual Basic, it's hard not to see the monumental impact Visual Studio has had on the way software is created. Hear from the godfather himself about the making-of and implications of his game-changing work.

If you're having issues (or have issues) with Silverlight, you can find other formats of the video here on the MSDN site.

Why are after-market casings so popular with consumers especially for portable devices? Are they just about protecting the product? Are existing product designs too boring? Have consumers lost confidence in the quality of product manufacturing? Or, do they just want to customize their devices to be unique and special, as we have seen in Asia's extensive customization culture?

Leather, custom decals and heavy-duty rubber covers.

The iPhone is beautifully designed, engineered, and manufactured. Apple has used high-quality materials to avoid scratches and heavier damage that come along with daily use. There are no painted parts, which would easily scratch to reveal the substrate. The early complaint about the physical construction was that its sleek finish made the phone too slippery. The absence of grip details on the surface, and the aluminum casing of the first generation, made the problem worse. Apart from this flaw, the physical form of the iPhone is well-designed, and I think it has great potential to display the aged patina that comes from long life and high-quality materials. Which makes me wonder: Why cover it up with a cheap plastic cover?

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.

During the Agile 2008 conference, Amr Elssamadisy interviewed Alan Cooper on the topic "Similarities Between Interaction Designers and Agile Programmers." During their conversation, Alan provides additional context for his talk, "The Wisdom of Experience" and explains why he believes the adoption of Agile methods by developers is a positive development for interaction designers.

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?

Tim sparked an interesting discussion around the office last week when he circulated a post from Derek Powazek's blog called "Programmers are tiny gods." It offers a provocative analogy for the designer/programmer relationship:

Programmers are the Gods of their tiny worlds. They create something out of nothing. In their command-line universe, they say when it’s sunny and when it rains. And the tiny universe complies ... So if you’re working with a programmer, you have to treat him or her like a God. You have to pray. You cannot issue edicts. You have to come on bended knee. “Here’s the problem I have. I need a solution. Please help.”

It's from a series called “Things I learned the Hard Way.”

Tim McCoy: It's a nice insight into the psyche of many development organizations. This is meshing with a sentiment I’ve heard a lot lately: “Don’t tell me what to build. Tell me what you need built.” It’s a subtle distinction that replaces the feeling of micromanagement with one of empowerment.

David Fore: Right. But this sentiment begs a fundamental question. When a programmer objects to being told what to build, how can biz decision makers ensure they aren't wandering into the weeds, building a taco stand rather than a playground, let's say. In other words, taken to the extreme, this sentiment means the inmates shall run the asylum. Alan, do you want to rewrite your book?

Tim McCoy: For me, it doesn’t challenge the notion that design has the responsibility of describing the product and development the responsibility of creating it.

I recently had a conversation with a developer who said “I want the definition of behavior as soon as possible, and I want to delay the definition of implementation for as long as possible.”

The issue is that being told what to build is a command, not a dialogue. Being told instead what needs building is an invitation to collaborate. That acknowledges programmers as professionals with expertise designers don’t generally have. (In turn, it assumes programmers acknowledge designers as professionals with expertise they don’t generally have.)

Programmers then have the flexibility to assess what building that thing would entail, express concerns over feasibility, timeline, motive, etc., and offer alternatives or adjustments that impact their ability to be successful.

So it’s about removing the friction to object to in the first place. Derek is being sensational with the bended knee bit, but the sentiment is sound. The payoff of his post is this:

The good news is, programmers want their work to be used, and the good ones know that the design matters. So programmers and designers actually have the same goal: getting the stuff used. If each can honor the talents of the other, great things can happen.

It’s about approaching developers as co-conspirators in producing great work: designers know what needs to happen and developers know how it can.

Lane Halley: I think you’re right on when you say “being told what needs building is an invitation to collaborate” and that designers and developers can be “co-conspirators in producing great work.” However, there are some nuances to the situation.

I think that when SW developers are removed from business decisions about what they are building (e.g. work for a salary, or code for hire), there’s a sense of relief when someone, anyone, steps up and takes ownership for the “what” of the product. However, at many companies, this responsibility for the “what” isn’t totally owned by Designers, it’s a space shared with Business Analysts, Product Managers and other folks.

I’ve also seen small teams of collaborative generalists at Web 2.0 companies and startups who have a different attitude. Those folks don’t think of “design” as a separate role, it’s more like an activity, or a skill set that has to exist within the team, somewhere. SW developers who work in this environment feel a greater sense of ownership of the product, and expect to be involved in defining the “what” too.

Tim McCoy: That’s a great point. The dynamic in a small team, startup, or indie development shop is usually much different from the situation Derek describes. I think it’s a side effect of the traditionally down-stream role developers have in larger established organizations that leads to this outlook, and why it’s design’s responsibility to say “hey, I’m not coming down here to drop a spec on your desk, I want to talk about how we can solve this thing.”

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?

Several months back, the New Yorker ran a fascinating article about elevators that explored multiple issues--engineering, architecture, ethnography, economics--and shed light onto the "why" of the elevator design problem we featured in a recent episode of The Drawing Board.

In elevatoring, as in life, the essential variables are time and space. A well-elevatored building gets you up and down quickly, without giving up too much square footage to elevator banks. Especially with super-tall towers, the amount of core space that one must devote to elevators, in order to convey so many people so high, can make a building architecturally or economically infeasible.

As designers we can be dismissive about the why behind the problems we encounter; it's often enough for us that an interaction feels patently hostile. At best we file it under "implementation model" and move on; at worst we assume those design decisions don't have any rationale behind them and neglect to consider it further.

It's easy to become jaded after seeing so many examples of poorly-made software, and while it's possible to come up with a decent solution without digging any deeper, it's critical we understand the why if we really want to marshal the potential of technology to serve human needs. Also, besides informing our work, exploring the whys often reveals fascinating stories that give us insight into the underlying processes, and help us sympathize with the people that created them.

Bob Martin’s rousing keynote speech at the Agile08 conference in Toronto entitled “Quintessence” proposed a small but significant addition to the Agile Manifesto, a seminal document in the programming world. Uncle Bob, as he is affectionately called, proposed adding the assertion that we value “Craftsmanship over crap” to the manifesto. The idea is excellent, and the wording bold, but it isn’t quite a complete sentiment, and Uncle Bob addressed this issue in his blog.

Shortly after delivering his speech, Uncle Bob stated in his blog,

The problem with my proposal is that it is not a balanced value statement. In the other four statements we value the second item. We just value the first item more. But in my proposed addition, we simply don’t value crap at all.

He goes on to propose rewording it as “Craftsmanship over Execution,” but admits that it still doesn’t capture his meaning precisely. He then asks the blogosphere for help. My response follows.

I was asked by the leadership of the Agile 2008 Conference to give the closing keynote address at their annual conference in Toronto. The audience at Agile08 consisted of about 1500 programmers, engineers, product managers, and others involved in the creation and deployment of software primarily using Agile methods.

My belief in the value of detailed written design has often led enthusiasts of Agile to assume that I am an adherent of the obsolete, and justly maligned, waterfall method of software construction. I was pleased to have this opportunity to state my position with clarity and precision, not to mention making the case for effective collaboration between interaction designers and Agile programmers.

Here are the slides and accompanying speaker's notes for my talk. Some in the audience noticed that I was reading from my notes during the presentation. If you're interested in why I chose to do this, read this Journal entry.

If you would like to discuss this presentation with me, either post a comment to the Cooper Journal blog or email me directly at alan@cooper.com.

We recently spent 14 months designing an investment platform for traders and portfolio managers. As you might imagine, this was a large and complex application that required a tremendous amount of collaboration with the client. Our team consisted of a design communicator, an interaction designer, two visual designers and an engagement lead. We spent many hours with subject matter experts (SMEs), business analysts (BAs) and developers, crafting a solution that satisfied the needs and goals of seven user personas (and because their real-world counterparts were also employees of our client, actual users reviewed our work every step of the way). This article describes some of the key techniques we employed to ensure that the interaction design was something our client's development team could implement (I'll focus on our collaboration about interaction design; visual design was a key component of this highly visual interface, and deserves its own article).

The industrial age is over. Manufacturing, the primary economic driver of the past 175 years, no longer dominates. While manufacturing is bigger than ever, it has lost its leadership to digital technology, and software now dominates our economy. We have moved from atoms to bits. We are now in the postindustrial age.

More and more products have software in them. My stove has a microchip in it to manage the lights, fan, and oven temperature. When the deliveryman has me sign for a package, it's on a computer, not a pad of paper. When I shop for a car, I am really shopping for a navigation system.

More and more businesses are utterly dependent on software, and not just the obvious ones like Amazon.com and Microsoft. Thousands of companies of all sizes that provide products and services across the spectrum of commerce use software in every facet of their operations, management, planning, and sales. The back-office systems that run big companies are all software systems. Hiring and human resource management, investment and arbitrage, purchasing and supply chain management, point-of-sale, operations, and decision support are all pure software systems these days. And the Web dominates all sales and marketing. Live humans are no longer the front line of businesses. Software plays that role instead. Vendors, customers, colleagues, and employees all communicate with companies via software or software-mediated paths.

If you work for a large company, or have one as a client, you've probably heard about Six Sigma. Many companies report great success using Six Sigma initiatives to improve the quality of their products and services, measured by increased customer satisfaction and millions of dollars saved.

At the core, Six Sigma and Goal-Directed design share some of the same values and provide tools to solve some of the same problems. Six Sigma seeks to understand and quantify the functions that matter most to users and provide improvements in those most leveraged areas. Goal-Directed design seeks to delight users and increase loyalty by creating products that are powerful and pleasurable to use. Six Sigma identifies and tracks faults "critical to quality" (CTQs). Goal-Directed design uses personas and goals to define and communicate interaction design decisions.

One lesson we've learned over the past several years here at Cooper is that on the vast majority of our projects, intimate client collaboration is a critical ingredient for success. This is a lesson that we have sometimes learned the hard way; collaboration can be messy, unpredictable and has often forced us to compromise what we thought was a supremely clear and elegant vision. Despite these growing pains, we've learned to embrace the unpredictability and compromise; through well-managed client collaboration, our designs are stronger and are more likely to serve our clients' needs and satisfy the goals of end users.

Everyone's talking about outsourcing and offshore development these days. It's been on the cover of major newsweeklies, featured prominently on the West Wing television show, and a topic of conversation around boardrooms and discussion groups. Regardless of your personal position on trade policy, globalization looks like it's going to be a fact of life in the software industry.

As an Interaction Designer, I'm not responsible for actually building the products I design. However, I find it increasingly clear that outsourcing creates a significant impact on the entire software design and construction process. Offshore development is in its infancy, but will continue to evolve to become an increasingly effective way to go about certain kinds of software construction. Based on recent project work, this article describes a number of observations worth considering as you ponder how outsourcing and offshore development may fit into your plans.

In most of the organizations we encounter during our consulting work, programmers tend to think they’re the best-qualified people to design the form and behavior of a product. In the absence of trained interaction designers, they may be right. They know from experience that no one else is going to think through all the implications of serving up that snippet of data in just the right way, and no one else questions the idea of programmers doing the interaction design because they assume it’s a technology problem. As a result, executives who lead technology initiatives believe that they already get interaction design for free from their programmers. In their opinion, having interaction designers is unnecessary; if the product happens to be hard to use, they assume the programmers just need some sensitivity training. Having programmers design the product is anything but free, though; it’s ineffective, inefficient, and risky.

Interaction design methodologies, like Goal-Directed Design, tackle the software development process from the top down by defining specific product requirements and interface behavior based on research and user needs. The Rational Unified Process (RUP) and other programming methodologies attack software development from the bottom up. RUP creates fluid efficiencies for iterating product development during the construction phase in order to react to changing product requirements while still producing shipping code.

Although different, the two approaches are both successful ways to manage software product development. Do development organizations need to choose one methodology over the other? Or are the two development strategies complementary?

In my article last month, Innovate, one step at a time, I discussed how the process of innovation easily derails during difficult economic times, such as today's. When creating software and digital products, innovation typically spans many months, and it can become disrupted by unobservable or frequently changing business conditions that make it extremely difficult to form and evaluate viable options. When people can't see where they're going, they typically just stop. This is tragic with respect to innovation, since it is innovation that propels business and society forward.

A few years ago I conducted a workshop on ethnographic mapping methods with a Pueblo community in the Southwest. While I wasn't familiar with Pueblo cultures, I had heard they were rigorously private. For example, I was asked not to discuss the specific details of the Pueblo's history or personal stories—normally a key topic in the workshop.

Despite these precautions, I was surprised when the group seemed unimpressed by the exercises in the workshop. They were often hesitant to participate, especially in the exercises that focused on developing skills for mapping personal stories, historical accounts, and cultural data. I was told, instead, that they were not prepared to talk about these things in the presence of outsiders—meaning myself and some other attendees from a nearby Pueblo. Instead, they asked for handouts.

Which is harder to change: a program with 1000 lines of code or a 1000 square foot slab of concrete? The concrete is ten inches thick and has steel reinforcing rods criss-crossing within it. Every cubic foot of it weighs almost 100 pounds. The software has almost no physical existence at all. It weighs nothing. It consumes no space. A few microamps and those bits flip from zero to one without a second glance. The answer to my question seems a simple one, doesn't it?

Which is the best medium for designing software: Visual Basic or a sharp pencil and a couple of sheets of paper? Visual Basic is a powerful, flexible integrated development environment. It is on its way to becoming the most widely used language ever. It has won every industry award there is. Paper is not interactive. Paper offers no palette of pre-made controls. It just lays there and you have to do all of the work. The answer to my question seems a simple one, doesn't it?