Frog House

I think about this story so often I made a logo for it.

When I was nine, I built something of a modernist mansion out of Legos. It had an open floor plan with a staircase to the second floor in the middle. Now that I think about it, that kinda describes the house I live in now. Anyway,  I scoured my collection of Legos for as many windows as possible. That wasn’t easy. Lego kept things pretty basic back then and blocks with angles or clear plastic were super rare. This took serious time and concentration. I added some furniture, sealed the roof down, and opened the front door for the new occupants.

It was early summer and tiny frogs were emerging from stagnant water next to a storm drain a nearby stream. I went down to the stream (work with me here) and captured about five penny-sized frogs, (toads, ok) brought them home in a butter tub, (right, I know, not really butter either) and put them in the Lego house. This involved more jumping out than I had anticipated.

When I finally got them all in, I carefully sat the house down in happy anticipation of the joy these frogs would have exploring their new home. I wished so hard that I could be a froglet (yeah, that’s a word – look it up) inside that awesome house. I would look out the windows, sit on the couch, but most importantly I would run up the stairs and discover the whole second floor.

There is a feeling I am thinking about. Anyone who has presented a home cooked gourmet meal to a four year old who only likes bread and ketchup knows this feeling (see below). That feeling when you have worked very hard to make something wonderful, and that wonderful thing is rejected. Pearls before swine, you might think. It is more than a disappointment. It is an offense.

It is in the nature of the creative person to make things in happy anticipation of their debut. It think it’s necessary, even when making art for hire, to tap into your own desire. You have to look at the blank page and wish for something there. If you don’t like it, how can you expect anyone else to?

So when the frogs just sat there. I had that feeling.

Motivated reasoning builds an explanation after having an emotional reaction to facts. Our brains, by design, process emotions faster than logic. Logic, late to the game, has to operate in the atmosphere of that bias. So I decided the frogs were idiots. Stupid idiots.

Temperamental architect that I was at the age of nine, I wasn’t homicidal. Or whatever the word is for frog-killer. I gave them (and me) some time to think about it, and returned them to the pond.

That pause is crucial to giving logic an advantage over emotion. If you can isolate how you feel about the facts before figuring out what is happening, you have better chance at reaching a rational conclusion and creating an effective solution.

Last week I had some designs in usability testing. I had made a decision to add one or two clicks to a process in the service of clarity, and clarity was successfully achieved. Users knew what to do and the design was hailed as a success. But I heard a few users call out the extra clicks. “You put an extra step in here. It’s going to take longer.”

Time to take apart the frog house.

Getting innovation from a spigot.

There is a difference between a conceptual model (the way a user thinks about a system), and a functional model (how a system actually works). There is also a difference between what a system does and what the user wants. We tend to overlook these differences to get things done, but if you take the time to identify the needs and models, you’ll find opportunity in the gaps.

Let’s look at the humble faucet (hat tip to Donald Norman). First, faucets were positioned over sinks and tubs to save the user a trip to the well. At this point the functional model and the conceptual model and the user need all aligned. By turning a lever or wheel the user could adjust the amount of water coming out of the faucet. The user might memorize which direction to turn the control, but no advanced technical knowledge was need to understand how a valve works.

The addition of heated water complicated the device and at the same time users were adjusting their needs to the new capabilities. Initially, the hot water was added as a second spigot, but users had moved their focus from the receptacle to the stream and they wanted moving water, not just a full bowl or bucket. And users didn’t want one cold stream and one scalding stream, they wanted to control the temperature and flow of a single stream. This was solved by mixing the two sources after the valves. The resulting device was still simple enough to be understood by users and they were able to manipulate the system to match their needs.

But the cognitive load on a system like this is significantly higher [than the single temperature spigot] because the relationship between the user needs and the functional model is no longer one-to-one. Users want a specific temperature and flow, but adjusting the temperature also changes the flow and vice versa. So any adjustment to a single user need requires two adjustments to the system. The burden of translating user needs to the functional model is put on the user. With this complexity comes errors, and opportunity.

In the 1940s Alfred Moen burned his hand under a faucet and thought, “you ought to be able to get what you want out of a faucet.” He invented the single handle mixing faucet to solve this problem. Now the movements of the controls mapped directly to the user needs — forward and back for flow, and left and right for temperature — and the user no longer needed to understand how the system actually worked.

In the 50’s housing boom after WWII the single handle mixing faucet became an icon of modern living and the cornerstone of one of the largest plumbing product companies in the world. So look at those gaps between the user needs, conceptual model, and the functional model, because that’s where opportunities lie.

Addendum. Here’s a question now that we’re thinking about faucets. There is another gap between the user needs and the functional model. It’s that pipe full of cold water sitting between the faucet and the water heater. Users know they need to flush the cold water out to get to the hot water, but again the user has to translate their need onto the functional model. What innovations can you think of to close that gap?

