2000 words on lamps, because why not?

Hello! I am traveling again.

Let’s take a tour of the eight (!!) light sources in my hotel room.

First, there are two paddle switches in the main entranceway. They light the ceiling lights above the kitchenette. Note that the one on the right has a tiny green light on it, so that when you enter your pitch-black hotel room you theoretically can find the light switch (since it is not next to the door, but rather past the bathroom door).

Two paddle switches - the very flat toggle-able switches almost the size of your palm. The one on the right has a small glowing light on it to make it easier to find when it's off.

Then, while we’re near there, there’s a paddle switch in the bathroom for its ceiling light. Like the entryway switch, it’s got a light to help find it. Unlike the entryway switch, in this case the light is a series of blueish LEDs that glow from behind the switch.

Wall paddle switch backlit with blue-white LED lights. It makes it glow from behind.

On the desk there’s a stylish brushed steel desk lamp with a rocker switch on the flat base.
Brushed steel desk lamp with a flat steel base. A black rocker switch (about an inch long) is on the top of the base.

As we move to the end of the room, we find a wall lamp to light the closet.  It’s powered by a paddle wall switch directly below it. Unlike most of the other wall switches, this one has no light to help you find it.

An odd wall lamp styled to look like someone had cut a table lamp in half and glued it to the wall, still working. The paddle switch is about 5 inches below it.

Opposite the closet is the first table lamp. It is powered by a three-position rocker switch, where “center” is off, “left” turns on the light bulb under the shade, and “right” lights a very soft moonlight-like light in the round base.

A table lamp. It has a tall cylindrical shade which covers a standard light bulb, and a large round base that glows like the moon.

On the other side of the bed is this monstrosity: a cylindrical wall lamp over the end table that is only about seven inches in height, but probably 15 inches around. Its light switch is a tiny old-fashioned steel toggle switch that is mounted to the underside of the lamp, so you can’t see it, you have to reach under the shade and hope you find it.

Cylindrical wall lamp with steel toggle switch under the shade. The switch is about the diameter of a ballpoint pen's ink barrel, and about the length of the first knuckle on your pinky finger.

Then there’s a floor lamp. It’s got a push-through switch under the shade near the top of the lamp. This is notable because floor lamps can literally put their switches anywhere from the base as a foot switch to anywhere on the pole, up under the shade, so it’s always a guessing game to find the switch.

A brushed steel floor lamp with a cylindrical shade.

Finally, our last lamp: a table lamp on the far side of the sofa. Like the other table lamps, it has a rocker switch on the base.
A brushed steel table lamp with a conical shade and a thin steel cylindrical body that ends at a thick cylindrical steel base and the same rocker switch as is on the desk lamp.

What does this have to do with web design?

When we talk about consistency, we generally divide it into two kinds: internal consistency and external consistency.

Internal consistency means that an interaction looks and behaves the same way inside a given system regardless of how many times it appears, whether that system is a webpage or (preferably) a section of the website, or even the whole website.

External consistency means that an interaction looks and behaves the same way inside a given system and outside that system. Or to put it differently, that people can recognize the way that the interaction works because they’ve seen it somewhere else. You didn’t invent it.

When we design an interaction such as “choosing a radio button” or “turning on a light”, we want the interactive element to be:

  • recognizable as interactive, whether that means it looks clickable, tappable, tabbable, or in the case of light switches, twistable, pushable, rockable, pullable, etc. It has affordances that tell us we can interact with it.
  • recognizable as changing state in a specific way. In the case of radio buttons and checkboxes that’s “deselected” to “selected”, for select menus it’s a change from one selectable value to another, and for lamps it’s “off” to “on”, or back. The same affordances that said “you can do something with this” generally hint at what you can do and what will result.
  • memorable, so if I’ve never seen this before I’ll remember how it works the next time

Ideally, all the radio buttons on a website will look and behave the same way, with the same affordances, so that the user only needs to learn to recognize our specific radio buttons as radio buttons and they will understand how they’re used.

Context is, as always, king

But there may be reasons why we’d have radio buttons look or behave slightly differently in two different areas of the site, and that difference is about context.

When we talk about the context changes that would force us to design two different radio buttons the differences can be pretty subtle. (Also I am in a hotel room at 11pm and can’t find any obvious examples.) So let’s look back at the light switches.

