Recently, I was in a room where I had to argue the product and business folks out of doing something novel. The familiar fintech pattern versus something new. I fought for familiar, and won, and I've been thinking about that room ever since.
Familiar means you ship something people already know how to use. The job gets done, and you earn no applause. It just works. Novel is the other bet: you do something nobody's done, it works, and you get one of the rarest compliments in product — someone copies you. A junior designer, or a PM, or someone on the business side, will tend to treat every new flow as a chance to break the norm. But the copy-worthy outcome doesn't happen as often as we'd like, and identifying the difference between the two is a skill.
A senior designer's job isn't to aim for familiar or novel. It's to know which win a surface can even pay out — and the copy-worthy one is rare, so most of the time the honest answer is the mundane one.
Here's where I think the difference lives, and two examples sold it for me.
For years, the demo lived behind a few clicks. A form to contact sales, then an invite, then a salesperson walking you through the product. Two companies went the other way — different directions, both opposite the norm.
The first was Mercury. They put a fully functional demo behind a plain link, no form. Go to demo.mercury.com and you land in a real dashboard, assume a real business, and can even move money, all in test mode. The second was Linear. They put a working dashboard demo on the landing page itself. In Linear, what looks like a screenshot of the product is the product.
So the way to know when novelty is warranted starts with one question: who owns the friction, and who gets rewarded for it.
Every convention has an owner and a beneficiary, and they're not always the same person. The hard part is that a convention rarely announces whose side it's on — it just looks like the way things are done. The senior skill is seeing past that: who actually benefits when the user carries the friction.
Take the sales example. The friction sits on the user, but the business is what benefits. Traditionally, companies don't want to show you the product — competitors might see it, or someone's OKR is growing the mailing list, so asking for contact details at every turn does its job. The user gets nothing back. Just friction.
So is removing friction the rule? I don't think so. Plenty of friction rewards the user and the business at once. The confirm-delete modal protects the user from a mistake they can't undo, and protects the business from a change it likely can't reverse either.
The test isn't only who benefits but whether the user's benefit is worth what they pay. Think about the password field that demands an uppercase, a number, a symbol, twelve characters. It's friction, and the user gets better security for it. But it also locks people out, or pushes them onto a weaker password they can actually remember. We might be inclined to design a better password input component, but the security they gain today is marginal, and the lockout they pay for tomorrow is not.
So when do you choose the mundane vs the novel? Conform to conventions that serve the user and break the ones that serve the maker at the user's expense. Most people can't see who benefits, and the instinct to stand out is usually the maker wanting applause on a surface that was only ever meant to disappear.