If you’re going to be an advocate of creating singular user experiences, it is important to have your bearings — know what came before you.

Before the first Macintosh arrived in 1984, graphical user interfaces were in their fetal form. Text interfaces were the norm. And consistency was nowhere to be found. Arcane commands and procedures ruled the day. And we liked it that way. It made us feel special that we knew how to view the file directory, and other people didn’t.

Then the Macintosh arrived. A common language with which to interact with the core functions of software was its gift to our industry. Pointing, clicking. Windows, menus. Selecting and operating on selections. Icons. Folders. The metaphorical language as well as the guidelines telling you when to use what verb, which noun, set the stage for Windows, and the next 10-15 years of software user interface development. The changes were so transformational that their benefit was undeniable. Only the crustiest of technologists lamented the loss of their clubbiness and branded these new GUIs as for simpletons only.

The icons got more colorful. The windows got bevelier (yes, we know that’s not a real word). And the menus got overcrowded. But ultimately not much changed, until the web.

The web introduced new tools in our user interface arsenal — most importantly the hyperlink, the back button, and the ability to update your software instantaneously for all your users (whether they like it or not). The first two were important extensions of the core language introduced to the masses back in 1984 by the Mac. The third enlightened us that it didn’t take 6-12-18 months to improve a user interface. It could be done instantaneously — for everyone. But beyond these three the web gave us an additional gift — it smashed our assumptions about how consistent our user interfaces really needed to be.

Up until well-designed web pages started showing up in the wild, the keepers of the User Interface fires would rely primarily on consistency and rules to maintain quality. But the web was out of control. Anyone could make a web page, and did. And while lots of web pages were ugly, or hard to navigate, some where beautiful, and compelling, and strangely, the human beings that used them were able to learn how to traverse these pages all by themselves. They didn’t need to be retrained. They didn’t need complex manuals. The web delivered user interfaces where the number of elements that needed to be consistent were much smaller than we’d been taught was necessary. And it didn’t seem to be a problem. The previous overly expansive focus on consistency now seemed foolish. (Hobgoblins, small minds, etc.)

This was more painful than you might think. Because the old guard was made up primarily of technologists. Technologists didn’t just love consistency for consistency’s sake, they loved it as it mirrored their understanding of the technology they were building from a code perspective. Engineers look to reduce the amount of code in their programs. They try to reuse pieces of code over and over in similar situations in their apps. Similarly, engineers try to reduce the number of concepts in an app. The remaining concepts form a framework that they teach to the user. The thinking goes, once the user knows the framework, they can accomplish anything in the user interface. This isn’t wrong so much as it is overdone in software. Humans don’t always perceive very similar tasks as similar at all. Sometimes they need things to feel different even when an engineer’s logic would dictate a more efficient path.

But even scarier, it wasn’t engineers that were creating all those inconsistent web pages, it was designers. And the engineers didn’t do themselves any favors. Designers were learning HTML and CSS and able to generate web pages without the help of an engineer. This was the beginning of the end.

The end result of the design vs. engineering conflict over user experience was never in doubt. The technologists with perspective switched sides and realized the benefits of the new approach. They would become amateur designers on their own, or professional ones in some cases. They would co-opt designers to join their teams (even if only temporarily). And ultimately, the combination of designers and technologists who saw the future started defining success as more than consistency but as usability. The seeds were planted in the early 90’s but the web really accelerated the ability of people to start designing software around humans, and the way they actually used the software, vs. the code and the functionality it expressed. Usability was core. Human-centered design was here to stay.

These new goals around discoverability, time to task, task completion, and general usability gave us engineering-like metrics we could use to start to measure our software experiences. This was sound thinking, and a great way to get the stragglers on board with the “new way”. We could measure user response to our software in scientific (or what seemed like scientific) ways. We could tell you which user interface was better. Definitively. And this was good. Measuring how users interacted with our software was and is a good thing. And yet, something was missing.

In the mid-2000’s two things happened. The first modern web browsers arrived with client-software-like user interface rendering capabilities. And, high-powered mobile devices (smartphones and tablets started to arrive) with powerful user interface rendering capabilities as well. All of a sudden the main places users would be experiencing our technology had very powerful capabilities when it came to delivering dynamic and engaging user interfaces. The designers had even more tools at their disposal. But the complexity of these new platforms meant that the engineers had to be more involved.

But something else mattered also — brand.

The notion that software not only could be, but definitively was an expression of the brand, the identity, the raison d’etre of a business, was something new. It had been staring us in the face for years. For years people’s opinions of Microsoft were formed by the multiple hours a day they sat in front of Windows (and much less so by the minutes per year they sat in front of Microsoft’s advertising). This was true for every technology company. The hands on user experience was core to the brand impression the company made. But this was almost invisible to many of the companies who created that technology. Apple had understood it for years, but (as usual) they were among the exceptions.

But just as big brands had heavily designed websites, they charged into apps with the same zeal for making a brand impression. When it was mostly websites that were getting this treatment, the notion that software was a brand expression could be dismissed. After all, “those websites are just ads. They’re not really software. They don’t do anything.” And while there are many apps that really don’t do much, brands started creating apps that did things. Now it wasn’t just the design that reinforced the brand, but the functionality itself that said something to the user about the company supplying the app. Companies were realizing that they could connect with their customers by providing software as a service that actually did something. And that getting users to use your app actually mattered. Not only was the fear of inconsistency a thing of the past, now it was imperative that your app actually stood out. It was imperative in a sense that your app be INconsistent.

Now that having software be desirable and creating an emotional connection with users were goals, how do you achieve those goals? Even if you built an app that was intuitive, appropriately consistent, measured high in usability tests, it might still leave users cold.

So here we sit, in this brave new world, where we must adhere to the lessons we learned in the 1980’s about appropriate consistency, the lessons we learned in the 90’s about updating our software regularly and not over-doing consistency, not to mention some ways to measure our effectiveness. And we must not forget those lessons all while we’re absorbing the teachings of thew new Millenium around how emotion, and perception, the way customers feel about our software, will ultimately dictate how successfully our technology performs in the real world.

It’s a lot to juggle, and yet, it’s the state of our art.