The desk lamp isn’t being used to light the entire space, only the desk, so (speaking as an experienced desk user) we can be confident that the user is very close when operating it. The user probably has empty hands when switching on the light, or if not, can easily empty their contents onto the desk. This light isn’t generally being used for safety purposes.

In the “using a desk” context, a big ivory-colored paddle switch on the stylish brushed steel desk lamp would be ugly as sin and possibly hard to use. A small black rocker switch on the base is much more appropriate for this context.

The wall switch in the entranceway is being used to light a significant portion of the room. The user could be wrestling a luggage cart into the dark room, wandering in inebriated from a fun night out, or experiencing any number of other distractions or temporary disabilities when they need to turn on the light. (I count a luggage cart as a temporary disability for door use in every hotel.) We can’t be confident they are near the switch they are trying to manipulate or that they can easily manipulate it.

In this context, a small black rocker switch would be a nightmare, because it’s small, difficult to locate in the dark, and difficult to switch with the back of a hand or an elbow. A paddle switch with an LED on it is both more accessible and more usable in this context.

We expect the hotel room to be internally inconsistent at the room level because the entranceway context and the desk lamp context are different.

On the other hand, both of the lamps next to the bed have the same context. They both need light the area around the bed for the sleeper. They both need to be easy to reach and manipulate for both the person about to go to sleep and the person suddenly awakened. Neither can block access to critical elements such as alarm clocks or telephones.

In this case, there’s no justifiable business case, user need, or technological constraint that explains why the two lamps are incredibly different.

It’s the website equivalent of having two sets of radio buttons on the same page in the same form asking contextually similar questions, but one radio button set uses the browser’s default styles and the other set is styled to look like poop emojis with drop shadows.

But that’s not the biggest sin the monstrous bedside wall lamp commits. Its biggest sin is breaking the user’s mental model.

If context is king, external consistency is emperor

When we’re born, we know nothing about radio buttons or light switches.

As we are exposed to new interactions, we learn to recognize patterns. We expect radio buttons to behave like other radio buttons, even if we’re too young to know why they’re called radio buttons. We expect light switches to look like other light switches (or at least use recognizable affordances). We expect the kinds of light switches we see on walls to fit one pattern and the kinds that are on desk lamps to fit on another, even if the switches themselves are different.

Our mental models have abstracted both the similarities and differences of all the switches we’ve used in our lives. Even if our users don’t consciously know the difference between the paddle switch’s intended context and the rocker switch’s intended context, they do know that a rocker switch doesn’t belong on a wall and a paddle switch doesn’t belong on a lamp. (This is also why Norman doors drive us crazy.)

The monstrosity wall lamp is out of place in this hotel room not just because it’s internally inconsistent with the other lamps in the room.

It also broke my mental model. It was not externally consistent with my concept of how lamps work.

Usually when a lamp juts out of a wall or hangs from a ceiling, there’s a switch on the wall. If there’s no switch on the wall, there’s a chain hanging from the center of the lamp. If there’s no chain, then look for a rotary switch on the cord, or something on the body of the lamp.

There shouldn’t be a toggle switch on the underneath of this lamp. My mind refused to accept it.

My mental model of a lamp involves a base or mounting plate, a body, a light shade, a light switch, and a hot incandescent bulb. Low-heat lightbulbs are pretty new to the scene. For the vast majority of my life, reaching underneath a lamp shade meant risking my tender fingertip skin would brush against a hot glass bulb and burn.

If the monstrosity lamp had two incandescent bulbs in it instead of comparatively cool CFLs, then it would throw enough heat onto the night stand to reheat a steak. No responsible lamp designer in the world would put a steel toggle switch underneath two incandescent bulbs, because the user would burn their fingertips every time they tried to turn the light off.

This lamp broke my mental model so badly that “under the shade” was the last place I looked, and I even considered that it was a decoy lamp of some sort.

There are eight light switches in this room and arguably they’re all different. That’s not ideal. For the user, that’s a lot of learning material. That causes hesitation on first and subsequent uses because the user has to keep reminding themselves, “oh yeah, this one’s the three-spot rocker and that one’s the unlit paddle switch.” They can’t just look at the lamp and immediately know how to use it because there are too many lamps with too many differences.

(Side note: the fact that every lamp looks profoundly different actually works in the user’s favor because it makes the differences more memorable and learnable. If they all looked the same but the switches were different, I’d be teaching them how to fly out the 3rd story window of a Hilton.)

