The Real UX Problem
In my first story, I introduced you to a gap I see between what we, as software development professionals, build and what our end users actually need. We’re going to explore this in a bit more depth here.
I hinted at but was not particularly detailed about the core problem, that of a consistent UX across all the things that a user does with a computer. Remember, and this is key, that the user has to use more than one tool, in general, to get their job done. This leads to some interesting problems.
First, very often the user is so busy trying to get their actual day-to-day job done that, paradoxically, they have no time to learn these cool tools we developers create for them. They get stuck in a catch-22, leading to frustration and an even lower desire to learn new tools. It doesn’t help that, because of how software is developed, there is never 100% alignment between what the development team has created and what the user would actually find useful. I have seen many, many times where training for software includes working around the places where the software doesn’t support the company’s desired processes in some way. Is it any wonder that those in charge of actually getting things done end up shoehorning processes, data management, and the like into things like documents and spreadsheets? They are certainly not well suited for most of what people actually do with them but they do provide a UX that most of us know and are even fairly comfortable using. It’s important for us to realize that this is so crucial to those decision makers that they don’t care they are usually sacrificing security and the ability to audit the system (!!) in favor of using software that requires little to no training. They have learned the hard way that the best software is completely useless if the user base cannot or will not use it.
Another problem is one I covered in my last story. Since each individual tool is typically built in isolation, users end up with a very choppy experience as they need to switch between them. At first glance, you might expect this to be a nearly impossible problem to solve, especially since tools can come from different vendors (at that point, we’re dealing with different ideas about how things should look, how they should behave and even what’s important for the user to see). I would suggest, however, that we’ve gotten this right about 1 1/2 times in the whole history of computing (not a great average but at least we know the problem can be addressed!).
Let’s take the example of office suites; this is not one of those 1 1/2 times but still bears discussion. Office suites have typically been less of a UX problem for people because they bundle the must common applications computer workers need (mail, documents, spreadsheets, etc.). More importantly, the companies that produce them generally place a strong enough emphasis on consistency across the individual pieces that the cognitive load is minimal; they only differ in behavior where it makes sense based on what the tool does. They also tend to support good integration. For example, it’s easy to include a functioning spreadsheet as an “object” in a document, giving you live data to play with. There is enough similarity in what those tools do, though, that they really cannot be considered part of the 1 1/2 times “success story.”
The “half” success that I see is the operating system itself, specifically the windowing (GUI) system. It’s a success in that the mental model of a window and how you interact with it and what you can do with it is the same, regardless of the application you’re using. It’s consistent across the entirety of the user’s interaction with the machine. That sounds pretty basic, and it is, but that simple idea has done a great deal to make us more productive on our computers. Where it’s not a success is once you get into each application. They are all different. Each has (probably) a different set of authors. The closest it can come to interoperability among applications is the clipboard (but that’s pretty poor) or the file system (and that’s even worse).
The one true success I think we’ve managed, and this may make you laugh given the above, is the command line terminal. You heard me right. The world of *Nix systems is built on the idea of from hundreds to thousands of little programs that focus on one key ability each but with an understanding that they are part of a greater whole. With a few key concepts and this ability built in to most every program, I can chain together any number of them and end up with an amazing, flexible and functional data processing pipeline. But then, who really wants to only use a command line?
With this one solid success (and our half a success) in mind, is there any hope that we can provide better experiences to our users? Are there any lessons we can learn from the humble command line or the less-humble GUI? The good news is that I believe there is. In the next story, I’ll talk more about what I think we can take away from those successes and ways we can apply them to the things we build.
