A Quick History of Business Software: Why User Interface Design Is Important


In the early days of computing, businesses were running mainframes running software intended to speed up and cut costs on accounting work. One mainframe could do the job of 100 white-collar workers. This time, the late 50s and early 60s, saw some of the first instances of computers replacing jobs.

This all occurred in rooms very much like the following:


Environments like these set the precedent for building software, yet it's important to notice the distinct lack of screens. A lot of the techniques and conventions born of this screen-less environment are still with us today.

The typewriter you see is connected to the mainframe and can be used to deliver instructions to the machine. In this environment, the only concern of the software is data in and data out.

To get to this point a software team is given a business case, the case is modelled down to the core steps and procedures, a specification is produced and then programmers start writing the software against the specification. “Given Y, do X then output A”. They keep going, ticking off features from the specification. Once all the features in the specification have a tick, the software is considered complete and will be delivered to the customer.

70s and 80s: Enter the GUI and the PC

Throughout the 1970's Xerox was running a research programme to develop a graphical user interface known as Xerox Alto, a way to allow more nunanced interaction and visual feedback between computer and user. The Xerox Alto was the first computer to use the metaphor of the “desktop”, one of the first to make use of a mouse and the project is now often cited as being the forerunner of the modern GUI (Graphical User Interface) and heavily inspired Apple and Microsoft.

As we enter the 1980s, the decade of the Personal Computer, we start to see widespread use of screens. Gone are the typewriters from the staff desks and in comes small, general purpose computing machines. Running a handful of different programs at the whim of the user, spreadsheets and databases are now in the hands of the general user, not only the specialist.


This new paradigm ushered in a small explosion in operating systems and interfaces. Initially all fairly different, over the decade patterns emerged and common ways of doing things became normalised.

The rise of the PC and increase in computing power meant those research programs of the 70s were now being drawn upon to inform software design – and how we would interact with software – for the next 30 years.

Program windows, input boxes, toolbars, dropdown menus and buttons were shared across the different platforms. These patterns became ingrained into users' minds, they expected to see them and understood how they work.

This is pretty much where we stop. We now have our basic components that will dominate human computer interaction for the forseeable future, it's these components that are going to be used and abused.

90s: Begin the Abuse

It's 1995 and your business has grown, it's time to have some bespoke software written to manage your orders, invoices and customers. So you begin looking for IT specialists and you find Really Good IT Inc, they've been around 10 years and have a good track record, they've worked with some big companies, so you hire them to do the work.

They come in, map out everything you need your software to do. You feel good, they've listened to your needs and seem like they know what they're talking about. They go away for a few months and present you with something like this:


“Amazing!” you say, “it does everything we wanted it to!” and you now decide to deploy this across your business, you take a day out to train your staff and on Monday morning the new system is being used!

So what is the problem here? Really Good IT Inc fulfilled their contract and the customer is happy. Well, the problem is the customer had no expectations, they haven't really used software before, so just the fact the computer is doing the job is enough to excite and please them. The UI (User Interface) is an afterthought, it exposes the agreed functionality but that is all it does. What this highlights is that even though the way we interact with software has changed, the way it is designed hasn't. Sub optimal UI has an associated cognitive cost, as you need to scan over the whole to find the details, you have to slowly learn how to use it, there is no context or clues on how it should be used, it simply gives you all the options on the screen at once.

This demonstrates developers trying to be designers. It's software, it's on a computer, so logically you need a developer to make the UI don't you? “I just need to expose the functionality to the user” is a common misconception held with developers and leads to interfaces like Bulk Rename for Windows:


There is a lot more to designing software than simply exposing functionality and features, the biggest hurdle is making sure a user's mental model matches the actual program model, basically how a user expects a program to behave matches how the program actually behaves. The easiest way to do this is by sticking with known conventions, but that's not enough, sticking to known conventions has lead us to where we are now, so what else is there? It's all about guiding and setting those expectations from the get go, how you display a widget, how you breakdown a procedure and how you frame the context all sets expectations in users.

This understanding is now becoming normal in software. The web and mobile apps have reshaped our expectations of computing; it should be easy, it should make sense right away, I shouldn't need a 300 page manual or full day training course. The problem here is that business and enterprise software has a tendency to stick around, and the companies who develop them haven't necessarily caught up. Software is still in the realm of programmers and big lists of features.

So How Should We Approach User Interface Design?

Things are changing, businesses are expecting design to be as much a part of the software creation process as development is. Disciplines such as Human-Computer Interaction and User Experience Design have all matured and taken their seats at the table (HCI already being a decades old area of study). Designers who have never touched code now specialise in interface design.

Companies like Slack, Dropbox and MailChimp are developing software primarily used by businesses, yet they have put empathy and design thinking at the heart of their products, simply exposing functionality is not enough for them and it shouldn't be for you.


Exploring the slack management interface feels intuitive, I'm not afraid I'll break something, I don't need a manual to be able to make the changes I want to, no one needs to train me because the interface trains me.

The biggest difference between a well designed piece of software and a not so well designed piece of software is showing a person only what they need when they need it, less clutter on the screen means you are not overwhelming the user, they begin building the mental models as they discover the functionality, and they discover it when they need it.

When you let the user learn as they go you avoid overwhelming them, they discover the settings and features only when they need them, and they are more likely to make memorable connections and build a fuller understanding of the software they're using. This is a much more pleasant experience and the user associates simplicity and ease of use with your brand.