--- title: Why your app needs real users not just your mums opinion description: Friendly feedback from people you know can mislead you badly. Find out why real user testing matters and how to do it before your app goes live. image: https://weareaffective.com/hubfs/learning-centre-images/why-your-app-needs-real-users-not-just-your-mums-opinion.webp --- [Skip to content](https://weareaffective.com/learning-centre/why-your-app-needs-real-users-not-just-your-mums-opinion#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # Why your app needs real users not just your mums opinion Table of Contents You have been building something for months. You know every screen, every tap, every transition. Your mum has used it twice and told you it looks lovely. Your business partner thinks the onboarding is clear. Your flatmate said it felt pretty straightforward. And so you convince yourself the thing is ready, because everyone around you said so, and nobody wants to be the one who deflates the room. > Real users arrive with no context and no loyalty, which makes their first few seconds with your product the only opinion that matters. The problem is not that these people are wrong to be kind. The problem is that kindness and accurate feedback are two different things, and you have been collecting the first while telling yourself you have the second. Every product launch we have worked on has produced feedback that redirected the product in ways the internal team did not see coming. That is what happens when [real users arrive with no context](https://weareaffective.com/learning-centre/why-most-business-apps-fail-and-how-your-digital-business-can-avoid-the-same-fat), no loyalty, and no reason to be generous. Getting that input before launch rather than after is the difference between a redirect and a rebuild. ## Why People Close to You Cannot Give You Honest Feedback The people in your life who care about you are not able to give you useful product feedback, and it is not their fault. When someone who likes you sits down with something you built, their primary goal is not to evaluate the product honestly. Their goal, consciously or not, is to protect the relationship. Telling you your checkout flow is confusing feels like telling you your child is difficult. So they smooth it over. They say it was fine. They say it was actually quite good. This is how human social dynamics work. People soften criticism for people they care about. The feedback you get from friends and family will almost always skew warmer than the reality, and because you want to believe it, you will. There is a second problem beyond social warmth. The people close to you are also close to you specifically, which means they are probably not your target user. A founder building a fitness tracking app for recreational runners might ask their partner, who runs marathons, and their colleague, who does not run at all. Neither of these people will encounter the app the way a recreational runner will. The feedback is structurally wrong for the audience. ## The Insider Bias Problem: Knowing Too Much to See Clearly There is a second version of this problem that catches founders who do avoid asking their mum, and instead ask their team. The team built it. They know what every button does, why it is positioned where it is, and what the logic behind each flow is. That knowledge makes the product feel intuitive to them, because they are recalling decisions they made months ago. When we work with a team that believes their product feels unintuitive, the first question we ask is where that belief is coming from. Is it a feeling from people in the room? Is it analytics data? Is it user research? Each of these sources carries different risks of bias and needs different handling. A team member saying "[this flow feels clunky](https://weareaffective.com/learning-centre/why-do-some-apps-feel-smooth-while-mine-feels-clunky)" is not the same as a user who has never seen the product before saying the same thing, and treating those two observations as equivalent is where a lot of product decisions go wrong. People who know a product deeply find it intuitive because they already understand its logic. A new user approaching the same screens without that prior knowledge will have a completely different experience. Conflating the two perspectives means you build for the version of the user who already understands you, which is nobody who hasn't already been hired by you. ## Design that understands *your* users We build app experiences around real user behaviour, not assumptions. Research, psychology-driven design and technical specs that turn users into loyal advocates. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## What Familiar Feedback Actually Costs You Collecting feedback from the wrong people does not just leave you with a warm feeling and a mediocre product. It actively costs you, because it creates confidence that is not backed by evidence. You move faster because you believe the validation. You skip steps because nothing has flagged a problem yet. And then you launch. After launch, real users arrive. They do not know your vision. They do not know what a feature was meant to do. They tap around for a few seconds, feel confused or underwhelmed, and leave. They do not email you to explain why. They simply stop opening the app. According to [Business of Apps](https://www.businessofapps.com/insights/top-reasons-why-mobile-apps-fail-to-make-a-mark-in-the-market/), 42 per cent of apps fail because they were launched without prior market research. The silence that follows a failed launch can feel like indifference, but it is almost always information you did not collect early enough to use. > Collected from the wrong people, warm feedback creates confidence that is not backed by evidence, and that confidence costs you later. The cost is in the rework. Every assumption that goes untested before launch becomes a thing you fix afterwards, under more pressure, with less time, and usually at greater expense than if you had caught it early. The feedback loop that feels slow and inconvenient before launch is always faster and cheaper than the one that starts after users have already decided the product is not for them. Before launch, write down the three assumptions your product depends on most. These are the things that most need testing with real users, and the things most likely to be invisibilised by insider familiarity. ## The Spreadsheet That Looked Like Research A pre-launch founder in the football industry came to us with a colour-coded spreadsheet mapping competitor products. The goal was to combine several existing tools into one. The founder was visibly excited and pleased with the work. We started asking questions about prospective users: why would someone choose an all-in-one product over the specialised apps they already use? Does consolidation risk reducing each individual feature below the threshold of usefulness? The founder was deflated. Not because the questions were unfair, but because the spreadsheet could not answer any of them. It was an analysis of what competitors had built, not an investigation into what real users actually wanted. A founder can spend weeks building a detailed competitive map and still have no idea whether the product they are planning to build solves a problem anyone actually has. This pattern is common because a spreadsheet provides something user research does not: immediate, unchallenged validation of your existing position. Nothing in the spreadsheet argues back. Nothing in the spreadsheet says "I already use three apps and I do not want one". That only comes from [talking to real potential users](https://weareaffective.com/app-user-research), and there is a quiet fear underneath the reluctance to do that. If you run user research and the idea is wrong, you have to reckon with that. If you build a spreadsheet, nothing contradicts you. Our intention when we challenge founders on this is not to devalue what they have done. The competitive analysis is useful. It just needs the missing dimension that user insight adds. It does not replace what the founder built. It gives it a sharper and more complete edge. ## When Skipping User Research Costs More Than Doing It We worked on a dating app whose core premise was verified profiles and the elimination of bots. The client wanted to focus the early work on onboarding, and chose to skip discovery around the messaging component. That decision seemed reasonable at the time. Onboarding was where the verification logic lived, so it felt like the natural priority. What got built as a result was a generic [messaging feature that contradicted](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-) everything the verified onboarding had established. It allowed automated messages and fake-feeling interactions, which directly undermined the product's central promise. The onboarding told users this was a safe, real space. The messaging told them otherwise. The entire messaging section had to be rewritten, at a cost of approximately £15,000 in additional budget and two months of additional work. Skipping discovery around one component did not save the budget. It deferred the cost and added interest. The decision to skip the research felt pragmatic in the moment. Eighteen months later it looked like the most expensive decision on the project. If budget pressure is making you consider skipping research on a specific component, cost it the other way: what would a rewrite of that component cost if you get it wrong? That number is usually larger than the research you were thinking of cutting. ## What Real Users Notice That Nobody in the Room Did We worked on a [fitness social app built around](https://weareaffective.com/learning-centre/fitness-app-trends-2026-what-users-really-want-from-their-workout-apps) a map-based feature, showing users' real-time locations so they could find workout partners nearby. The internal team loved it. It was the product's central mechanic and everyone who had worked on it found it compelling. Then we ran research, and the picture shifted quickly. The research showed that a high proportion of the app's likely users would be female, which made precise real-time location sharing a security concern that the product team, building in a room of people who were not the primary target user, had not weighed heavily enough. The feature that felt exciting from the inside looked different from the outside. We redesigned the approach to use randomised location offsets, so users could see the rough area where a potential workout partner was, without broadcasting their exact position. They could review profiles and have a conversation before choosing to share their precise location. The core value of the feature stayed intact. The security risk did not. That is what real users notice. Not the things your team debated for weeks, but the things that never came up because nobody in the room was the right person to surface them. According to [Nielsen Norman Group](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/), testing with just five users uncovers around 85% of usability problems. The gaps are almost always there. The question is whether you find them before or after launch. 1. Recruit users who match your actual target audience, not people who happen to be available. 2. Give them a task to complete rather than asking them to evaluate the product generally. 3. Watch what they do, not just what they say. Behaviour and self-report often differ. 4. Note where they pause, hesitate, or double back, as those moments are the data. 5. Do this before you build the final version, not after. ## How to Run Basic User Testing Before Launch User testing does not have to be a formal research programme with a specialist lab and a six-week timeline. At its most basic, it is sitting five people who match your target audience in front of your product and watching what happens. You give them a task. You stay quiet. You observe where they slow down, where they tap something that does not work as expected, and where they give up entirely. The key is recruiting the right people. Testing with five users from your target audience will tell you more than testing with twenty people who happen to be available. The closer someone is to the person you are actually building for, the more useful their confusion and their fluency both become. #### What to watch for The moments that matter in a session are rarely the ones where users tell you something is wrong. They are the [moments of hesitation, the slight frown](https://weareaffective.com/learning-centre/how-to-read-a-user-session-recording-for-emotional-signal-rather-than-task-compl), the second tap on something that did not respond as expected. Ask users to talk through what they are thinking as they go, but do not interpret what they say in isolation from what they do. The two often diverge, and the behaviour is usually the more honest signal. #### When to test Test earlier than feels comfortable. A rough prototype with the core flows in place is enough. You do not need a finished product to learn whether the logic of your product makes sense to someone encountering it for the first time. Waiting until everything is polished before showing it to real users is one of the most consistent ways teams delay learning things they needed to know six months earlier. Run a short test with five real users on your core flow before you finalise any design decisions. The cost of a morning's worth of sessions is negligible against the cost of building the wrong thing with confidence. ## What to Do With the Feedback Once You Have It Collecting user feedback is only the first part. The harder part is deciding what to do with it, because not everything a user says is a design instruction, and not everything that surfaces in a session is a problem the product needs to solve. A useful frame is to separate what users say from what users do. If six out of eight participants hesitate at the same screen, that hesitation is telling you something real about that moment in the flow, regardless of whether any of them name it as a problem. If one participant expresses a strong preference that no one else shares, that is worth noting but probably not worth building around. - Group feedback by theme rather than by individual response. - Separate moments of confusion from moments of preference. Confusion is usually fixable. Preference is personal. - Prioritise issues that appear in the core flow over issues in secondary screens. - Bring findings back to the team as observations, not as verdicts. The research informs the decision, it does not make it. One thing we have found is that sharing findings with clients often produces immediate resonance. Everyone in the room is a user of products, so seeing a real person hesitate at a screen they thought was obvious lands differently than being told the screen tests poorly. The research creates shared understanding of the problem, which makes it considerably easier to align on the solution. Every product we have launched has come back from real users with feedback that took things in directions the internal team had not anticipated. That is the normal result of letting the audience into a conversation that, before that point, had only ever included people who already knew the answer. ## Conclusion Your mum is not your user. Your team is not your user. Your investor, your co-founder, and your most enthusiastic friend are not your users either. They all have reasons, conscious or not, to see what you have built through a lens that will not reflect the experience of someone arriving at your product cold, with no context and no loyalty to the outcome. The work of getting real feedback before launch is recruiting the right people, sitting them in front of an unfinished product, and watching what they do. It is hearing things you did not want to hear at a point when you can still change them. That discomfort is the thing that makes it useful. The football founder's spreadsheet was a real piece of work. The dating app's onboarding was genuinely strong. The fitness app's map feature was a compelling idea. None of that was wasted. It just needed the dimension that only real users can add, and the sooner you involve them, the less it costs to act on what they tell you. If you are approaching a launch and the only feedback you have collected is from people who like you, that is the one thing worth changing before anything else. [Let's talk about your product before it goes to market.](https://weareaffective.com/get-started) ## Frequently Asked Questions Why can't I just ask friends and family to test my app? People who care about you are motivated to protect your feelings, not to evaluate your product honestly. This means their feedback will almost always skew warmer than reality, which gives you a false sense that the product is ready when it may not be. What is wrong with asking my business partner or team to review the product? Your team built the product, so they already understand the logic behind every screen and every decision. This prior knowledge makes the product feel intuitive to them in a way it never will for a brand new user, meaning their assessment is structurally unreliable. What makes a real user's feedback so different from someone I know? Real users arrive with no context, no loyalty, and no reason to be generous with their opinions. Their first few seconds with your product reflect an experience your team or close contacts can never genuinely replicate. Does it matter if my testers are not in my target audience? Yes, it matters enormously. If you are building an app for recreational runners but you test it with a marathon runner or someone who does not run at all, the feedback is structurally mismatched to your actual audience. You need testers who reflect the people you are genuinely trying to serve. When is the right time to gather feedback from real users? The right time is before launch, not after. Getting genuine user input early means you can redirect the product without having to rebuild it from scratch, which is a far less costly outcome. How do I know whether feedback is coming from bias or genuine insight? It helps to identify the source clearly. Feedback from a team member, analytics data, and structured user research each carry different risks of bias and need to be handled differently. Treating a colleague's gut feeling as equivalent to an observation from an unfamiliar user is where many product decisions go wrong. Is it unkind to distrust the positive feedback I have received so far? Not at all. The people giving you warm feedback are not being dishonest, they are being human. Recognising the difference between kindness and accurate feedback is not a criticism of them, it is simply an acknowledgement that you need a different kind of input to make good product decisions. What should I do if my team genuinely believes the product feels unintuitive? Start by working out where that belief is actually coming from. A feeling shared in a team meeting is very different from a pattern emerging in real user research, and each source needs to be assessed on its own terms before you act on it. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.