The decisions you make before writing any code do more to determine whether a product works than almost anything you do afterwards.
Most founders we meet have a good idea. Very few of them have a product problem that is really about the idea. What tends to go wrong is the gap between the idea and the experience of using it. The thing makes sense in the founder's head and not on the screen.
User experience is the discipline that closes that gap. It is not decoration and it is not a stage that happens after the build. It is a set of decisions about how people move through your product, what they understand, and how much effort you are asking of them. Here are the five that matter most before you start.
1. Know who you are building for, specifically
Small business owners is not a user. A bookkeeper at a six person plumbing firm who does invoicing on a Friday afternoon on her phone is a user. The difference matters, because the second description tells you something about the device, the moment, the interruption level and the tolerance for complexity. The first tells you nothing you can design against.
You do not need a research budget to do this well. Ten honest conversations with people who actually have the problem will change more about your product than a month of internal debate. Ask them what they do now, not what they want. People describe their workarounds accurately and their preferences badly.
2. Design for the one job that matters
Every product has a core job. Everything else is support. The most common failure we see in early products is a home screen that treats fifteen features as equally important, because the founder is proud of all fifteen and cannot bring themselves to rank them.
Ranking them is the work. If a new user can complete the one job your product exists to do within their first session, you have a product. If they have to find it among fourteen other options first, you have a feature list.
Simplicity here does not mean fewer capabilities. It means a clear hierarchy, so the important thing is obvious and everything else is available when someone goes looking for it.
3. Make navigation boring
Navigation is one of the few places in design where being unoriginal is a virtue. People arrive at your product carrying expectations built from every other product they use. Menus at the top or down the left. Back goes back. The logo returns you home. The primary action sits where they expect it.
Every time you break one of those conventions you spend some of the user's attention on learning your system instead of doing their task. Occasionally that is worth it. Usually it is not, and the novelty that looked distinctive in a mockup reads as confusing in use.
A simple test: can someone say out loud where they are and how they would get back? If they hesitate, the structure is not clear enough yet.
4. Be consistent inside the product
Consistency inside a product does the same job that brand consistency does outside it. When buttons look and behave the same way everywhere, when the same word always means the same thing, when spacing and type follow a pattern, people stop having to think about the interface and start thinking about their work.
This is also one of the cheapest things you can do for build speed. A team working from a shared set of components ships faster in month six than a team inventing each screen, because most of the screen is already decided. The consistency arrives as a byproduct of a decision you made for engineering reasons.
Pick your patterns early, write them down, and resist the small exceptions. Small exceptions are how design systems die.
5. Ship, watch, then change something
No product is right on launch. The useful question is not whether you got it right, but how quickly you will find out that you did not.
That means building in the ability to see what people actually do, before you need it. Where do they stop? Which step takes four times longer than you expected? What do they email you about? Watching five people use the thing without helping them is uncomfortable, and worth more than any survey.
Then change something. The teams that improve fastest are not the ones with the best first version. They are the ones with the shortest loop between noticing a problem and fixing it.
The advantage founders already have
None of this requires a large team or a research department. It requires a willingness to be specific about who you are serving, honest about what your product is for, conventional where convention helps, disciplined about patterns, and quick to respond to what you learn.
Founders who do those five things build products people understand. Products people understand get used, and products that get used are the only ones that get a second chance.