I was staring at my laptop screen, watching a user session recording that was about to change everything I thought I knew about mobile design. The user had just downloaded the trading app I'd spent eight months designing. They opened it, looked at the home screen for exactly 4.2 seconds, and closed it. Forever. This wasn't just any user – this was someone who'd specifically requested early access because they were "excited to try professional mobile trading." They wanted to use this thing. They'd even paid for premium access. But we'd lost them in less time than it takes to tie your shoes. That moment broke something in me. Not just professionally, but personally. I'd poured my heart into this project, worked weekends, skipped family dinners, argued with developers about pixel-perfect implementations. And for what? So someone could take one look and decide it wasn't worth their time? Three years later, I only work with one type of mobile client. The ones who understand that mobile isn't just desktop with smaller buttons. Here's how I learned to spot the disasters before they destroy you, what it cost me in the process, and why saying no to 80% of mobile work saved my career and probably my sanity. The Warning Signs I Wish I'd Recognized Earlier I can predict project failure within the first fifteen minutes of a discovery call now. It's become this depressing superpower – like being able to smell rain three days out, except the storm is months of wasted work and disappointed users. "We want it to work exactly like our web version, but mobile." "We want it to work exactly like our web version, but mobile." The first time someone said this to me, I thought, "Challenge accepted!" I was going to be the designer who figured out how to make complex desktop workflows elegant on mobile. I was an idiot. This phrase translates to: "We think our users' problems change when they switch devices, but our solutions shouldn't." They've never watched someone try to fill out a 12-field form while standing on a subway platform. "Our power users need access to everything immediately." "Our power users need access to everything immediately." I fell for this one hard with a project management tool. "Our users manage million-dollar construction projects," the client said. "They can't afford to miss anything." So we put everything on the home screen. Project timelines, budget tracking, team communications, document sharing, change orders, safety reports. It was like trying to fit a filing cabinet onto a Post-it note. The "power users" took one look and went back to making phone calls. "We're different – our users actually prefer complexity." "We're different – our users actually prefer complexity." This is the lie every client tells themselves to justify bad design decisions. I believed it for years. "Enterprise users are sophisticated," I'd tell myself. "They can handle interface complexity." Turns out sophisticated users hate complexity more than anyone else. They have actual work to do. "Can we make it like Uber for [something completely unrelated to transportation]?" "Can we make it like Uber for [something completely unrelated to transportation]?" Translation: "I want the success of a ruthlessly focused app, but with all the feature bloat of my existing business model." I once had a client ask for "Uber for legal services." They wanted one-tap lawyer summoning, but also contract management, billing integration, document storage, case tracking, and client communications. When I explained that Uber works because it does exactly one thing, they looked at me like I'd suggested removing the steering wheel from their car. The Project That Nearly Destroyed My Faith in Mobile Design Two years ago, a fintech startup hired me to design their mobile trading platform. The founder was brilliant, the funding was solid, and they said all the right things about user-centered design. hired me to design "Simple and elegant," they kept saying. "Like Robinhood, but for serious traders." That sentence should have made me run. "Simple" and "serious trading" are fundamentally incompatible on a 5-inch screen. But the money was good, and I was convinced I could solve it. I was going to be the designer who finally cracked the code on mobile financial interfaces. Eight months later, I'd designed something that looked like Bloomberg Terminal had a baby with a smartphone. Real-time market data streaming across multiple layouts. Interactive charts with zoom and overlay indicators. Portfolio analytics with drill-down capabilities. Options trading interfaces. Futures contracts. Currency exchange. In Figma, it was a masterpiece. Clean typography, sophisticated color coding, elegant micro-interactions. My portfolio was going to look incredible. In beta testing, it was a disaster. "I opened it and immediately felt stressed," one user told us. "There's just... so much happening." "I tried to buy 100 shares of Apple and accidentally placed an options order," said another. "Closed the app and did it on my laptop instead." My personal favorite: "This crashed my phone twice. How is that even possible?" But here's what haunts me: the internal stakeholders loved it. The CEO called it "revolutionary." The head of product said it was "everything we dreamed of." We'd designed for the people signing the checks, not the humans who'd actually use it while grabbing coffee between meetings. The app launched to 1.2-star reviews and was pulled from both app stores within six months. The startup folded eight months later. But not before I'd spent most of a year of my life, missed my nephew's first birthday party working on "urgent revisions," and started having panic attacks every time I opened the App Store. The Brutal Truth About Mobile Context That failure forced me to confront something I'd been ignoring: mobile usage is fundamentally different from desktop usage, and pretending otherwise destroys products. I started obsessively studying mobile analytics from every project I'd worked on. The data was humbling: 67% of mobile sessions lasted under 90 seconds
Users abandoned tasks if they required more than 3 taps to complete
73% of form fields with more than 5 inputs never got completed
Apps with more than 7 primary navigation items had 40% lower retention rates 67% of mobile sessions lasted under 90 seconds Users abandoned tasks if they required more than 3 taps to complete 73% of form fields with more than 5 inputs never got completed Apps with more than 7 primary navigation items had 40% lower retention rates But the real revelation came from watching session recordings. Not highlight reels from usability tests, but raw footage of people actually using mobile apps in their natural habitat. They use them while walking. While waiting for elevators. While their toddler is having a meltdown in Target. With one hand, in bright sunlight, with notifications constantly interrupting their flow. Desktop users sit down with intention. Mobile users grab their phones during micro-moments of availability and opportunity. This isn't a constraint to overcome – it's the entire point of mobile design. The Criteria That Saved My Career After the fintech disaster, I developed a scoring system for mobile projects. I only work with clients who score at least 8/10 on these criteria: Purpose Clarity (0-3 points) Can they explain what their app does in one sentence without buzzwords? Purpose Clarity (0-3 points) 3 points: "Helps parents track their kids' soccer schedules"
1 point: "Comprehensive family lifestyle management solution"
0 points: "Platform for optimizing household operational efficiency" 3 points: "Helps parents track their kids' soccer schedules" 1 point: "Comprehensive family lifestyle management solution" 0 points: "Platform for optimizing household operational efficiency" Context Understanding (0-2 points) Do they know when and where people will actually use their app? Context Understanding (0-2 points) 2 points: "While walking between meetings to check if their Uber arrived"
1 point: "During work hours when they need productivity tools"
0 points: "Whenever they want to access our platform" 2 points: "While walking between meetings to check if their Uber arrived" 1 point: "During work hours when they need productivity tools" 0 points: "Whenever they want to access our platform" Prioritization Willingness (0-2 points) Are they excited about removing features or terrified of it? Prioritization Willingness (0-2 points) 2 points: "We want to do three things perfectly"
1 point: "We could probably simplify some areas"
0 points: "Everything is equally important" 2 points: "We want to do three things perfectly" 1 point: "We could probably simplify some areas" 0 points: "Everything is equally important" Mobile-First Thinking (0-3 points) Do they understand mobile capabilities or just mobile constraints? Mobile-First Thinking (0-3 points) 3 points: "We want to use the camera for instant document capture"
2 points: "We'll need to rethink our desktop workflows for mobile"
1 point: "We want our website to work on phones"
0 points: "We need all our features accessible on mobile" 3 points: "We want to use the camera for instant document capture" 2 points: "We'll need to rethink our desktop workflows for mobile" 1 point: "We want our website to work on phones" 0 points: "We need all our features accessible on mobile" Clients who score below 8 get politely declined. It's not personal – it's survival. What's Actually Worth Building The mobile projects that genuinely improve people's lives have specific characteristics you can identify early: They solve problems that happen in mobile contexts. The best mobile app I ever designed was for restaurant reservations. People use it when they're already out, hungry, and need a table in 30 minutes. Perfect mobile moment. They solve problems that happen in mobile contexts. They leverage mobile superpowers. GPS for location-aware features. Camera for instant document capture. Push notifications for time-sensitive information. Biometric authentication for security. These aren't afterthoughts – they're core functionality. They leverage mobile superpowers. They start stupidly simple. I mean embarrassingly simple. New users should accomplish something valuable in under 30 seconds without any learning curve whatsoever. They start stupidly simple. They become invisible habits. The apps people genuinely rely on solve small problems consistently rather than big problems occasionally. They become invisible habits. The Questions That Reveal Everything I've learned to ask specific questions that instantly separate viable mobile projects from disasters waiting to happen: Walk me through exactly when someone would use your app. Not just where they are, but what they're doing, how they're feeling, what just happened that made them reach for their phone. Walk me through exactly when someone would use your app. Not just where they are, but what they're doing, how they're feeling, what just happened that made them reach for their phone. Good clients paint vivid pictures: "They're standing in line at Starbucks, remembered they need to split last night's dinner bill with their roommate, and want to handle it before they forget again." Bad clients give vague answers: "They'd use it whenever they need to manage their finances." "What will people accomplish in their first 15 seconds with your app?" "What will people accomplish in their first 15 seconds with your app?" Good answers are specific and valuable: "They'll see if their delivery driver is nearby and get an accurate arrival time." Bad answers are process-focused: "They'll create an account and begin exploring our features." "What are you most excited to exclude from the mobile experience?" "What are you most excited to exclude from the mobile experience?" The best clients light up at this question. They've been thinking about focus and can't wait to cut unnecessary complexity. The worst clients get defensive. They consider exclusion a failure of imagination rather than a design necessity. The Personal Cost of Bad Projects Here's what no one talks about in design articles: working on doomed mobile projects doesn't just waste time. It damages you. I spent eighteen months on projects that launched to terrible reviews and low adoption. Eighteen months of my life building things that made people's days slightly worse instead of better. I started dreading user research sessions. I'd watch people struggle with interfaces I'd designed, and instead of learning from it, I'd make excuses. "They just need more time to learn it." "Power users will appreciate the depth." I was lying to myself and everyone around me. My confidence crumbled. I started second-guessing every design decision. Maybe I wasn't cut out for this. Maybe I should pivot to web design or go back to school or learn to code. My relationship with my partner suffered. I'd work late trying to "fix" unfixable projects, miss dinners, cancel weekend plans. I was stressed, irritable, and couldn't explain why work that should have been exciting felt like trudging through quicksand. The fintech failure was my rock bottom. Watching something I'd poured my heart into get torn apart in the App Store reviews was genuinely traumatic. But it also forced me to confront the truth: I'd been accepting projects based on money and ego instead of likelihood of success. What Changed When I Got Ruthlessly Selective Everything. The apps I design now actually get used. Not just downloaded – actively used, regularly, by people who recommend them to friends. My client relationships transformed. Instead of explaining why their requests won't work, I'm collaborating on solutions that leverage mobile strengths. Instead of managing expectations down, I'm helping exceed them. Projects finish on time and under budget because we're solving mobile problems with mobile solutions instead of forcing desktop solutions into mobile constraints. My rates doubled because I became known for mobile apps that succeed instead of mobile apps that exist. But the biggest change was personal. I love this work again. I'm excited to show people what I'm building instead of dreading their reactions. The Mobile Projects Worth Doing After three years of ruthless selectivity, here's what I've learned about mobile projects that actually matter: They solve urgent, frequent problems. Checking if your train is delayed. Splitting a restaurant bill. Finding your parked car. Calling an Uber after a late meeting. These aren't sophisticated use cases – they're human moments where mobile makes life measurably better. They solve urgent, frequent problems. They use mobile capabilities as primary features. Voice input for hands-free interaction. Camera recognition for instant data capture. Location awareness for context-appropriate functionality. These aren't nice-to-have additions – they're the reason the mobile version exists. They use mobile capabilities as primary features. They become part of people's routines. The most successful mobile apps I've designed integrate into daily habits so seamlessly that people don't think of them as apps – they think of them as tools for living. They become part of people's routines. Why I'm Sharing This If you're considering a mobile project – whether you're hiring a designer or building something yourself – here's what I want you to understand: Most mobile projects fail not because they're poorly executed, but because they shouldn't exist in the first place. They're solving desktop problems with mobile constraints, or trying to replicate web experiences in contexts where they don't make sense. Most mobile projects fail not because they're poorly executed, but because they shouldn't exist in the first place. They're solving desktop problems with mobile constraints, or trying to replicate web experiences in contexts where they don't make sense. But when mobile projects are built on correct assumptions – when they leverage what phones do uniquely well instead of fighting what they don't do well – they can genuinely transform how people accomplish important tasks. The difference between building something people tolerate and something people genuinely rely on comes down to understanding that mobile isn't just another screen size. It's a different relationship with technology entirely. That's why I only work with one type of mobile client now: the ones who want to build something that belongs on mobile, not something that merely fits. The others can find someone else to design their digital Swiss Army knives. I'm busy making apps that solve real problems in real moments – apps that people actually open more than once. That's the only mobile work worth doing. And honestly? It's the only mobile work worth paying for.

Apple

Starbucks

Robinhood

The Button That Teaches People to Stop Paying Attention

Work

UX\UX Agency London

Read My Stories

UI/UX Design Services

Digital Product Design Services

Free Discovery Call with Me

Too Long; Didn't Read

Make resilience your competitive advantage

Why I Only Design Mobile Apps for One Type of Client Now

Why I Only Design Mobile Apps for One Type of Client Now

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

The Button That Teaches People to Stop Paying Attention

Mobile APP failure: TOP 6 reasons why it happens

The 💩 Poop Emoji's 10th Anniversary

10 Year Challenge — How Popular Websites Have Changed In China.

10 ways how designing a chat bot is different from designing an app

The Button That Teaches People to Stop Paying Attention

Mobile APP failure: TOP 6 reasons why it happens

The 💩 Poop Emoji's 10th Anniversary

10 Year Challenge — How Popular Websites Have Changed In China.

10 ways how designing a chat bot is different from designing an app

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps