I recently attended a workshop where user-experience experts (those responsible for the outside of the software) met with software architects (the über-developers who design the product's insides) to talk about how these two disciplines could work better together.

The evening's guest speaker at the workshop was a resort hotel architect. He was chosen to speak because his line of work depends greatly on the hotel visitors' expectations, which are always above average. Especially interesting was the large number of concerns he must balance.

The building architect is responsible for designing the inside and the outside of the structure. If the hotel comes in on budget to build but doesn't achieve revenue requirements, his design is a failure. If the hotel comes in on budget and isn't aesthetically pleasing, it won't meet its revenue requirements either. If it costs too much for the hotel to be operated, his design is a failure.

To be successful, the architect works collaboratively with the company paying for the hotel, the hotel builders, and the hotel operators. He leverages lots of research about hotel customers and what they like. He draws on the experience of specialists, such as engineers, construction experts, operational experts, interior decorators, and landscape designers. But ultimately the architect is responsible for the success of the building.

Balancing all these concerns, the architect successfully designs resorts all over the world. Because he's responsible for the success of the building, he doesn't throw his designs "over the wall," but stays with them throughout construction and into operation.

The architect's story left us wondering why we in software so often try to divvy up those responsibilities to separate people—people who in many cases don't collaborate. The outside of software is usually designed by people different from those designing the inside, and costs and timelines often are someone else's responsibility altogether. Far too often, software designers have no clear understanding of how the software will earn its revenue. As often as we draw parallels between software design and building design and construction, we should pay closer attention to the way architects design buildings holistically.

What do I mean by holistically? Think of the last time you purchased a commercial software product. You got a box with cool graphics and text explaining the product's features and benefits. The package likely held a manual, a warranty card, a bit of advertising, a quick reference on loading the software, and a CD containing the software. When you put that CD in your system, perhaps you saw an installation utility. If it didn't ask too many difficult questions, you got the software installed. You may have been asked to register the software and directed to a registration Web site. Eventually you got the software running, but if you were new to this product you'd need a little help finding your way around the features. Maybe you'd read the manual or help files. Maybe you'd just feel your way around, checking menus and tooltips to see what you can do with the software. Eventually you'd start to use the stuff.There's more to a product than just the core software and features, and all those other parts are often the first things you see and judge about a product. They make up your initial experience with the product, and the quality of that experience will affect your opinion of the software.

Given that there's so much to a product, who on your product team do you see as responsible for designing, building, and testing the product? For any given product you work on, ask the following questions:

1. What are the components of your customer's and user's experience with your product? Your list should include everything the customer and users see and touch
2. Who is responsible for designing, constructing, and validating each component?
3. How do all those responsible collaborate with each other to ensure a high-quality product?
4. How is the entire product tested? How do you determine the success of the finished product, and how do you determine where it can improve?

As software development matures, often the thing separating high-quality software from lesser counterparts is the user experience. While I think it's a good idea, I'm not ready to insist that software should go the way of building architects—training people who can effectively design the inside and outside of the product—we should consider the whole product when we design, build, and validate. And, from a process perspective, if we can't get all those brains into one body, I hope we can get them to collaborate as closely as possible. The success of the whole product depends upon their combined success.