What Research Should I Do Before Designing My App?

You have this brilliant app idea that's been bouncing around your head for weeks. Maybe months. You're convinced its going to change everything—or at least make peoples lives a bit easier. So naturally, you want to jump straight into designing screens and picking colours and fonts. I mean, why wouldn't you? The exciting stuff is the visual bits, right?

But here's what I've learned after building apps for countless clients over the years: rushing into design without proper research is like trying to build a house without checking if the ground can actually support it. Sure, you might get something that looks good on the surface, but underneath? That's where the problems start to show.

The apps that succeed—the ones that people actually use and love—are built on a foundation of solid research. Not the boring, academic kind of research that puts you to sleep. I'm talking about practical, actionable insights that tell you what your users really need, what your competitors are doing wrong, and how you can build something that stands out in an incredibly crowded marketplace.

Good design is obvious. Great design is transparent.

This guide will walk you through the exact research process I use with my clients before we design a single screen. We'll cover everything from understanding your users' real problems to figuring out your monetisation strategy. Because honestly? Getting this stuff right at the beginning saves you months of headaches—and thousands of pounds—later on. Trust me on this one.

Right, let's talk about the most important part of your app research—understanding who's actually going to use the thing. I've seen countless projects where brilliant developers built exactly what they thought users wanted, only to discover they'd got it completely wrong. It's heartbreaking, honestly.

The mistake most people make? They assume they are their target user. But here's the reality—you're probably not. You're too close to the problem, you understand technology better than most people, and you definitely think differently about apps than someone who just wants to get stuff done quickly.

Start With Real Conversations

