I recently saw a post called “the best interface is no interface”. I started thinking about that title. There is no where that you can actually have no interface. If there is no interface there is no interaction.
So what is an interface then? My first thoughts when back to my programming background. What is an interface in programming? In it’s most basic form it is a group of related methods (designers, don’t turn off your brain, or go somewhere else just yet. This will make sense to you, in fact this article is for you). Basically you are creating a contract to use. A simple interface example:
1 2 3 4 5 6 | interface biker { void bike(bike fuji); void cadence(int speed); void gear(long ratio); void break(long friction) } |
The thing to notice here is there isn’t actually any code here. It is just setting up a contract that has to be followed to create a biker. It needs a bike, a cadence, a gear, and the ability to break. Basically it is defining what needs to be done.
Contracts in design
I really liked that idea of a contract when it comes to defining an interface. What is my definition of an interface. Well … here goes. “An interface is an interaction point between two systems regulated by a contractual agreement.” There. That is an interface. So let’s walk through this and why this even matters.
Why a contract?
Isn’t a contract an agreement by two people that they sign? Yes it is. So we change people for systems and a signature for an agreement and there you have it. An agreement by two systems that spell out how they are going to interact. For example. I create a contract with an employer. I agree that I will work and they agree to pay under specified terms. Both parties need to agree to fulfill the terms of the contract.
Let’s move that to an interface, a simple one, a doorknob.
What is the contract here? The hand agrees that it will turn the doorknob a specified amount and the doorknob agrees that it will unlatch. A simple contract. That is why I really like this approach it simplifies. It also tells us what exactly we need to comunicate to the user through the design. I’ll touch on this later.
The Doorknob
Let’s go back to the door knob. Let’s apply this definition of interface.
Two systems:
- The hand
- The knob
the contracts:
- the hand:
- turns
- past a certain point.
- the knob:
- unlatches
With that defined we can now address the design. I have everything that needs to be fulfilled. I can look at the terms and create a design that communicates the contract. And here we go. The design:
We can then take the design and discuss if it meets the contracts. And this design does, and has for a very very long time, since about 1878 (first patent). This design, however, introduced a new contract point. Now the hand needs to squeeze. so now the contract is this.
Two systems:
- The hand
- The knob
the contracts:
- the hand:
- Squeezes – added by design not original contract
- turns
- past a certain point.
- the knob:
- unlatches
Now remember this change was not the original required contract. This is a contract item added because of the limitation of the design. This becomes important as we go further into this scenario.
Failure to meet terms of contract
So along came the car, and with it grease monkeys. Which I happen to be one. One thing that I hated was trying to open a door with greasy fingers for two reasons, First, I didn’t want to get the door knob dirty, the second, I couldn’t get a grip on the knob to open it.
So we have identified one situation where the contract fails. Greasy hands. It fails for two reasons. I can’t grip because of the viscosity of the substance on my hand, or I don’t want to touch it with my hand, thus not getting a grip on it. This is an easy way to determine contract points too, find the failures.
Also, in the not to distant past, there was a movement of thinking that the voice for the disabled population should be more important. In our case the voice of those who cannot meet the contract.
This is where this method of design really shines, identifying the point where the contract cannot be met. If you can say that the requirement is to turn the handle so far we can start asking the question who cannot fulfill this contract. What then happens is that the contract separates from the design.
Once we have identified the failing we have two options. The first is the most common, but unfortunately the least effective.
The first option – add an interface.
This option is used over and over. I’ll describe it in terms of the door knob then show, generically, a process in the real world.
So someone sees that amputees cannot open the door. They say, ok, well, let’s add another system that needs to interact here.
So now we do this:
Three systems:
- The hand (or gripper)
- The knob
- The stub
the contracts:
- the stub:
- put force in linear direction or allow for squeezing motion
- the hand (gripper):
- Squeezes – added by design not original contract
- turns
- past a certain point.
- the knob:
- unlatches
Now the contract has been augmented. We have another system, that needs to meet the requirements on another system. So here are the interfaces. The stubb needs to contact a plastic or other type of piece in a solid way to support the force placed on the end of the piece. The end of the piece needs to squeeze the door knob to allow for a rotational or lateral movement, then we enter the original contract, then the piece will turn the knob a certain amount which then the knob will unlatch.
A quick drawing of such solutions.

