Sheldon Cooper would never apply for a UX engineering job. He’d be recruited after filing a 40-page bug report about the office vending machine’s touchscreen, complete with diagrams, a severity scale he invented, and a footnote explaining why the “Cancel” button was “an affront to Newtonian expectations.”
Nobody on the team would find him easy to work with. Almost everyone would agree the vending machine works better now.
He’d write the working agreement first
Before his first sprint, Sheldon would hand the team a working agreement. It would cover pull request etiquette, naming conventions, acceptable emoji in commit messages (none), and which meeting room has tolerable lighting.
Like his Roommate Agreement, it would be long, oddly specific, and right more often than anyone wants to admit. Teams that write down how they work spend less time arguing about it later. Sheldon would just get there first, and with more appendices.
Every button gets a spot
Sheldon has one spot on the couch, and he will explain at length why it’s the correct one. His interfaces would work the same way. The primary action always sits in the same place. “Save” never wanders to the left side of a dialog because a designer felt like a change.
People build muscle memory around where things live. Sheldon would treat breaking it as a personal attack on the user, and honestly, the user might agree.
He takes words literally, and so do your users
Sheldon can’t detect sarcasm without a sign. That makes him a surprisingly good microcopy reviewer.
He’d flag “Let’s get this party started!” on a payment button with a comment like, “There is no party. The user is paying an invoice.” He’d replace “Oops, something went sideways” with what actually happened and what to do next.
Literal language helps screen reader users, people reading in a second language, and anyone using your product while tired or stressed. Sheldon wouldn’t call it accessibility. He’d call it accuracy.
Patterns, repeated exactly
Sheldon knocks three times and says “Penny” three times, every time. He’d love interaction patterns for the same reason. Every dialog closes with the Escape key. Every focus ring looks the same. Every date picker behaves like every other date picker.
If one component behaves differently in one corner of the app, Sheldon would notice before QA does. Then he’d knock on the design team’s door. Three times.
The friendship algorithm needs an exit
Sheldon once drew a flowchart for making friends, and it got stuck in a loop until someone pointed out that it needed a way out. He’d map user flows the same way, with every branch on the whiteboard. Then he’d go looking for the loops where people get stuck, like a form that clears itself after an error or a password reset that sends you back to the login page that sent you to password reset.
Every loop gets an exit. Every dead end gets a next step.
Where the team helps Sheldon
Sheldon’s first usability test would not go well. When a participant couldn’t find the export button, his notes would say, “User is wrong.”
This is where his teammates matter. A designer would help him see the participant’s hesitation as data. A product manager would help him explain findings without making anyone cry. Over time, he’d learn that social protocol applies to interfaces too. When someone is upset, Sheldon offers a hot beverage. When a flow fails, a good interface offers something similar: an apology, an explanation, and a clear way forward.
What we’d learn from Sheldon
Sheldon would remind us that rigor and consistency are a kindness to users, even when they come from someone who struggles with kindness. His precision works best alongside teammates who notice how people feel, and his teammates’ work gets better with someone who notices everything else.
He’d also remind us to write down what we agree on. Preferably with appendices.
This article is part of the Famous Fictional UX Engineers series.