I'm really curious about how others manage the disconnect between what clients believe their users want and what those users actually do. We primarily create web products for small businesses, like booking systems and customer portals. The issue I often encounter is that clients come in with a specific vision regarding their needs—often with lists or even wireframes in hand. However, when we build these products and observe actual user behavior, there's usually a significant mismatch. For instance, a recent client insisted on a complex filtering system, but we found that users rarely engaged with it, opting instead for a basic search bar. Despite investing around 40 hours into developing this feature, it was barely used. I've tried strategies like having clients share real conversations with their users, analyzing existing data, and conducting short interviews before finalizing requirements. While these approaches have had some success, I still feel like we're often building based on the founders' assumptions rather than actual user behavior. Is this just part of doing client work, or is there a method to identify these issues earlier? I'd love to hear if anyone has found an effective requirements process that addresses this before we waste hours on unnecessary features.
1 Answer
I totally relate to this! Working with gym owners, I often encounter the same scenario—clients push for complex booking features when, in reality, most customers just want to reserve a few popular classes. What’s really helped me is requiring clients to conduct user observation for two weeks before we even start. They track how their customers behave, which usually surprises them and shows how off-base their assumptions are. I've also learned to resist 'feature creep' by advocating for a simpler version at first and only adding complexity once we have real usage data, which has saved us so much time.
I, too, struggle with how to pitch the observation homework as part of the process without making it feel like a delay. But the truth is, seeing real user interaction is usually the wake-up call they need.
That two-week observation homework is genius! I'm definitely going to implement that. It's astounding how often clients come in convinced they know their users, yet their assumptions are so off. I've also found that those who resist starting with a simpler version often struggle with low engagement later on. Have you figured out how to present the observation task in a way that doesn’t feel like you're slowing down the project?