It’s plain and simple. Your users don’t see the product like you do. They have a problem that needs to be solved, and all you have is one possible solution. How that solution is presented to them and functions is almost more important than the problem it solves.
You have to ask yourself questions like:
Is it easy to use? If not, do you have sufficient tutorials and/or documentation in place to support them?
Is it fast and snappy? If not, how can you keep the user engaged while something loads/processes?
Do you understand the technical capabilities of your users? Can they “figure things out” if it doesn’t work perfectly? Apple has this nailed better than anyone else (and they have the valuation to prove it). They understand that the vast majority of users just want it to work. They don’t want to spend time tinkering with settings and getting it just the way they like it. They just want it to work. Sure, you could argue that people are now just used to the way Apple products are configured, but how do you think they got the majority share in the first place? They hired some of the most talented product and engineering people in the world to figure out how to build a simple and intuitive user interface.
What about your own users? B2C software is tough. Consumers are notoriously picky and will quickly move to the next thing if it doesn’t work right. If you are building B2B SaaS, it can be a bit easier, as business people are a bit more forgiving (mostly). At the very least, you usually have a sales, customer success, or support person that can help smooth over the rough edges and buy you time to fix it. These are just two of many markets, but I think one of the best case scenarios is if you are building a tool for developers. They are more understanding when something is broken, and honestly might even help you fix it.
Just avoid building anything for test engineers. They find all the problems, even the ones you said weren’t possible.
— Me (a former software test engineer)
Seeing things the way a user sees them is one of the hardest things to do as an engineer, especially early on in your career. You are often more excited about doing cool things with code or getting lost on a new technical challenge, than building a product. Couple that with a lack of experience building at scale, and you will have quality problems. But that’s a post for another day. You have to pull your head out of the code and forget about “how hard that will be to build”. Though I would also argue that if it is hard to build, it might actually be hard to use. Often, intuitive designs are intuitive to build. If something feels clunky or weird, that’s probably because it is.
Truly understanding how your users will use your product to solve their problem is extremely important, but if it is hard to use or understand, it doesn’t really matter how well it solves the problem. There are numerous frameworks out there to tackle/track these issues: Jobs to be Done, Definition of Done, Spotlight, Net Promoter Score (NPS), ACAF Feedback Loop, etc. That’s just from memory and the first page of Google for “customer feedback framework”. Honestly, ChatGPT could probably come up with an even better answer. But the most important part of any framework is actually talking to your customers and listening to the problem(s) they need solved.
Even after you’ve gathered all of that data, you still may build something the customer doesn’t understand. That’s because you didn’t evaluate the technical acumen of your customer. For my current job in web3, the customer base seems to skew more towards the technical side. Part of that comes down to it still being a bit niche I think, but also because building on blockchain technology is more technical by nature. This doesn’t mean we’ve slacked on the user experience though, because it’s still immensely important (if that hasn’t been clear enough yet). We still want the interface to be intuitive, because so many web3 experiences are still clunky (have you used Etherscan?), and people have been seemingly okay with that. We want to bring more people into the web3 ecosystem, so in this way, we actually are planning more for the less technical users.
At this stage, intuitive software is required for the everyday consumer. That’s the baseline. Gone are the days where you could get away with clunky navigation, overloaded dropdown buttons, and blue hyperlinks everywhere (I’ll just leave this here, Web Design Museum). The users deserve a quality experience when using your software. It is up to you to ensure you take a step back and try to see it through their eyes.