Founder's Guide: Rules for Product Design
I just got back from a week-long ski trip to Zermatt, a ski town in the alps. It was absolutely incredible — the trails were insanely long, the views were gorgeous, and the conditions were just way better than anything you can get on the ice coast.
Still, I had some gripes. I'm a pretty good skier, and I can ski basically the whole mountain, but I was with a bunch of folks who were pretty new to the sport. And for them, the way the mountain was designed was really hard to work with.
There were a bunch of places where you would start on an easier run only to be forced onto a harder run with no other way out. Or places where you would end up in a totally different part of the mountain with no way back to your starting point. The mountain doesn't really "connect", so you can lock yourself out of paths down to the bottom by accident very easily. And it's very difficult to know what parts of the trail map are uphill or downhill. Trails were marked with difficulty levels that didn't really make sense — some supposedly easy trails were actually quite hard. And there was basically no 'easy' marked path to get back down to the bottom on any of the mountains.
In other words, the "UX" of the mountain was, like, really bad.
In my opinion, ski resorts that are 'well designed' generally follow two rules:
If you're on a run at a certain difficulty, there's always a way down the mountain at the same difficulty or easier;
Every run has a way to get back to the top of that run from the bottom, unless it's explicitly marked as a traverse.
These rules are useful because they avoid unexpected outcomes for a skier. Even if you're not paying attention, you won't end up on a triple black diamond on the opposite side of the mountain by accident. That, in turn, makes navigating the mountain much easier, and much more intuitive.
When people hear 'UX' they think about tech and tech products — things like button placement and font size and so on. But UX shows up everywhere: tables, chairs, door handles, appliances, road grids, railroad stations, video games, cars, apis… In some trivial sense, anything that any 'user' interacts with has an associated 'user experience', and often it's someone's job to care about what that experience is.
A lot of people have spent a lot of time arguing about what is or isn't good UX. To me, it's pretty straightforward: good UX is setting and meeting user expectations. Or, put another way, good UX is minimizing surprise. If a product tells the user — either explicitly or implicitly — how to use it, and then it more or less does what the user expects it to do, it's a well designed product. The key phrase to chase is "it just works".
UX is omnipresent in product experiences. You need to assume that every single interaction a user has with a product is going to set some kind of expectation, regardless of whether it's intended. Humans are just really good at pattern matching, and they pick up on patterns with very few examples. This is good, because if you are thoughtful you can create really smooth products. But it's bad, because you have to be really really thoughtful.
Frustrating product experiences do a bad job of minimizing surprise. They set user expectations, and then break them, often by accident. Bugs are the most obvious example of this — you go to login to Facebook and are greeted with a 503 error page, or maybe you sit in your desk chair only to have it collapse underneath you. It's not intentional, but it's definitely not a good experience. I get unreasonably mad at my apartment because every pull door has a handle and every push door is flat except one. I don't think the architects were being malicious, maybe there's a security reason they had to have a pull door instead of a push door, but that doesn't stop me from slamming my head every time I need to leave the house.
Sometimes, product experiences don't do a good enough job setting expectations to begin with. All users come into a product with some preconceived ideas about how the world ought to work. If your product is doing something meaningfully different, it is up to you to help the user reorient. Overall I'm a big fan of substack, but what is the difference between follow and subscribe??? Everyone assumes these are the same thing! Having two different things makes the whole experience way more confusing!
A quick tangent: I really don't like voice controls, because I think they fail on both counts. They make promises that can't be kept, and often intentionally (the voice agent that does everything is a great sci fi trope and sells a lot of hardware. It's a tale as old as time. The marketing departments are happy to run with blatant lies even as the tech team begs them not to.) don't do enough to set user expectations. Keyboard commands, control schemes, traditional UIs with buttons and menus and popups — these constrain the possible input space, implicitly letting the user know what's possible by their mere existence. That constraint is good, because it sets expectation appropriately. Voice control schemes promise unlimited flexibility, but they are almost always secretly restricted by a set of words that the system can actually understand. Having Siri or Alexa misunderstand what you want or do the wrong thing is always incredibly jarring for this reason. Voice UX is getting better thanks to AI agents and better voice recognition, but I'm still generally bearish on the entire concept. If I could misuse a term, it's "NP-hard" — a good voice system is capable of understanding and executing on the full range of language semantics.
Good products avoid both of these pitfalls. They communicate to the user with smart onboarding and intuitive controls, they leverage existing patterns that users are familiar with, and they make the easiest thing the right thing. The result is a user experience where someone tries something without looking up whether it's possible, and "it just works".
I think that if you keep "minimize surprise" at the forefront, you can get pretty far with just first principles thinking. But just in case, here's a list of non-exhaustive design principles that have helped me build complicated but intuitive software products.
Choose boring UX. Pulled from the famous "choose boring technology" blog post. Same concept.
Unless it's core to your product, don't reinvent visual language. Icons for different actions or UI patterns can be lifted wholesale from popular applications. Onboarding is significantly easier when you don't have to explain that a certain blob or squiggle means "save file" (just use the floppy disk icon!)
Unless it's core to your product, don't reinvent control schemes. Basically everyone on the planet understands that left click means "select whatever is under the mouse", if you change that you're asking for frustration.
Related: think about what icons/language your target audience will be familiar with. Leverage that as shortcuts. The smaller your target audience, the more specific you can be.
Steal UX shamelessly from competitors. If you're targeting the same audience, odds are your users will have learned patterns that they are attached to and don't want to relearn for a new tool.
Every interaction with your product is going to set some kind of expectation, whether you want it to or not. Better to plan for it than to hide from it.
Every interaction with your marketing is going to set some kind of expectation, whether you want it to or not. I'm not going to say "always be really conservative with your messaging" or something like that. But I will say that you need to balance top of funnel growth with user experience judiciously.
Make it easy for users to find more information about things that are unclear. Many users are already trained to hover for tooltips. Don't be afraid to have a big help button on your page.
Your users may not have the same assumptions that you do. Try and see your product from the perspective of someone who didn't build the thing. Look for user patterns that depend on knowledge about how the application was built, and eliminate them.
Menu hierarchies create surprise. "Why is the image width setting under edit→page→dimensions instead of image→size?" Etc. Minimize menus. Build in search tools for menu settings.
If two things behave differently in edge cases, they should be clearly delineated as different things even if they mostly behave similarly. Use different colors, shapes, and text to clearly demarcate them.
Related: reducing clutter is good because it helps users build a mental model of the product. But combining things that are actually different just to reduce clutter will actually complicate the user's mental model. Only combine things when you know they are the same.
If you have things in your application that require additional explanation to learn how to use, you need an onboarding flow. Even if it's something simple like flashing an image on the screen. A lot of games will just overlay game controls and UI element descriptors during loading screens and pause menus.
Write docs. Package them with your tool. Make them searchable.
You don't need to introduce all of your features at once. For complicated applications, consider gating "power user" features behind UI elements.
Anything in your application that requires additional explanation will likely be misused by some users. Proactively warn users when they fall into predictable antipatterns.
If a certain user flow has a single "correct" or "desired" next action, take the action for the user instead of waiting for them to do it. Many products will auto-submit when a user enters 6 digit 2fa codes.
Related: make sure that there is only a single next action when you do this! It is incredibly frustrating when tools do unexpected things on their own.
Changes to existing UX flows are more costly than creating new UX flows. All your users have to learn new patterns AND they also have to forget old ones. In an ideal world, changes to UX would come with their own "onboarding" flows indicating what has changed.
Delight comes from flourish, not fundamentals. Animate your hover effects, use stylized transitions, create beautiful branding. Express yourself in the parts of the UX that don't matter to the functionality of the product.
There are a lot of ways to minimize surprise. Most of them don't need to involve your product at all. You can always just, like, call up your users on the phone and tell them what to expect directly.
These rules are not ironclad, they are more like general guidelines, and following all of them to the letter is probably going to be weird and contradictory. And, like, this series is called "founder's guide" so at the end of the day, if you're a founder working on a small business, you probably can't afford to do full onboarding suites for every version change.
But the underlying principle remains. Minimize surprise. If you build an intuition for how you implicitly set expectations in your business, you can make explicit changes to improve the overall UX and build something people love.