Of the eight, seven are externally consistent with the standard user’s mental model and abstraction of the contexts for “light switch”. So even if they’re not internally consistent, they’re arguably usable.

The eighth lamp breaks the externally consistent rule. For users who have the same mental model I do (which would arguably be anyone over the age of 30), it doesn’t follow any known patterns. As a result, the user may figure out how to use it but choose not to use it at all, or may choose to use it but hate it, or may never figure out how to use it. There’s even a chance the user will break it trying to figure out how to use it. It is arguably unusable.

The moral of the story

When evaluating a design for consistency:

  • First, do your best to be both internally and externally consistent, taking context into account. This is the path that causes the least cognitive load for your user. Bonus: it also result in the most code reuse and happiest developers.
  • If you can’t (or choose not to) be internally consistent, be externally consistent. You’re increasing cognitive load on your user, and probably increasing development time, but there are some valid reasons to take this path as long as you haven’t broken the user’s mental model.
  • No matter how smart you think your new component is or how slick you think it behaves, if it’s externally inconsistent and breaks the user’s mental model, you’re probably being an ass, not helping the user.
  • If you’re absolutely sure your new component with the new mental model really is the better solution, test the ever-loving hell out of it with your users. There is the tiniest of chances that you are the Einstein of interaction designers, but you owe it to your company, your users, and yourself to be sure.

Look a layer deeper

This is a hotel bathroom:

To take a shower, you must:

  • either sit on the toilet, squeeze between the toilet and the tub (you have about 4 inches of clearance) or stand in the tub
  • Stretch up and over to turn on the shower, possibly with the help of the grab bar
  • Wait for the water to reach suitable temperatures
  • Climb in the tub to shower, possibly with the help of the grab bar. In this case, the tub has a significantly curved bottom, making slipping slightly more likely.

Due to the placement of the grab bar, you will likely walk into it two or three times while showering. The irony of this is that the grab bar is supposed to help prevent a fall, but because it juts into the tub, maneuvering around it makes a fall more likely.

This is also a hotel bathroom, at a different hotel roughly 1500 miles away:

To take a shower, you must:

  • Walk up to the controls
  • Bend over slightly to turn on the shower, possibly with the help of the grab bar
  • Wait for the water to reach suitable temperatures
  • Climb in the tub to shower, possibly with the help of the grab bar. In this case, the tub has an almost flat bottom, making your footing more secure.

They both seem reasonable, when written out. In fact, they could have both been generated by the same list of business requirements:

  1. The room shall have a shower tub with suitable controls
  2. The room shall have a toilet
  3. The room shall have a sink
  4. The user shall have the opportunity to turn on the shower and use it
  5. ACCESSIBILITY REQUIREMENT: The shower shall have a grab bar.

Both the installers and the users would likely complain about the addition of the grab bar in the top bathroom.

It does make people safer, and it makes the shower more accessible.

On the other hand, it’s inconvenient to install. It’s inconvenient to use. It doesn’t really add to the experience. It’s ugly.

An almost identical grab bar is being used in the second bathroom, but it’s likely to generate significantly fewer complaints from either developers or users.

It’s easy to install. It’s easy to access. When you’re showering, it’s not in your way. It’s not what I’d call aesthetically pleasing, but it’s not in-your-face breaking up a tile surface and making the shower feel smaller.

The first bathroom’s grab bar feels like a major inconvenience, and the second bathroom’s grab bar feels like just another element of the room. The first bathroom’s accessibility is actually hampered by its grab bar (while also still making the act of turning on the shower safer). The second bathroom’s accessibility is only improved by its grab bar.

Why?

You probably already know it has nothing to do with the grab bar and everything to do with the toilet.

In the first picture the accessibility of the entire bathtub is hampered by the fact that some architect somewhere thought it was more convenient to only run pipes to the inside wall — and so the shower controls, toilet, and sink are all next to each other. (The room next door’s design is flipped so that all its pipes face these pipes, making plumbing even easier.)

The fact that this makes the plumber’s job easier and the job of every other user more difficult was apparently summarily rejected.

The grab bar must be where it is in that shower because it’s the only place where someone stretching over a toilet to turn on a shower would be able to access it. And it’s desperately needed in that location because the rest of the architecture automatically makes the user less safe. Even if the user is an average-height 21-year-old healthy human being. Especially if the user is five foot tall, 85 years old, and has osteoporosis.

