Design is a hypothesis

It's easy to get stuck as a software team (and wider organization) on design discussions: "Is this icon the right one?" for example can start such a difficult discussion. What is right and what wrong in this context? And who decides about this? The product designer, the most experienced person, or even management?

On one side, design has a rich history of research and best practices, but they are all tied to specific use cases. The golden ratio works better for a printed book than a website. And you might even wonder what "works" would mean for a website. Design has a strong opinion about how the world should be.

But on the other hand, you have real users of your software or website. They might be under stress, they might look at your website only superficially, they might have one specific need.

Users have goals and do actions that often will not match your ideal assumptions.

Hence, even your best-practice design choices should be considered hypotheses. And you can only test them with the real users of your product. So instead of thinking "What is the right icon?" you as a team should think "How can I find out what the user accepts as the right icon to solve her job?".

You will need to find different solutions based on the size of your audience. If you have a website with only a handful of visitors, you need to talk to them directly somehow and observe how they use your service. If you have a lot of traffic, make AB tests from your design assumptions (and only them, that's the art of focused tests) and test them in the wild.

There is no shortcut to find out what works. You need to shift your perspective from "How can we design it right from the start?" to "How can I learn as quickly as possible how my users interact with my page and prove or disprove my assumptions?".