Sevginur Ak Parlak
May 23, 2026
15 min read
Design New Features for a Mobile App Without Breaking It
Take a typical case: A team sends a Figma file with a new payments feature for their iOS and Android app. It looks good. It also uses a custom bottom sheet that does not match the 1 already in the app, a tab bar with a 6th item, and 1 state out of the 9 it needs. No offline state, and the app is used in the field. The mobile engineers spend 3 days rebuilding it in the real components, and the feature misses the release.
This is the most common way I see feature work go wrong in teams that ship a mobile app every 2 weeks. The feature is designed on a blank canvas, and the app it has to live in, with its navigation, its platform rules and its release train, is treated as background.
This post is how I design new features for a mobile app so they ship: how I scope a feature in 1 day, the platform patterns I check first, how I work inside your app design system, the rhythm with your mobile engineers around app store releases, and how long a feature takes at Studio Scale.
Why you cannot design new features for a mobile app in isolation
A mobile feature is never alone. It arrives into a tab bar with 4 or 5 slots, a navigation stack, a permission model, a set of components and 100 small conventions that users already learned with their thumbs. When I design a feature without those, I am designing a second app and asking the first app to absorb it.
The damage shows in 3 places. In the interface, a new pattern for the same job adds cognitive load. In the code, every component outside the app design system is built twice, once on iOS and once on Android. In the release, a feature that missed the train by 2 days waits 2 more weeks for the next 1.
The fix is to design from the app outward. I start every feature by installing the current build on my phone, not by opening Figma. If your app has a design system, that is my palette. If it does not, the existing screens are.
How I scope a mobile feature in 1 day
Most feature work starts with 1 line in a ticket: "users should be able to split a bill". That line is not a scope. My first day on any feature is turning it into 1, in 4 passes. If the team has not yet decided which feature to build, we start 1 step earlier, with the scoring in our post on feature prioritization for product teams.
The job
What is the user trying to finish, and where are they? Splitting a bill is not the job. Getting 3 friends to pay you back before you leave the restaurant is the job. That decides whether the feature is 1 screen or a share flow, and whether it needs contacts permission at all.
The entry points
Where does the user find this? 1 entry point in settings and 4 entry points across the home tab, a list row, a push notification and a deep link are different amounts of work and different amounts of adoption. I list every place the feature can start and where back returns the user to.
The states
Empty, loading, partial, success, error, no permission, offline, already done. A single mobile screen has 6 to 9 states, and the 1 state in the ticket is always the success state. I write the list before I draw anything because the engineers estimate against it.
The edge cases
Real data on a real device. The 90 character name on a 375 point wide screen, the list with 4,000 rows on a 3 year old Android phone, the keyboard covering the primary button. I get most of these from your support inbox, your crash reports and your engineers in 30 minutes.
By the end of day 1 you get a 1 page scope: job, entry points, state list, edge cases per platform, and an estimate in days. If the scope is bigger than the ticket assumed, better to find that out on day 1 than after the release is cut.
How I redesign 1 flow in 2 to 3 weeks
Run this on the ticket before you send it to a designer.
Write the job in 1 sentence starting with "the user needs to", and add where they are: at a desk, walking, in a shop, offline.
List every screen, notification or deep link where the feature could start.
Count the states. If you have fewer than 5, you are missing offline and no permission.
Find 3 real records that would stress the layout: longest name, largest count, oldest account.
Name the 1 metric you expect to move in 4 weeks after the release.
Decide what you will remove or hide to make room for it. The tab bar is full.
Platform patterns I check before drawing
Mobile app feature design starts with the platform, because the platform already made 80% of the interaction decisions. Fighting them takes engineering time and fails app store reviews.
Navigation
Does the feature live in a tab, a stack pushed from a list, or a modal flow that ends with done? The answer decides the back behaviour on Android and the swipe back on iOS, and it is the decision users notice most when it is wrong.
Sheets
Most apps already have 1 bottom sheet component. The new feature uses it, at the same detents, or it has a reason not to.
Permission prompts
Camera, contacts, location, notifications. Each 1 is asked once by the system, and a denied prompt is a state the feature lives with for months. I design the pre prompt that explains why, and the denied state with a path to settings.
Push notifications
If the feature sends any, I design the text, the deep link target and what the user sees if the content is gone. A notification that opens the home tab is a broken feature.
Offline
What is visible with no connection, what is queued, and what tells the user their action will sync.
Small screens
Every layout is tested at the smallest device the app supports, with the largest text size and the keyboard open. That is where most of my layout changes come from.
Designing inside an existing app design system
Around 80% of a typical mobile feature is built from components that already exist: list rows, sheets, forms, toasts, empty states, tab bar, navigation bar. My first job is to use them exactly as they are, including the spacing tokens, the type scale and the platform specific variants.
The remaining 20% is where the judgement is. Before I create a new component, I check whether an existing 1 can be extended with 1 variant, whether 2 components can be composed, and whether the new pattern will be used in 2 more places within 2 quarters. If not, I design the simplest version that works and mark it as local to the feature.
When I do add a component, I add it to your library properly: iOS and Android variants where they differ, states, tokens bound, naming that matches the code. We describe that setup in our post on a design system for startups. If your app has no design system yet, I build the feature from the existing screens, and the 5 to 10 components it touches become the first page of your library.
The rhythm with a mobile engineering team
A web team can deploy 5 times a day. A mobile team ships a release every 1 to 2 weeks, then waits for app store review, then waits for users to update. A design mistake that reaches the store lives in the app for at least 1 month. So I stay 1 release ahead of engineering and run design QA on the build before it is cut. This is the rhythm we run with app teams, async, in Figma, Slack and Loom.
Day 1
We agree the feature for the next release in a 30 minute call or a Slack thread. I share the 1 page scope by the end of the day.
Days 2 to 4
I design inside the system, on both platforms where they differ. Flows first, then screens, then states, in 1 Figma page named after the ticket.
Day 5
A 30 minute review with the iOS and Android engineers who will build it, not only the product owner. This is where I hear that the sheet library does not support a third detent or that the Android back stack will not do what I drew. Cheaper to hear now than in the pull request.
Day 6
Dev ready Figma with the state list checked off, final copy in place, and a 5 minute Loom. Engineering starts the next sprint with no open questions.
Before the release is cut
I install the TestFlight or internal Android build and go through the feature on 2 real devices, 1 small and 1 large, with the largest text size. I file the differences with screenshots, typically a list of 5 to 15 items, and the engineers fix them before the release. Design QA on the build is the step mobile teams skip most and regret most.
When to prototype and when to skip it
A prototype takes 1 to 2 days, and I only spend them when static screens cannot answer the question. I prototype when the feature has a new gesture, for example a swipe to act on a list row, when the team disagrees about feel rather than logic, and when we plan a usability test with 5 users on their own phones, because a static screen tells you what people understand, not what their thumbs can do.
I skip it when the feature is built from known platform patterns and the engineers can read a state list. An internal build behind a feature flag is often a better prototype than Figma, because it has real scroll, a real keyboard and real latency. A clickable prototype of a settings screen is 1 day of work that answers a question nobody asked.
Where AI tools help and where they do not
I use AI tools in 3 places. Drafting a first pass of copy across 9 states and 4 permission prompts. Generating test data with long names for the small screen. And summarising app store reviews into a list of edge cases, which saves most of a morning.
Where they do not help is the part that decides whether the feature ships. An AI screen generator does not know your app design system, your tab bar, your permission model or the sheet library your engineers use. It produces the isolated feature from the first paragraph of this post, faster, usually with a web pattern on a phone. The scoping, the platform fit and the engineer review are the work, and they are still done by a person who has your app on their phone.
Mistakes I see most often
Designing the success state only. 8 of the 9 states describe what happens when it does not work, and on mobile the offline state is the 1 users leave a 1 star review about.
Web patterns on a phone. Hover states, a modal with a close button in the corner instead of a sheet you can swipe down. Each 1 tells the user the feature was designed on a desktop.
Adding a tab. The tab bar has 5 slots and every feature wants 1. A 6th tab is how apps end up with a "more" tab nobody opens.
Skipping design QA on the build. The Figma is right, the build is mostly right, and the difference stays in the store for a month.
FAQ
How do you design new features for a mobile app without breaking it?
Start in the app on a real phone, not in Figma. Use the platform patterns and the existing design system, list every state including offline, and review with the iOS and Android engineers before the design is final.
How long does it take to design a new feature for a mobile app?
3 to 5 days for a small feature built from existing components, 1 to 2 weeks for a medium feature with a multi step flow or platform differences. Scoping takes 1 day.
Can you hire a product designer for an existing mobile app on a continuous basis?
Yes. For teams shipping a feature every release, we run a monthly subscription with 1 senior designer, 1 to 2 features in flight, a queue review each release and design QA on each build. It replaces scoping every feature as a separate project.
Should the feature look the same on iOS and Android?
The job, the flow and the copy should be the same. Navigation, back behaviour, sheets and permission prompts should follow each platform. I design 1 set of screens and mark the 3 to 5 places where the platforms differ.
Do we need a design system before adding new features to our app?
No. If you have 1, we design inside it. If you do not, we build the feature from your existing screens and the components it touches become the first page of your library.
Can a product designer work with our app release cycle?
Yes, if the designer stays 1 release ahead, joins 1 engineer review per feature, and tests the TestFlight or internal build before the release is cut.
Working with us
We design new features for existing iOS and Android apps, 3 to 5 days for a small feature and 1 to 2 weeks for a medium feature, inside your app design system and with your mobile engineers in the review. You get a 1 page scope on day 1, every state and every string at handoff, and design QA on the build before the release.
We also say when you do not need us. If your feature is 1 form on existing components and you have a good mobile engineer, the honest answer is to build it from the pattern you already have. And if 3 features in a row have been hard to place in the app, the problem is the information architecture, and we would start with a UX audit instead.
If you have a feature that has missed 2 releases waiting for design, book a free 15 minute intro call and bring the ticket and a build. We will tell you the scope and the states on the call.
