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.

stable unstable

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.

stable-straightstable-circle

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.

less-unstable more-unstable

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.

jackknife

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.

sprint-chat-hold

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.

sprint-queue-1

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…

sprint-queue-2

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.

sprint-queue-3

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.