How to back a trailer, for nerds.

I’m not terribly accomplished in the manly arts. I can’t throw a football, work a barbecue grill, or even begin to recite the rules for poker. I put my chances of landing a high five at about 50/50.

But, tell you what, I can back a trailer.

And here’s why – In my brain I have a conceptual model that accurately predicts the behavior of a trailer relative to a car when going backwards. (See what I did there we’re back to conceptual models.) This ability to predict is the most important aspect of a conceptual model. I’ll get back to this.

Here’s how I think about backing up a trailer.

First, there are two dynamic states that describe the angle between the trailer and the car. Stable and unstable.

• In the stable state, when the car and trailer move, the angle at the hitch is fixed.
• In the unstable state, the angle at the hitch changes as the car and trailer move.

The stable state can exist on a straight line or circle and is true going forward or backward.

• If the car and trailer are moving in a straight line, all the axles are parallel.
• If it’s on a circle, all the axles point at the center.

Going forward, the unstable state is always in transition toward the stable state. This is why it is easier to go forward with a trailer. But going backwards, the unstable state is either changing toward the stable state or away from the stable state. The stable state is so fragile in fact, that it’s nearly impossible to maintain going backwards.

It’s the existence of these two different states of instability that renders more common advice about backing a trailer like, “Turn the wheel in the opposite direction,” half wrong. It will get you started and then get you into trouble.

Instead, think in terms of stable and unstable. If you are backing up in a straight line, and need the trailer to swing toward the driver side of the car, adjust the wheel (clockwise) to create an unstable state and as soon as you get the angle you want, turn the wheel (counter clockwise) to re-stabilize. They key is to learn to feel the difference between stable and unstable and to always stay close to that stable position. Most of your movement should be in a stable state either in a line or on an arc. Only use the unstable state in passing to make adjustments.

Finally, there is a state that you cannot get out of going backwards. As the angle at the hitch increases, the point of stability moves away from the center position of the steering wheel. If the angle is too much, the point of stability is no longer available via the steering wheel. No backwards motion can bring you back toward a stable state. You’re jackknifed and you’ll have to drive forward to regain access to stability.

What does this mean for user experience?

I’m sure an automotive engineer could poke some holes in this model. Especially the brilliant engineers that designed the dynamic steering system for Volvo trucks.  There are factors such as the distance between each of the axles that are not part of my model but do affect the behavior. But there is a big difference between a functional model (how the system really works) and a cognitive model (how the user thinks it works). As long as the cognitive model allows me to confidently and quickly put a trailer where I need it, the difference is unimportant.

There are many important qualities to a good conceptual model. It must be intentional, coherent, and elegantly communicated to the user with a minimal cognitive load. But it’s primary purpose is to allow the user to predict the behavior of system being used.

What happens when a conceptual model breaks.

I start every interaction design project with a conceptual model. Maintaining the integrity of that model is crucial to staying in control of the user experience.

Yesterday, Sprint handed me a great example of what happens when a conceptual model is broken.

See what happened there? I screen grabbed this because it’s a little funny, but I’d like to decode what’s going on here by looking at it through the lens of a conceptual model.

The layout follows convention for a chat window with new comments added at the bottom and the history scrolling up. Following convention allows me to focus on the task and not the interface. So far, so good.

Now the interface asks me to change the conceptual model associated with the chat convention, because chat requires two people, and I’m the only human here.

I’m waiting, and if I don’t get feedback of some sort, I’m out.  So Sprint tells me I am number 8 in line. Then in about 20 seconds, tells me I’m seventh. The system is asking me to build a new conceptual model into my experience. There are a number of people ahead of me and it will be my turn when all of those people have been helped. I’m standing in line. Got it.

As long as there is a steady countdown to a conversation with a person, then it doesn’t matter if I’m imagining one representative taking care of a single line of people, or a feeder line leading to many representatives, or multiple lines each leading to an assigned representative. My model of standing in line reliably predicts what is happening on screen. Until…

Huh. Ok. Repeating a number doesn’t fit the model. I need to adjust my model some. Did it give me an update because someone is taking a long time? Is it a bug? This is the first crack in the model.

Now the intended model has been shattered. Ask four people why the line just got longer and you’ll get four different answers.

1. Someone was given preferential treatment over me. (perceives injustice)
2. I broke it because I was reading Facebook in another window. (blames self)
3. One of the reps went to lunch and the algorithm for determining my place in line was adjusted. (technical perspective)
4. Sprint doesn’t know how to count. (perceives incompetence)

I’ve seen this in usability tests many times. When users adjust their model for anomalies, they turn toward subjective explanations and their behavior becomes difficult to predict and design for.

I know that interfaces don’t always behave as intended, so I stayed on the line and worked with a very nice person who solved my problem. But users who already have a problem are likely to take an adversarial attitude with a company, and when you lose control of the experience the results can be costly.