In the second bathroom, the plumbing is run on both walls. No one has to lean over a toilet to turn on a tub. It’s automatically safer and more convenient for every single user. In this case, the grab bar becomes what it was intended to be: an additional handhold available to everyone, and required by a few.  The 21-year-old user may never use it (or may never consciously use it). The 85-year-old user will still use it, but also find the tub safer and easier to use overall.

Let’s talk about the quality of your website for a second.

Your information architecture is the plumbing and the walls. If someone put constraints on that IA that regularly cause people to trip over bad navigation or weird structures or disruptive advertisements, that’s going to have an impact on your accessibility project.

Your HTML and CSS are the toilet and the tub. If your code is unwieldy, if it has a curved bottom where users are expecting a flat surface, if it gets in its own way, then it gets in the way of your users.

If the HTML is not semantic, it’s likely that inherent accessibility is being lost — you’re being forced to implement accessibility workarounds and ARIA roles and scripts — because of that lack of semantics. (If it’s not being written syntactically there’s a decent chance that there’s a hole in the tub big enough to eat a person.)

If you’re using CSS to do things that you should be using HTML to do, it’s a lot like putting a toilet in front of the controls. You might be fine as long as you only want to use the toilet, but as soon as you decide to shower it’s in the way.

And both the bathrooms and our code result in the same conclusion: to make the accessibility, someone’s got to gut that room at the top, move the pipes, remodel it, and then rebuild it.

But that’s not the grab bar’s fault. That’s not the screen reader’s fault. That’s not the alt tag’s fault. The business requirements didn’t say “stick this handle in the most inconvenient place possible”.

If the only way to make your design accessible is to put the accessibility controls and features somewhere that they get in everyone’s way or force a major redesign, that’s not because accessibility is bad. It’s because the current design is inconvenient, unsafe, or both. And if those things are true for the 85-year-old who can only use Dragon Naturally Speaking to navigate your site, they’re also true for that 21-year-old who likes to use Dragon to read a webpage while their eyes are occupied knitting a sweater or watching a kid or playing with a dog.

In other words, folks, keep the blueprints handy and the sledgehammer near by.

The names we won’t say

“Why won’t you tell me their name?”

We were at a conference, talking about the fact a known “problem person” is attending. Those of us who’d attended for a while (and had been around the industry) knew the person had been accused of sexual harassment multiple times. The incidents keep piling up, year on year.

But none of us could say their name.

One of the attendees was having none of that. “If I’m not safe because of their presence, you need to give me a name. Why won’t you tell me their name.”

I didn’t have an answer. As a community, we just didn’t say their name.  But why… was it fears of a lawsuit? Was it that making accusations felt like hearsay (even though I’d heard six separate, verifiable stories about them?) Or were we just afraid we’d have to tell the truth — that we’d known the stories but had repeatedly refused to do anything about them because we didn’t want to rock the boat?

So we did nothing, and it happened again.

Every year there’s a new story. Every year another victim’s story is told across the whisper network but never bubbles up to the point that someone does something. And every year, the information diffuses unevenly so not everyone knows.

And the cycle of vulnerability begins again.

Why won’t we say their name? Why won’t we remove them from the community? Why won’t we choose the safety of those vulnerable to these predators over the silence we stick to?

I wish I had a good answer, other than just being afraid of what happens when I speak up.

In the #metoo era, our society has to reckon, repeatedly, with abusers in our society we haven’t removed. We’ll say they’re “important” or “essential” people, that they have power or smarts or political capital. We have to reckon with these small decisions that have repeatedly left vulnerable people, often new to the business, open to being preyed on by these abusers. We’re frightened, as a group, because we’re frightened individually of the repercussions of saying no.

I want to say their name. I have no idea how to, though. The stories of abuse aren’t mine to tell. I just know what I’ve heard.

At some point in the near future, someone will say their name publicly. And they will be met with scorn, denial, threats, and worse. They will also be met with a chorus of “me too” that will raise questions about the silence this community has built. Other names will rise. Hard and painful conversations will follow. Lawsuits may fly.

But it will be a moment of true honesty for all of us in this community. Design requires honesty. Without it, design is nothing more than a façade of “design mythmaking” wallpapering over an empty, lifeless, sometimes dangerous manipulation of truth.

May that moment of honesty come soon. In the meantime, the predator keeps lurking, unnamed like some ancient sea monster.