Is Simplicity Always the Goal?

I get asked often why we named our company Simple Thread. I usually joke and say “the domain name was available.” But then I say the name brings together two of the core beliefs we have about building software.

1. Simplicity over flexibility – We believe in choosing simplicity whenever possible. If you have a choice between configuration and a sensible default, go with a default. This is one of our core software values.
2. Great software is all about people – Thread symbolizes bringing together people to create exceptional digital products.

Once or twice I’ve had people dig a bit deeper and ask me what I mean by “choosing simplicity”. It turns out, simplicity is a complex topic to discuss. So I usually tell people that complexity in software is a scourge, and we fight it at every turn.

Everybody struggles with complex software. So this is usually a satisfactory enough answer that we move on to other topics. Simplicity, in the abstract, is something that everyone can get behind. If you gave someone two choices, would you prefer something simple or something complex? Virtually everyone would say they would prefer something simple. But why?

Let’s back up a bit and define what we mean by simple. The Oxford dictionary has a few definitions of simple, but let’s focus on the most popular one:

Easily understood or done; presenting no difficulty.

Based on this definition, it is pretty clear why people say they want something simple. Why expend effort when you don’t have to? Why would you want something difficult to accomplish when you can get away with easy?

When it comes to software applications, everyone wants interfaces that are easy to understand. The three most common complaints I hear from users of software are:

1. It is slow.
2. It is unreliable.
3. It is difficult to understand.

Seems pretty clear that everyone wants simple interfaces then, right? It seems so obvious that it feels like a truism, but have you ever asked someone how to make an interface more simple? It usually involves the system developing some form of ESP.

Let’s consider the cockpit of a commercial airliner:

To most of us, this is not “easily understood”. It takes quite a bit of training to become proficient in using an instrument panel like this. Why is the cockpit created in this way? Is there a design that could make this “easier to understand”? Absolutely. You could do things like:

1. Highlight critical information
2. Clearly label information displays
3. Provide descriptions
4. Hide rarely used controls
5. Remove controls that the on-board computer can manage

With many modern aircraft, they can virtually fly themselves in ideal conditions. So wouldn’t it be easier to remove all of the controls and just have a big “go” button?

Sometimes Simple Isn’t The Answer

If it was as simple as just adding a big “go” button in the cockpit, then why wouldn’t it already be that way? Well, what would we do if something went wrong? Would the computer read your mind at that point? I guess we are back at designing for ESP. In times like these, I’m reminded of Chesterton’s Fence. The principle is very relevant here, we shouldn’t attempt to change something until we understand why it was like that in the first place.

Let’s consider who has to use this interface. Airline pilots are highly trained, and they interact with a cockpit like this daily. How would making the cockpit “simpler” affect their experience? Making the interface “simpler” would require a lot of tradeoffs:

1. Speed – If you hide a bunch of controls, accessing them would take time. Something that might not be worth it in a critical situation.
2. Visibility – An expert user is going to want to have visibility into a lot of information about the aircraft at a glance. They don’t want to dig for hidden controls or have the aircraft hide information.
3. Reliability – A switch or dial is a very simple control interface. Having a lot of them might require training in their use, but makes for a very reliable system. The pilot can easily tell at a glance if a knob is turned or a switch is flipped.
4. Information density – If lots of labels or descriptions are used, it can eat up a lot of space that could be used for displaying information to the pilot.
5. Control – Planes have a lot of redundant systems. You could have a single switch for a set of redundant fuel pumps, but an expert pilot is going to want a switch for every individual pump in the plane. This could probably be handled by a computer, but this level of control serves as a failsafe in an aircraft.

Are these trade-offs worthwhile to an expert pilot? Almost certainly not. Are there improvements that could be made? Probably, but it is hard to argue with the overall safety record of the aviation industry.

Experts have very different needs from novice users. When optimizing an interface for an expert making it “easily understood” by a novice usually isn’t on that list. So does this mean that expert users want complex interfaces? No, of course not, but it does mean that sometimes an interface needs to be complex for an expert to accomplish their goals.

The expert spends a lot of time becoming proficient in a tool or interface, which over time makes that interface more and more intuitive to them. After enough time the interface is “easy to understand” and “presents no difficulty.” To the expert:

1. Controls have meaningful labels
2. Controls are grouped in meaningful ways
3. Controls are placed in reasonable locations
4. Information displays are easily read at a glance

But to the novice, it is a bewildering array of knobs, dials, and switches.

Simplicity is Relative

Simplicity and complexity are always relative to the individual and the situation. When considering the relative complexity of an application for a particular user, it might be helpful to ask yourself a few questions:

• How often will this person be using this system? Will they be in the system every day, or will they use it once a year?
• Is the person familiar with the problem domain? Are they familiar with the concepts and terminology being used?
• What is the individual’s mental model of the system? How will that clash with how it will actually function?
• Has this person had any training with the system? Will they receive training?

You have to remember that just because someone is an expert in a particular piece of a system, doesn’t mean they understand the system as a whole. When a pilot becomes an expert at flying a plane, does that mean they also understand the inner workings of the planes engines? No, of course not, that would be a silly assertion. For the pilot, simplicity is limited to the parts of the system to which they are intimately familiar and we have to understand that in order to design a system that meets their needs.

When you set out to design a piece of software, you should always strive for the utmost simplicity, but universal simplicity is not possible. Ever. However, simplicity relative to the needs and skills of the user is possible, and should always be a guiding principle in the design of any software product or application.