Note: I started this post back in October, but never got it posted. Dave Brubeck turned 87 on December 6, 2007.

I had the good fortune to see the Dave Brubeck Quartet in concert last month. For those of you who may not know, Dave Brubeck is one of the legends of Jazz. He is a classically trained pianist, who has been delighting audiences with his jazz renditions (usually with his quartet) for more than 60 years. Yes, that makes him quite old. Eighty-six years old, to be precise. But, he still has “it.”

“It” in this case refers to the ability to captivate an audience, to deliver an amazing concert experience.

Certainly, the quartet contributed to the whole experience, but the key focus was Dave Brubeck and the piano. He didn’t need to jump around, or bob his head, or wear flashy clothes to keep the attention of the audience. He simply played the piano with amazing finesse and style, and talked genuinely with the audience between sets. No big light show, no theatrics, just amazing music from an amazing artist. That was the experience we came for, that was the experience we got. And we weren’t disappointed.

A lot of things can contribute to an experience. If no one thing really stands out, and drives the experience, sometimes other things can be added, or enhanced to make the experience more powerful. But, when the experience people want comes through simply, powerfully, “adding” other things to the experience ends up detracting and taking away from the experience.

Dave Brubeck is the real deal, a genuine artist with true star power. Seeing him in concert, in all his simplicity, was a fabulous experience. Anything else would have been a cheap substitute.

Good design requires understanding. And true understanding (of customer/user and business needs, constraints, opportunities, etc.) doesn’t just happen. It requires probing, studying, and questioning.

So, when one stops asking questions, for whatever reason, good design becomes much more difficult. Through the years I have repeatedly seen one key reason that people stop asking questions: Smart Guy Syndrome (or SGS). (Not to be sexist, but my experience is that men have a much bigger problem with SGS than women — although it does afflict women on occasion.)

It usually happens like this. A guy is given a job/ project/ team/ whatever to run — because he is a “smart guy.” Now, he needs to support the premise that he is indeed a smart guy. He is a smart guy because he has the answers. Asking questions would just undermine his position as a smart guy, therefore he quits asking questions. It doesn’t happen all at once, but gradually the questions and the probing lessen, and more and more trust is placed in what is already “known.” After all, he is a smart guy. As this happens, the design becomes more ego-centric, and based less on true needs and opportunities.

If you stop and think for a minute (and you are honest with yourself), I’m sure you can recall several cases of SGS. You may have even been afflicted at one time yourself (most of us have). The challenge for each of us is to stay alert, to recognize the early signs of SGS, and take preventive measures (seek true understanding through probing, studying, and questioning). Avoiding SGS is one of the best ways to improve designs. Trust me, I know…

Last month I was at MIT for the Campus Preview Weekend for next year’s freshmen. It was a fun weekend packed with seminars, tours, classes, presentations and parties. Of course the focus was on my daughter, not me. But, there still were plenty of things for the parents to do. At a reception for the parents Phillip Clay, the chancellor of MIT, spoke of the many projects undertaken by MIT and MIT students that are making a difference for the poor and less fortunate around the world. It was an interesting, and impressive, presentation. Truly the skills, talents, and intellect of these exceptional people is making a difference.

At another presentation, Susan Hockfield, the president of MIT, also spoke of MIT initiatives that are targeted at helping in third-world countries. She described these efforts as “helping those who can’t help themselves.” I was both encouraged and frightened by her comments. I was encouraged for the obvious reasons — that those who have been given much would go out of their way to help those less fortunate. I was frightened because of the potential dangers of “helping” too much. Not social engineering, exactly, but assuming we know what is best for others when we see only our perspective, and don’t understand theirs.

What does this have to do with design? All too often we rush in to design and/or build some great new thing that the users will love. After all, we have skills and talents, and we can help them. Except, skill, talent, and desire to help aren’t enough if we don’t really understand what the real users want or need.

