Happy Gilmore never meant to become a UX engineer. He was a hockey player who couldn’t skate, until someone noticed he could hit a ball 400 yards with a running start. Put him on a product team, and you’d get the same story: a newcomer with no formal training, a wildly unconventional technique, and results nobody can argue with.
He’d also have a temper. We’ll get to that.
He comes from a different sport
Happy doesn’t know the rules of the game he’s playing. He’s never read the style guide. He didn’t go to design school, and he learned to code by breaking things on purpose.
That turns out to be an advantage. He doesn’t do things the way they’ve always been done, because he doesn’t know how they’ve always been done. He looks at a twelve-step checkout and asks, “Why can’t we just do it in three?” Nobody has a good answer.
Plenty of great UX engineers start this way. They come from support, or graphic design, or teaching, or a hockey rink, and they bring a way of seeing the problem that the people who grew up inside the field have trained out of themselves.
The drive is not the whole game
Happy’s big features are spectacular. He takes a running start, swings, and ships an entire dashboard in a single sprint. The demo goes great. Stakeholders cheer.
Then a user tries to finish a task with it.
The error message says “Error.” The Save button has no loading state, so people click it four times. The keyboard focus disappears halfway down the page. Happy’s drive went 400 yards, and his product is stuck three feet from the hole.
Users don’t experience your big launch. They experience the small moments at the end: the confirmation, the empty state, the thing that happens after they press the button. That’s the short game, and it’s where people actually finish.
Practicing the putts
So Happy practices. Not on a fancy course, but at the mini golf place, putting through the clown’s mouth for hours.
On a product team, his mini golf is the unglamorous stuff. He tabs through every form. He turns on a screen reader. He tests the error state, the loading state, the zero-results state, and the state where someone’s name has an apostrophe in it.
It’s not exciting work. But one day, the putts start dropping, and his features start feeling finished.
It’s all in the hips
Every good UX engineer has a Chubbs, the mentor who saw something in them early. Chubbs doesn’t fix Happy’s work for him. He teaches the fundamentals and lets Happy figure out how they apply.
“It’s all in the hips,” Chubbs would say, which on a product team translates roughly to: “Start with semantic HTML. The rest gets easier.”
Go to your happy place
Happy’s temper is legendary. A stakeholder moves the deadline, and he wants to fight. A reviewer leaves forty comments about spacing, and he wants to fight. The build breaks on a Friday afternoon, and he wants to fight the build.
He learns, eventually, to go to his happy place before replying to anyone. He takes a breath, closes Slack, and comes back to the problem when he can see it clearly. His code reviews get kinder. His decisions get better. Fewer people get punched, figuratively.
He’s doing it for someone
Happy didn’t take up golf for glory. He did it to save his grandmother’s house. And that shapes the way he works. When he builds, he pictures a real person on the other side of the screen, usually someone like his grandma.
So the text is big enough to read without glasses. The buttons are big enough to tap with an unsteady hand. The instructions are written in plain language. Nothing important hides behind a hover. If his grandma can finish the task, he figures, most people can.
What we’d learn from Happy
Happy would remind us that people with unconventional backgrounds can see what everyone else missed. He’d remind us that the big launch is the easy part, and that users judge a product by its short game. And he’d remind us to build for a real person we care about.
Also, to go to our happy place before replying to that comment about spacing.
This article is part of the Famous Fictional UX Engineers series.