Before you sketch a single wireframe, you need to talk to real people who might use your app. Not your mates, not your family (they'll just tell you what you want to hear), but actual strangers who represent your target audience. I usually recommend chatting with at least 15-20 people to start spotting patterns.

Ask them about their current frustrations, not about your app idea. Find out how they solve the problem you're trying to address right now. What tools do they use? What drives them mad about existing solutions? Where do they give up and just accept that something is rubbish?

Watch How People Actually Behave

People lie in interviews—not on purpose, but they do. They'll tell you they'd definitely pay for premium features, then never actually do it. That's why observing behaviour matters more than listening to opinions. If possible, watch people use similar apps or go through the processes your app would replace. This type of contextual research and user observation reveals insights that traditional interviews simply can't uncover.

This research phase might feel slow when you're eager to start building, but trust me—it's the difference between creating something people actually want versus something that looks good in your portfolio but nobody downloads.

Analysing Your Competition

Right, let's talk about something that might make you feel a bit uncomfortable—studying what everyone else is doing. I know, I know, you want your app to be unique and special. But here's the thing: understanding your competition isn't about copying them; its about learning from their mistakes and finding gaps you can fill better.

When I start competitive analysis for a client, I'm not just looking at the obvious players. Sure, if you're building a fitness app, you'll want to check out the big names everyone knows about. But I also dig deeper—what about apps that solve similar problems in different ways? What about non-app solutions people are currently using? Sometimes your biggest competitor isn't another app at all.

Download and actually use your competitors apps for at least a week. Don't just browse through them once—live with them, understand their user flows, notice what frustrates you.

What to Look For

I focus on a few key areas when analysing competitors. First, their onboarding process—how do they introduce new users to the app? This is where most apps lose people, so pay close attention to what works and what doesn't. Second, their core features and how they present them. Which features do they put front and centre? What's buried in menus?

Look at their app store reviews too. Honestly, this is pure gold. Users will tell you exactly what they love and hate about existing solutions. I've found some of my best feature ideas just by reading what people wish an app could do differently.

• User interface patterns and navigation styles
• Pricing models and subscription tiers
• Marketing messages and positioning
• App store ratings and common complaints
• Update frequency and new feature releases
• Social media presence and user engagement

I'll be honest with you—most market research for mobile apps is complete rubbish. People spend weeks creating elaborate spreadsheets full of market size data and industry reports that tell them absolutely nothing about whether their specific app idea will work. After building apps for nearly a decade, I've learned that the research that actually matters is much simpler and more direct.

The first thing you need to understand is market timing. Is your app solving a problem that people are actively looking for solutions to right now? I've seen brilliant apps fail because they were too early, and mediocre apps succeed because they hit the market at exactly the right moment. Check Google Trends for search terms related to your app's core function; look at what questions people are asking on Reddit and Twitter. If nobody's talking about the problem you're solving, that's either a red flag or you've found something genuinely new.

Size Doesn't Always Matter

Forget about total addressable market calculations for now. What you really need to know is whether there are enough people who will pay for your specific solution. A niche market of 50,000 highly engaged users can be far more valuable than millions of casual users who won't spend a penny. I've worked on apps that targeted incredibly specific audiences—think left-handed golfers with back problems—and they were more successful than broad consumer apps because the users desperately needed what we built.

The research that moves the needle? Talk to potential users, check app store reviews of similar apps to see what people actually complain about, and understand the business models that work in your space. Everything else is just noise that stops you from building something people actually want.

Technical Research and Platform Decisions

Right, let's talk about the technical stuff—the decisions that'll shape how your app actually gets built. I've seen too many projects go sideways because someone made platform choices without doing their homework first. It's not the most exciting part of pre-design research, but bloody hell, it's important.

First up: iOS, Android, or both? This isn't just a "let's do everything" decision. Each platform has its own quirks, development costs, and user behaviours. iOS users tend to spend more money on apps, but Android has a much bigger global market share. Your target audience research should tell you where your users actually are. If you're building a business app for executives, iOS might be your priority. Gaming app for emerging markets? Android's probably your best bet.

Cross-Platform vs Native Development

Here's where things get interesting. Cross-platform tools like React Native and Flutter can save you money and time—you write once, deploy everywhere. Sounds perfect, right? Well, not always. Native development still gives you better performance and access to platform-specific features. I've had clients who went cross-platform to save money, then ended up rebuilding native anyway because the user experience wasn't quite right.

The best technical decision is the one that aligns with your timeline, budget, and user expectations—not the one that sounds most impressive

Don't forget about backend requirements either. Will you need real-time messaging? Heavy data processing? Cloud storage? These decisions affect everything from your development timeline to ongoing hosting costs. Research what your competitors are using, look at case studies from similar apps, and honestly assess your team's technical capabilities. There's no shame in starting simple—you can always scale up later when you've got users and revenue coming in.

Content Strategy and Information Architecture

Right, let's talk about something that most people completely skip over—figuring out what content your app actually needs and how its going to be organised. I mean, you wouldn't build a house without knowing where the rooms go, would you?

Content strategy isn't just about writing copy; it's about understanding every piece of information your app will handle and how users will interact with it. What data will users input? What information do they need to see first? How much text can you realistically fit on a mobile screen without making people squint?

Mapping Your Content Needs

Start by listing every single piece of content your app will need. And I mean everything—button labels, error messages, onboarding text, help documentation, legal pages. You know what? Half the apps I've worked on have crashed because someone forgot about edge cases like "what happens when there's no internet connection?"

Here's what you need to catalogue:

• User-generated content (posts, comments, profiles)
• System-generated content (notifications, confirmations)
• Static content (help pages, terms of service)
• Dynamic content (feeds, search results)
• Multimedia content (images, videos, audio)

Information Architecture That Makes Sense

Once you know what content you have, you need to organise it logically. This is where information architecture comes in—basically, creating a map of how everything connects. Users shouldn't have to think about where to find things; it should feel natural.

Test your structure with real people. Give them scenarios like "find the settings page" or "delete your account" and watch where they tap first. Their instincts will tell you more about good navigation than any design theory ever will. Trust me on this one.

Visual Design Research and Brand Alignment

Right, let's talk about something that makes or breaks first impressions—your app's visual design. I can't tell you how many times I've seen brilliant apps fail because they looked like they were designed in the early 2000s. Visual design research isn't just about making things pretty; its about understanding what your users expect, what your competitors are doing, and how your brand should show up in the mobile space.

First things first—you need to understand the visual language of your industry. If you're building a fintech app, users expect clean lines, plenty of white space, and colours that feel trustworthy. Blue and green dominate for a reason. But if you're creating a gaming app? All bets are off—vibrant colours, dynamic illustrations, and bold typography might be exactly what you need.

Brand Research That Actually Works

Before you even think about colour palettes, spend time researching how established brands in your space present themselves. Look at their websites, their apps, their marketing materials. What patterns do you notice? More importantly, where are the gaps you can fill with your own unique approach?

I always tell my clients to create what I call a "visual competitive analysis"—basically a mood board of your top 5 competitors' key screens. You'll start spotting trends quickly. Maybe everyone uses the same shade of blue for primary buttons, or perhaps there's a standard way of displaying pricing information. This research helps you decide whether to follow conventions (safer for user experience) or break them (riskier but potentially more memorable).

Create a simple brand mood board with 10-15 images that capture the feeling you want your app to evoke. Include competitor apps, but also pull inspiration from completely different industries—sometimes the best ideas come from unexpected places.

Typography and Iconography Research

Typography research is often overlooked, but it's genuinely important for mobile apps. You need fonts that work across different screen sizes and remain legible at small sizes. Research platform-specific guidelines too—iOS and Android have different approaches to typography, and fighting against these conventions usually creates more problems than it solves.

Icon research is equally important. Users have learned visual languages over years of app usage. A magnifying glass means search, three horizontal lines mean menu, and a heart means like or favourite. You can innovate, but understand the conventions first.

• Research colour psychology within your industry context
• Analyse successful apps' visual hierarchy and information density
• Study accessibility requirements and how they affect visual choices
• Investigate platform-specific design patterns and user expectations
• Examine how your brand translates from web to mobile contexts

Monetisation Research and Business Model Planning

Here's the thing most people get wrong about app monetisation—they think about it last. By the time they've built their beautiful app, they suddenly realise they need to make money from it. That's backwards thinking, and it's expensive backwards thinking at that.

I always tell my clients that monetisation isn't something you bolt on later; it needs to be baked into your app's DNA from day one. The way people pay for your app affects everything from user interface design to feature prioritisation. A subscription-based fitness app will have completely different onboarding flows compared to a one-time purchase productivity tool.

Common Monetisation Models

Let me break down the main ways apps make money, because understanding these will shape your entire development approach:

• Freemium: Free download with premium features locked behind a paywall
• Subscription: Monthly or yearly recurring payments for continued access
• In-app purchases: Buying additional content, features, or virtual goods
• Advertising: Revenue from displaying ads to users
• One-time purchase: Single upfront payment to download and own the app
• Transaction fees: Taking a percentage of transactions processed through your app

Research your target market's spending habits before picking a model. Business users might happily pay £50 monthly for productivity software, but asking teenagers for the same amount? Good luck with that. Look at successful apps in your category—what monetisation strategies work for them? More importantly, what are users actually complaining about in the reviews?

Pricing Research That Matters

Don't just guess at pricing. Study your competitors obsessively, but remember that cheaper isn't always better. Sometimes higher prices signal quality and exclusivity. Test different price points if possible, and always consider your customer acquisition costs when setting prices. There's no point charging £2.99 monthly if it costs you £15 to acquire each user!

Testing Your Assumptions Early

Here's the thing—every app idea is built on assumptions. You assume people want your solution; you assume they'll use it the way you envision; you assume they'll even understand what problem you're solving. I've watched brilliant developers spend months building features nobody wanted because they never tested these assumptions early on.

The good news? You don't need a fully built app to start testing. Actually, testing before you build saves you from making expensive mistakes later. I always tell my clients to think of this phase as cheap insurance against building the wrong thing.

Simple Ways to Test Early

Start with paper sketches or basic wireframes—show them to potential users and watch their reactions. Do they understand what each screen does? Can they figure out how to complete a task? Their confusion tells you more than any survey ever will.

Create a simple landing page describing your app idea and see if people sign up for updates. No signups? That's valuable data about market interest. Run small Facebook or Google ads to test different value propositions; see which messages resonate with your target audience.

The biggest risk isn't building the app wrong—it's building the wrong app entirely

Build quick prototypes using tools like Figma or even PowerPoint (honestly, it works!). Test one feature at a time rather than trying to validate everything at once. I've seen startups pivot their entire concept based on early user feedback, and they were grateful they discovered these issues before writing a single line of code.

Remember, early testing isn't about proving you're right—it's about discovering what you don't know yet. Every assumption you validate or disprove gets you closer to building something people actually want to use.

Right then, we've covered quite a bit of ground here—from understanding your users and scoping out the competition, to making technical decisions and planning your monetisation strategy. I know it might feel overwhelming at first, but honestly? This research phase is where the magic happens. Its where good apps separate themselves from the ones that disappear into obscurity after a few weeks.

The thing is, most people want to jump straight into design and development because that's the fun part. I get it, I really do. But every successful app I've built over the years has had one thing in common: proper research done upfront. Not just surface-level stuff, but deep, meaningful research that uncovers real insights about users, market gaps, and technical possibilities.

You don't need to spend months on research—that's overkill and you'll lose momentum. But you do need to be thorough enough to make informed decisions. When a client comes to me with a well-researched brief, the entire project runs smoother. We make fewer costly changes, the app resonates better with users, and launch day is far less stressful.

Here's what I want you to remember: research isn't just a box-ticking exercise. Its your roadmap for building something people actually want to use. Every hour you spend researching now saves you weeks of rework later. And more importantly, it dramatically increases your chances of creating an app that doesn't just get downloaded, but becomes a genuine part of your users daily lives.

So take your time with this phase. Do the work properly. Your future self will thank you for it.