Before you “rush in” on your next design or project stop and consider — honestly — who your audience really is. What drives them? What are their goals and objectives? What are their fears and frustrations? Now, design to satisfy their needs, goals and desires, not just what you assume would work for them. The best way to help is to first truly understand the need, and design to that need, and not just impose our ideas on others. As Uncle Ben said to Peter Parker, “with great power comes great responsibility.” [More to come on this subject.]

While testing the beta of the new Interaction Design Association web site (ixda.org) I came across an entry that I had posted in a thread about the commercialization of art/design back in December 2005. A slightly modified version follows.

Design is not a random, spontaneous act. It has purpose — a goal that is trying to be achieved. Good design achieves the intended goal or purpose (or, at least gets close). If I design a chair that is visually appealing, but terribly uncomfortable, my design has not succeeded (as a chair, although, it may succeed as sculpture, or art.)

It is true that some designs may be overly constrained due to business issues. But, this is nothing new. Many great artists through the years were constrained by the desires, or willingness to pay, of their benefactors. What they painted, composed, sculpted, etc. was greatly influenced by their employer. That doesn’t mean their work wasn’t worthwhile, or successful. The reality is that most designs have constraints of time and money. Tradeoffs must be made. Good designs focus on achieving the objectives of the sponsor, and of the user even if some *art* gets sacrificed in the process.

I don’t see this as pandering to profits. It is not a bad thing to be avoided, rather it is what makes design design. Does that mean that a comfortable chair cannot be visually appealing? Absolutely not! If the visual aesthetics add to the overall experience, they add to the success of the design.

Great designs go beyond the business (sponsor) needs. Really great designs have as one of their key objectives to meet the needs/wants of their users (in an elegant way). Great designs provide great user experiences, not just a creative outlet for the designer. And, bad designs (that don’t consider the user experience), generally are limited in their benefit to the business paying for the design. The process is self regulating. Bad designs have limited commercial success. Good/Great designs often have the best commercial success. (Think of iPod, IKEA, Google, or your favorite products/services/software.)

A few years back I worked on a project to build a web-based application to replace a very unwieldy Oracle Forms application that tracked the purchase and sale of all properties owned by a large international organization.

While the developers were digging into the guts of the old system I started talking to the users and watching them do their work. It started with how they used the system, but quickly got to why they did what they did. I soon learned a key reason that the system was so unwieldy — it had been ported over from a mainframe application with little change in the procedures or process flows. Many of the menus and forms were basically the same as they were on a green-screen system!

The fact that the current system had basically just been ported over from the prior system without adding any usability enhancements really wasn’t that surprising. The fact that the new agile team was ready to do the same thing was amazing to me! As I talked to the main users of the system I quickly discovered that most of their time was spent monitoring and updating things that the new system could easily do automatically. But, if freed from those tasks by the new system, there were a number of places in the process where their expertise could be put to much better use.

In addition, the various divisions had developed systems in Access to take care of the many things that the main system could not do for them. The decision was made (without talking to the users in the various divisions) to get rid of all the Access systems because new system would be so much better and it was too messy (for IT) to deal with all those Access databases. My discussions, however, revealed that the people in the various divisions did the majority of their critical work in the Access databases, and that, as envisioned, the new system would not provide the functionality found in their Access systems.

The program manager and the dev team would have none of that. Java was so much better than Oracle Forms, that the system would obviously be easier to use and more functional. And I was in trouble for bothering all those people instead of cranking out wireframes. (The program manager wanted wireframes within two weeks of starting the project — even though the developers spent more time than that getting their arms around the technical specifications.)

We had the opportunity to develop a system that would greatly increase productivity and improve working conditions, while reducing the costs of managing properties world-wide. The developers, however, just wanted to complete user stories as quickly as possible.

As it turns out, the project was scrubbed. The managing director had received so many complaints about another system that was just being rolled out, that he wanted all the development resources committed to getting that system right before any new development was undertaken.

