Now that Cooper has an office in New York, we find ourselves using video conferencing much more than previously. I attend three recurring video conference meetings every week, plus several ad hoc ones. Just about every meeting involves technical difficulties, delay, confusion, and dissatisfaction for all the parties participating. 

The same is true for just about every presentation, whether in person or virtual, I give or audit. The projector, the presentation software, the microphone, the slide clicker, all conspire to make the experience rocky and unpleasant. All of them require that I know technical details that I really wish I didn’t, and didn’t have to know.

One of my colleagues asked me, after a frustrating session trying to get all of the digital bits and pieces to cooperate, why the complications never seem to go away. Here is my answer to that simple but profound question.

While it’s tempting to blame the vendors, the problem is broader than any one company’s failure. As proof, we’ve changed video conferencing vendors three times. We’ve upgraded our hardware. We’ve taken classes from the supplier. There is some principle at work here other than just simple bad quality or bad design.

The difficulty in making these systems work smoothly comes from their edges, not from their centers.

The people who create these systems are not — usually not — incompetent, nor evil. Their products undergo tests and quality assurance regimens. They are not blind to the notion that giving their users a bad experience is bad for their own self-interest. So why do these failures continue? Why is it that our experiences using these systems don’t seem to improve even with repeated use?

The difficulty in making these systems work smoothly comes from their edges, not from their centers. Each vendor builds a reliable and effective product, and through diligent testing assures that they meet high standards of performance. The only place where those standards fall is at the edges, where the maker is unsure of the requirements.

Reconciling the two disparate points of view is what the profession of interaction design is all about.

The edges are the interfaces with entities outside their control, outside their offices. Out there they are a little unsure of what they have to do and what forces affect them. Inside the company’s four walls they know exactly what they’re making, how it should behave, and what it should do. But for the entities outside those four walls, some measure of haziness creeps in, notably, the user.

A button on a user interface is well-designed if it makes these things clear to the user:

• Its physical location.
• Its function.
• Its purpose and current state.
• The consequences of its use.

Most contemporary, mainstream products are reasonably clear on these points. The difficulty arises when the function, purpose, state, and consequences of that button are not precisely the same as the user imagines them to be. Reconciling the two disparate points of view is what the profession of interaction design is all about. Interaction designers study the user and then design the placement, appearance, and function of the button so it is consistent with the user’s mental model of what is happening inside the program. Good design goes a long way towards reconciling the two sides; however, it can always be better.

Two successful systems fail as they interact.

Of course, the user is only one of the two big areas of interaction with external entities. The other, arguably bigger and more consequential area is the interaction with other systems, particularly hardware and software systems from other vendors.

When I use a sketching program on my computer, it runs as a standalone, sovereign application, and therefore using it is straightforward, if not easy. But when I use a video conferencing application on my computer, it has to talk to multiple correspondents on their various computers and browsers, each one with their different brands of microphones and web cameras, and then the image is sent to a projector, and the sound is sent to external speakers. Each different product by each different vendor has built into it just a small amount of uncertainty about the behavior of the other guy.

From the user’s point of view, that well-designed button loses a lot of its clarity. When all or part of that button’s function, purpose, state, or consequences take effect in another vendor’s product, there is every likelihood that the situation has neither been fully thought out nor verified in real-world conditions. When I push “Submit” on a website, I generally know what that means on that website, but I may have no idea what that means on a related or connected site.

Whose fault is it that the user is misled about the effects of their actions in a product other than the one the action is initiated in? Each product can say with all sincerity that, “It isn’t my fault.” Of course, while true, this assertion does not help the user. Better than assigning blame, we should ask whose responsibility it is.

It is clearly everyone’s responsibility, but as the old saying goes, “When everyone is responsible, no one is responsible.” It’s too easy to claim that you thought someone else was going to take care of it. What’s more, the rules of business grant no value to such consideration. Modern business norms and accounting systems ensure that any time a cost can be externalized, it must be.

One of the reasons why Apple’s products are so well regarded is because they “just work,” and the main reason they do is because most of the supplementary products that run on or with Apple computers are made by Apple. Apple’s mouse division can, in fact, really know what the folks in Apple’s keyboard division are thinking, so their products don’t misconstrue each other’s behaviors or interfaces. There’s also a notion that what is good for the mouse division will also be good for the keyboard division.

Video conferencing and presentations are always fraught with technical minutiae simply because they always rely on making multiple products from multiple vendors in multiple product areas work together performing a complex task across great distances and on disparate platforms.

I have devised a simple formula for understanding this interface problem that I call the “Edge Calculus.”

I have devised a simple formula for understanding this interface problem that I call the “Edge Calculus.” From a single vendor, the total failure is the averageof the individual failures of the elements, or (x1+x2+…xn)/n. When there are elements from more than one vendor involved, the total failure is theproduct of the individual failures, or x1*x2*…xn.

For example, I’m typing this draft of my blogpost into Pages, Apple’s word processor, on an Apple computer. If we assign each product a success rate of 90%, the final result I experience as a user is 180/2 or 90%.

But when I use the video conferencing product GotoMeeting, from Citrix, on my Apple computer, the two 90% products multiply out to 81%, and my experience degrades. Further, when I use an external microphone from Samson, a Webcam from Microsoft, projected through a Samsung, I now have .9*.9*.9*.9*.9 or 59%.

The Edge Calculus puts in sharp relief the uselessness of determining fault. Instead, it makes clear that everyone has to take full responsibility for the quality of the behaviors of every element in the chain. This is an unfamiliar approach to conventional business models, because businesses are loathe to accept indirect expenses that they can avoid simply by pointing the finger of blame somewhere else.

From this discussion you might imagine that I think the problem of the Edges is insoluble, but that is far from true. The digital revolution is changing everything, including the rules of business. It is conceivable that companies will recognize that, while it’s not their fault, it is their responsibility to assure that every part of the execution chain operates with the same high quality as every other part. Delegating the responsibility to another vendor is like saying, “That hole is only in your end of the boat.”

What each organization has to do today is to regard the edges of its products with as much diligence and attention as they give the center. The quality of both their outside system connections (known as application program interfaces, or APIs) and their user interfaces demand levels of expertise and investment that have historically fallen short.

One of the most noticeable characteristics of man-made complex systems is that they don’t work.

One of the most noticeable characteristics of man-made complex systems is that they don’t work. Even when they do work, they don’t work well, have unintended and undesirable side effects, and cost more in time and resources than expected. Software systems are archetypal examples of this, but agricultural, political, and financial systems have the same issues. The primary origin of the dysfunction comes from the edges.

Written by: Alan Cooper, Medium
Posted by: Situated Research