There was an almost interminable pause in the conversation, as Bill thought about what I had said. And then he looked up at me after some processing and exclaimed: “That’s just rude.”

~ ~ ~

In November of 2003 it was my job to get Bill Gates on board with the new designs my team had planned for the Windows user interface. I’d been in countless meetings with Bill, and already knew that I wasn’t great at convincing Bill of much. When it came to discussing the user interface of Windows we generally spoke past each other, which didn’t make sense to me then, but makes a lot of sense to me now.

The currency of the software industry, an industry that Bill Gates had a large hand in creating, is the engineer. Software gets built without executives, without marketers, without designers, and without accountants. It even gets built without testers. But it doesn’t ever get built without engineers. Bill is the ultimate engineer. Back in the 1980’s when graphical user interfaces were new and shiny, Bill internalized many of the lessons that made those original GUIs work. Concept reduction, consistency, skill portability, were all core to how to make a great UI. Why have 17 different ways to pop up (or drop down) a menu? Why have 17 different graphical treatments? With “one menu to rule them all,” users could learn how to use the menu once and then apply this knowledge anywhere they saw this affordance. That way, developers don’t have to reinvent the wheel, and users don’t need to relearn the wheel.

And this is still a sound fundamental principle of user interface design.

But engineers (like everyone) see the world through their lens. Engineers look at code all day. And when they see two pieces of code doing roughly the same thing, they immediately think about ways they could eliminate the wasted effort by combining them into one piece of code that performs both functions. And often, when coders participate in UI design, they make the same observations, and can overdo this principle.

Additionally, though it’s uncomfortable for the left-brained among us to discuss, another one of the fundamental aspects of today’s state-of-the art user experience design is to focus on how the software makes the user ‘feel’. You can imagine how popular a fuzzy notion like this is in a company (and industry) where empirically -minded engineers and their fans are running the show.

Just as I’d known it before all my previous meetings, I knew that Bill didn’t love my fuzzy notions about what makes for a great user experience. I’ll also confess at this point that I have a personal weakness when it comes to beautiful analogies. I overestimate their power to get people excited about ideas in which I’m invested. They’re certainly effective, but perhaps not to the degree that I imagine.

Back to my meeting in the board room with Bill Gates, and the 3 or 4 executives between he and myself in the Microsoft org chart. While the actual specifics of the day’s discussion are lost to history, I do remember clearly that we were debating the merits of my team’s user interface designs for powerful new data management features in the Windows Explorer. From my perspective, Bill’s preferred direction was overly abstract. We had created a compact set of tools to help users manage their files and folders where we felt we’d balanced the “learning curve” that comes with anything new with the way human beings actually think about things. Bill felt that we could reduce the concepts much further, thereby easing each user’s learning curve, and ultimately making them more powerful as they could employ this learning across a wide variety of scenarios. Cue my “beautiful” analogy.

At one particularly frustrating moment, I offered the following: “Bill, a shower, a toilet, and a water fountain all have mechanisms to control water flow, places where the water comes out, some sort of porcelain basin to hold the water, and a drain, but we don’t combine them into one thing to reduce their learning curve. We don’t merge them into one object because each of them are in use in fundamentally different ways at different times.”

Then the pause.

Then Bill’s verdict.

Ouch.

As I saw my career disintegrate before me, I started to question just how “beautiful” my analogy really was. To his credit, Bill was forgiving, and met with me many times after that, giving me numerous opportunities to get him on board with all manner of ideas coming from my team (with varying degrees of success on my part). Ultimately, I never did succeed in making Bill really comfortable with a more emotional approach to software design. But the real lesson of the day was learned. In the software industry, as long as the engineering-minded run the show, the notion of subtle and textured user experience design that balances the emotional and functional aspects of a software experience will always struggle to take root.