I wasn’t involved with any of the other projects in that organization. I can only hope that the second time around they listened to the users about what their objectives really were instead of just asking what steps they take in their current systems so they could be translated from one technology to another. Our goal should be to help people and organizations better achieve their goals, not just to replace F6 with a mouse click, or client server with web 2.0.

Wow! Apple’s announcement of the iPhone sure has generated a lot of buzz. In just a few days I’ve probably seen well over 100 articles, blogs, or posts about the iPhone. What is it about the iPhone that is garnering so much attention? There really isn’t anything new here. I’ve seen it all before, including the multi-touch interface. And not very many people seemed to care when these various element were introduced before.

Is just Steve Jobs? Or the Apple mystique? I think those certainly are considerations, but the real power behind the iPhone (or the iPod, MacBook, or anything else Apple does) is something that I’ll call iDesign.

Apple doesn’t generate so much excitement at it’s product launches, or win so many loyal customers by doing something completely new. (The iPod certainly wasn’t the first MP3 player.) Apple wins by taking existing concepts and doing them better. Although there are lots of MP3 players, there aren’t any that make the whole music experience as smooth, or satisfying as the iPod. There are lots of smart phones, but none as smart — in ways that matter to people — as the iPhone.

Apple seems to understand that the context of product usage can be as important as the content. It isn’t just about playing music on a portable device with decent quality sound. It is about the whole music experience. How easy is it to add new music to my collection, make up playlists, listen at home or at work, etc. Apple is very good at “cool.” But cool isn’t enough. Apple is able to consistently bring cool to the pent up desires and frustrations left behind by existing products. This creative problem solving, or iDesign, is what gives Apple an edge.

Right after the keynote, many of the comments about the iPhone centered around the cool factor and its features. But as discussions progressed, comments began to reveal long held frustrations, and the hope or expectation that the iPhone would help relieve those frustrations.

I admit this is no scientific study, but the number and intensity of the posts over this past week have been undeniable. And the common thread in those ongoing posts has been the expectation that the iPhone would make their mobile phone experience much better, in substantial ways that would improve their lives.

That is the magic of Steve Jobs and Apple. That is the power of iDesign.

That simple question — what’s the motivation? — is one of the most useful things I learned in college. I was taking a TV directing class and we were learning about using camera moves wisely. The simple, but powerful lesson is this: when contemplating a camera move (or some other effect), stop and ask yourself why you are doing it. What do you hope to gain by doing it? Will it really further your objectives, or will it detract? If you don’t have a valid reason for moving the camera, perhaps you shouldn’t do the move. That isn’t to say that camera moves (or widgets, or interactions) are bad. It just means that we should know why we’re using them before we do.

The application of this little gem obviously goes way beyond camera moves. It applies to web widgets (Ajax, 2.0, or otherwise), industrial design, interaction “enhancements,” and design elements of any flavor. Does the widget, component, text, interface, etc. further the objectives of the site or product? Does it help the users? Or, is it just cool, cutting edge, easy to implement, or a personal favorite? (This applies to clients too. When we get requests for things that just don’t seem to make sense, we should seek the motivation behind the request. If there isn’t any, other than XYZ Corporation did it, or “because,” we should push back and introduce other options.)

Next time you are tempted to throw in a widget, or some other element into your design, pause for a moment and ask yourself “what’s the motivation?” If you are satisfied with the answer, you are likely on the path to a good design. If not, stop and reconsider before making any rash decisions.

I’m old enough to remember the first laser printers (and the Apple ImageWriter). Before laser printers typists and computer users didn’t have to worry about what font to use. They generally only had one option (usually Courier). With the advent of laser printers they were free to choose from a number of fonts, and font sizes! The result was often ugly.

Emboldened with this new typographical freedom, one-page newsletters would often have 12 fonts - with italics, bold and underlined text. Some were so bad you could hardly read the messages. Why did people create these abominations? Because they could. Fortunately with time, common sense returned (a bit) and real design took over, and many wonderful, but simple, newsletters were created.

