When designing and developing a product, it doesn’t matter how much design thinking you believe your organization exhibits if your designs are based on assumptions. Sometimes there is no way around assumption-based decisions, but if assumptions are your go-to method for solving problems, you’re in trouble.

Sure, this seems obvious. Yet, so many companies have this assumption-based design process built in. Take user stories for example. When a team is trying to solve a user’s problem and is developing a new feature for that problem, how is the feature need conveyed? Is it conveyed as a problem needing to be solved, or is it conveyed as a feature solving the problem? If it’s the latter, that’s assumption-based design.

Suggesting a feature based on what you think will solve a user’s need is nothing more than guesswork. Instead, the feature suggestion should be vague, and the problem should be clear. If a user is struggling with updating their profile, suggesting a new feature that auto-completes profile information might sound like a genius solution. However, if that enhancement was arrived at by any other means than significant research, it is based on assumption. What if the problems with completing the profile lie in a user’s desire not to share information your organization requires? What if the problem lies in a bug with your software that prevents important profile instructions from displaying in some older browsers?

I could play the what if game all day, and that’s the point. Suggesting enhancements to your product using user stories that have already presumed to have solved the problem is a mistake. There are ways around this problem, though. Instead of the traditional user story, your organization might try using job stories. Your organization might try using a persona-based solution that requires you to research the problems based on how you’d like your persona to be reflected once they have been able to use your product properly.

Assumption-based design doesn’t just take place in user stories and feature requests, though. It rears its ugly head when a company first sets out to build a new product. It shows up when an executive mandates change for “business reasons.” Assumption-based design can find its way into your product via countless channels. It’s your job as someone who cares about users to recognize an assumption when you see it and suggest data instead. Suggest research. Suggest speaking with customers. Just don’t suggest that the assumption stand without backing.

Assumptions hurt users. They cost your organization money. They can sink you before you even get started. But they are so easy to avoid if you commit to avoiding them. It’s easy to spot an assumption by simply asking “How do you know?” If the answer is based on concrete research and actual contact with users, then it is not an assumption. If the answer is anything but, it’s probably a design based on assumption alone.