I’m going to write about “bad” design.
When I write about “bad” design, I want you all to understand that a design that’s bad for me might be a perfectly good design for a different user. It might even be the ideal design. It’s about the context.
For example, I recently applied to speak at a conference. The form asked me for the speaker’s name.
A half a dozen years ago, I stopped capitalizing my name. Why? Because it felt right. Names are labels, my label needed to change to match its contents, so I stopped capitalizing it.
Except not every website has the flexibility to handle a lowercase name, apparently.
![A screenshot of a portion of a form for speakers. The field label is speaker name and it allows for a first name and a last name. The form is in an error state with the following error message under both the first and last name fields: all uppercase or all lowercase letters are not allowed. Below that is an alert box that reads please note that you're logged in as anne gibson and submitting a session in that context. This event doesn't allow you to submit session [sic] for somebody else while being logged in as yourself, or to submit sessions for multiple speakers with the same account. Below that is a warning that states changing this will update your system-wide profile.](https://theinterconnected.net/wp-content/uploads/2026/10/speaker-name.png)
The form won’t let me put my name in lowercase! But when it’s not in lowercase, it’s not my name! I know how it should be capitalized! Because it’s my name!
I won’t deny that having had my name misspelled and mispronounced as Ann most of my life [1]Yes they have different pronunciations, at least in the Delaware Valley, don’t @ me. has wrapped a bit of bitterness around my soul that my choice of capitalization has not eradicated, but instead fed as if it was Miracle Grow.
That same bitterness has led me to defend users’ names from overthinking designers and developers on many occasions. There’s a reason why we have a list of Falsehoods Programmers Believe About Names, and there’s a reason why I now use it as a checklist of experiences instead of a warning.
(One through eight, seventeen obviously, twenty five, thirty one — shout out to everyone whose last name is “beaver” — and thirty nine, so far.)
But when we critique, we have to recognize that sometimes a “bad” design is being viewed in the wrong context.
Not always, and if you bring me a design where you’re putting yellow text on white (or any other inaccessible color combination LOOKING AT YOU SHAMPOO BOTTLE DESIGNERS) you’re still going to hear from me about it.
But sometimes.
The name on this form is the one automatically fed into the conference program. That’s good! That means the organizers don’t have to take the data from the proposals form and retype it into the conference program form. They can’t mess up the spelling during the retyping, they can’t miscapitalize, they can’t get the spacing wrong… the speaker is the only one responsible for the way the speaker’s name displays.
But this poses a problem: what if the speaker who would normally write their name as Anne Gibson entered anne gibson because they were in a hurry and it’s just the proposal form, so someone will fix it later when they write up the conference program?
There is no “someone to fix it later”, because that step doesn’t exist. When a bunch of speakers half-ass their own names, the programs look less professional, and the speakers get upset at the way their names are presented.
From the standpoint of conference organizers, having an enforced name format ensures consistency, avoided mistakes, and programs that are visually less jarring.
Do I think there should be better instructions on the intake field? Yes, yes I do.
Do I think that [2]outside of “user would like that context” this is a workable solution to the problem? Actually, yes I do. That doesn’t make the Falsehoods Programmers Believe About Names any less true; now that the constraints on the designers are visible to me, I can understand the decision.
The tech support rep I complained to (who explained the constraints) used an override to allow me to (un)capitalize my name correctly. Presumably, everyone whose name is outside the bounds of “beliefs about names” can still get their name displayed correctly if they contact support.
The key is the context. With only the context of the user in mind, this looks like a bad design. Within the context of the conference program publication, it’s a better design. [3]If I were the designer I would question whether the cost pressure put on the support team was worth the extra guardrails on the field. But I’m not, and that’s the point. For all I know, … Continue reading
When I write about “bad” design , I don’t know if my context is the only context. I’m going to anonymize the designs as much as possible. These posts aren’t about shaming a company and its designers. They are about saying “in this context, this choice can backfire and here’s how”.
I hope that everyone who reads these posts will keep that context in mind 🙂 [4]ha! see what I did there?
Notes
| ↑1 | Yes they have different pronunciations, at least in the Delaware Valley, don’t @ me. |
|---|---|
| ↑2 | outside of “user would like that context” |
| ↑3 | If I were the designer I would question whether the cost pressure put on the support team was worth the extra guardrails on the field. But I’m not, and that’s the point. For all I know, it might be a cheaper option to have customer service handle the issue. |
| ↑4 | ha! see what I did there? |