Then came the World Wide Web. The first web pages had plain text on a silver background, with perhaps a few low-resolution, 64 color images. They were very simple, yet succeeded in conveying the intended message. But as connection speeds increased (56K modems instead of 14.4K modems), and HTML “advanced,” those simple pages gave way to multiple fonts, background images, and blinking text. Again, with time, design sense prevailed (on many sites), and the background images and blinking text became a thing of the past.

Now we are in the midst of Web 2.0. While many remember the lessons learned in prior implementations, too many have gone crazy with the seemingly endless possibilities. Web services and applications are being mashed up left and right, creating frankenstein monster web applications that have no reason to exist, other than the creators found out that they could.

Real design is about accomplishing a purpose, solving a problem, or enhancing an experience. Design is not about seeing how many cool widgets, APIs, or RIAs can be forced on a user. Fortunately, we have many new and exciting tools that we can use to create better, more enabling designs. Many web applications are very exciting, and empowering. But, these new tools and technologies should be used wisely. Good design is purposeful and enlightening, not overpowering. Remember, just because you can, doesn’t mean you should.

I love being part of the new field of experience design (and related fields like interaction design and information architecture). Like many others, I find it exciting and fulfilling. But why do we do it, really? Why is this new field becoming so popular? It isn’t for the short working hours. It isn’t for the technology (although the technology is exciting). It isn’t for the money. It isn’t to make cool designs. We do it for the people — the customers, the users.

The whole effort is about helping people. Real people with real wants and needs. A professional accessing her investment or banking accounts online, or a parent checking a child’s grades on a school site, a gen x’er searching for a new song by his favorite band, a weary traveler trying to get to her flight, or a customer service rep taking someone’s order. Regardless of the application, web site, process, or system involved, the users (or customers) are real people trying to accomplish some goal.

Our job, our opportunity, as experience/interaction designers is to help them accomplish their goals in a satisfying manner.

Of course, we have to also represent business concerns. Usually, however, there is a strong advocate representing the business objectives. We, on the other hand, are often the only advocate for the user. We must ensure that their interests are represented, and balanced with the business objectives. If we don’t, not only will the users be underserved (or alienated), but the business goals will be compromised as well (it is hard to sell product when your customers are alienated).

Yesterday I came across an online video of a talk Bill Buxton gave last year for the Alberta Ingenuity Fund/ Alberta Ingenuity Centre, entitled What if Leopold Didn’t Have a Piano? Wow! I’ve listened to it several times now, and I’m still gleaning pithy insights. (I’ll follow up with more insights from Bill Buxton in future posts.)

The title refers to Leopold Mozart. Buxton follows up by (jokingly) asking if Wolfgang Amadeus might have ended up being the best butcher in Salsburg. He then goes on to posit that the piano was important, but not sufficient, to create the genius that was Wolfgang Amadeus Mozart. Neither was his father being a music teacher, or the music hall in Salzburg, or the many other things that contributed to shaping the young Mozart. Each of them alone was not sufficient. But, together they provided the environment, or ecology, in which the genius of Mozart could develop. They did not guarantee it, but did allow it.

Go to Bill Buxton’s site and scroll down to the Online Talks section. His link will take you to the page on the Alberta Ingenuity Fund site where you can get the video stream. While you are at Buxton’s site check out a few of the other links. This little, unassuming, one page site is a gold mine. I’m sure there was much rejoicing in Redmond last year when Buxton agreed to be Principal Researcher for Microsoft.

One of the many insights I like from the What if Leopold Didn’t Have a Piano? talk deals with the importance of getting the right context. Buxton said that we focus too much on problem solving, and not enough on problem setting. We always want to get the design right — even without knowing if we’ve got the right design. Read that again if you have to. The distinction is very important. I’ve seen all too many projects that had slick interfaces, or beautiful designs, fail because they didn’t address the right problem. Their design was very nice, but it was the wrong design.

Before getting too excited with your next great design, step back for a minute and take in the ecology of the design. Who will use it, and why? How does it fit with other tools or information sources?  Sure, it is a great design, but is it the right one?