This adds a lot of complexity and is usually not the best solution. We need things to be simple. Here is a scenario of a process I have been thinking about recently.
A user collects data from a group. That data reflects experiences the group has had. This process started many years before the computer. It was paper and remains paper to this day. As part of the instructions it asks the user to print out data from our systems and mail it to us. There was a software piece built to enable the transfere of the paper information to a digital system in a little easier fashion. So data gets printed, mailed, then reentered into the same system is was pulled from. At times there are over 70 lbs of paper being shipped from all over the world at a huge cost.
So we added an interface and a lot of complexity. The process included paper, to facilitate the contract it needed to be mailed. The functionality was added that the data was in a central area, but the contract wasn’t changed. The process was changed to meet the initial contract. So they added an interface instead of removing a contract point. Mailed instead of queried.
So back to the doorknob.
We introduced a contract point because of a design limitation. Everyone was ok with that because, back in 1878 people weren’t thinking about the disabled, maybe because a much larger percentage of people with amputations and disabilities didn’t live long. Maybe because people just didn’t think about it much. But either way when the need arose we changed the interface not the contract. So we come to our second possability of solution.
Second option – readdress the contract.
So we do this:
Two systems:
- The hand
- The knob
the contracts:
- the hand:
- Squeezes – added by design not original contract
- turns
- past a certain point.
- the knob:
- unlatches
Whether that was introduced by a design or a designed feature in the beginning doesn’t matter, either way we can remove the contract point and readdress the design. This would stop the cycle of appending interfaces to fix problems. This process cuts to the center and allows a simple path for the simplification of products and processes.
And there we have a design that removes the contract point of squeezing and this style of door knob is growing in popularity for all applications.
Communicating the Contract
So know we have a solid contract and we want to create a solid design. From earlier we know that we want to introduce as little contract points as possible through the design. We also need to think about how to tell users what the contract points are.
It is much easier to communicate the contracts when we know what they are. Take these for example.
Bad communication:

what is the interface?
Two systems:
- Person needing to Potty
- Sign directing person to Potty
the contracts:
- The Potty Person:
- see the sign
- The Potty sign:
- point to potty
Where does it fail? The location of the person determines the effectiveness of the arrow. I guess, however this doesn’t fail if, the corner is the potty, or there is some sort of star trek teleportation system, fear of both kept me from walking into the corner.

image from http://www.signservice.ie/
what is the interface?
Two systems:
- Person
- Door
the contracts:
- The Person:
- apply force
- The door:
- open
Where does it fail? The direction of the force in a limitation of the design. To overcome they added another interface, now we have a system of understanding the direction the force needs to be applied. The problem is that the design wasn’t readdressed. Instead a sign was placed. A simple solution may be to have a pull handle only on the side that should be pulled, and a plate on the side that should be pushed, eliminating the need for the second interface, the sign. Or you could resign the door to overcome the limitation of the direction being a factor and making the door open on a push or pull.
Good communication:

image from promotionalpromo.com
what is the interface?
Two systems:
- liquid
- glass
- person
the contracts:
- The Liquid:
- move to contianer
- The glass:
- keep liquid in container
- until needed to be removed
- The person:
- grasp
- tip
- enjoy
Of course this is overly simplified, but here we have three systems interacting. Liquid to a glass, and glass to a person, and liquid to a person. Why has this been around for so many years? and in so many cultures? because it is simple, easy to use, and communicates it’s use effectively. Part of the successful communication is the fact it is so ingrained into cultures. But looking at the design you can see what it’s purpose is.
Conclusion
To wrap up this article I want to recap and bring a few points out.
First, an interface is “an interaction point between two systems regulated by a contractual agreement.”
Why the contract? Well, it is simply a mechanism to quickly and effectively identify the parts needed to interact. These rules exist, in nature and in human made experiences. How do you get a banana? Peel and shove. What if I can’t fulfill one of those requirements? No banana. Any point where two systems interact is an interface, is a contract. Again, if I want you to read this article, you need a computer, need to see the article, and need to understand my language. If you don’t fulfill one of those contract points, no article for you.
Second, readdress the contracts
To build a simple lean interface simplify the contract rather than building more interfaces. It is easy to try and add something to the mix, like a plastic appendage to open a door knob, but the better way is to change the contract and then design to the new contract.
Third, A good interface needs the contract communicated by the design.
The interface itself needs to communicate the contracts otherwise you might end up with people “relieving their waters” in a corner somewhere.





































