Sevginur Ak Parlak
Aug 12, 2024
14 min read
Mobile App UI Design Services: What We Deliver for iOS and Android
Take a typical case: a team sends me a Figma file with 24 app screens and asks how soon their Flutter developers can start. I count. 24 happy paths, 1 screen size at 390 by 844, 0 dark mode frames, 0 offline states and no permission prompts anywhere. The structure is good but the interface is not ready to build.
This is the most common situation I see with teams that have done discovery properly. The user flows work, the wireframes are approved, and what remains is the final interface, designed so that engineers can build it without guessing on 2 platforms. We call this phase interface delivery, and it is the core of our mobile app UI design services.
This post covers what the work includes, what it does not include and why, how I run it week by week, how we keep 2 platforms consistent with 1 design system, what design QA looks like on TestFlight and internal builds, and how long it takes.
What our mobile app UI design services include
The scope is fixed on day 1. It has 9 parts, listed in the proposal in this order.
1. Platform decision
Before any screen, we agree whether this is 1 design for 2 platforms or native patterns per platform. More on that below, because it changes the screen count by 20 to 30%.
2. Visual design
Type scale, colour, spacing, radius and the hierarchy of every screen, applied to the brand you have. On mobile this includes the tab bar, navigation bar, sheet and list styles, because those carry most of the identity.
3. Component set and tokens
Every element that appears more than once becomes a component with real variants. Colours, spacing and type live as Figma variables with semantic names such as surface.raised and text.muted, with a light and a dark value each.
4. All states
Empty at signup, empty after filtering, loading, partial failure, success, field error, no permission, offline, 1 item, 2,000 items and a 60 character name. Plus the permission prompts themselves: camera, notifications, location, contacts, with the screen that comes before the system dialog. On a 20 screen app this adds 40 to 70 frames.
5. Screen sizes and safe areas
At least 3 sizes, usually 375, 430 and 412 wide, with safe areas, the home indicator and the keyboard drawn in, and written rules for what scrolls, what pins and what truncates.
6. Dark mode
Every screen and component in both themes, driven by the token set rather than by redrawing. If you do not want dark mode at launch, we still deliver the tokens so it takes 2 days later instead of 2 weeks.
7. Interface copy
Labels, helper text, button text, empty states, permission prompt reasons and every error string, written in the file.
8. App icon and store screenshots
The icon at the sizes both stores need, and 5 to 8 store screenshots per platform in a template you can update when features change.
9. Dev ready Figma, handoff and design QA
1 file structured by flow, a 45 minute walkthrough with the engineers, a channel for questions during the build, and 2 passes of design QA on TestFlight or an internal Android build.
We wrote about the handoff package itself in Design Handoff to Developers. This post is about the phase that produces it.
What it does not include, and why
Interface delivery does not include discovery. No user interviews, no information architecture work, no rethinking of the navigation or the user flows. Doing them inside an interface project produces a bad version of both.
If the tab structure moves in week 3, every component built in week 1 and week 2 now sits on screens that no longer exist. The budget goes to redrawing, not to quality. So we check 3 things before we quote, and you can check them yourself:
The flows are drawn and agreed, at least as wireframes, including the onboarding and the permission steps.
At least 5 users, or 5 people outside the product team, have gone through the main flow on a phone, not on a laptop.
You can list the screens by name and say which platforms ship at launch.
Teams that cannot tick all 3 usually need the process in Product Design Process for an Early Stage Startup first. Better to find that out in week 1 than after 25 screens are designed on a navigation that changes.
How I run mobile app UI design week by week
A 20 screen app takes us 4 weeks. This is the default rhythm.
Week 1, foundations
We make the platform decision and write the exception list on days 1 and 2, and agree the token names with your engineering lead. Then we design 3 screens fully, in the most complex part of the app, usually the main list with filters and 1 detail screen. You see them on day 5, in light and dark, at 2 sizes.
Week 2, the component set and the main flow
We build the components from the 3 approved screens outward and design the main flow end to end, with all states, onboarding and permission screens included. Engineers can start building components at the end of this week.
Week 3, the rest of the screens, sizes and dark mode
Secondary flows, settings, account and empty states. Then every screen at 3 sizes with safe areas and keyboard, and every screen in dark mode. Copy is finished and reviewed by whoever owns your product voice.
Week 4, store assets, handoff and QA
App icon and store screenshots on Monday and Tuesday. The walkthrough on Wednesday. Questions through the week, and if the team started in week 2, design QA pass 1 on TestFlight happens in this week as well.
Reviews run on a fixed rhythm: a Loom walkthrough every Friday and comments in Figma by Tuesday. We work async across timezones, so the rhythm matters more than meetings.
How we keep 2 platforms consistent with 1 design system
Consistency across iOS and Android is not a matter of a careful eye. It is a matter of not having a choice. If there are 6 spacing values, nobody can pick a 7th, on either platform.
So the token set and the component set come before most of the screens. Each token has a light and a dark value, and each component that has a platform variant carries it as a property, platform: iOS or platform: Android, rather than as a separate file. When a screen needs something the system does not have, we decide once: a new variant, or the screen uses what exists. Each decision goes into a short changelog inside the file.
For SwiftUI teams the token names map to a colour and font extension, for Flutter to a ThemeData, for React Native to a theme object. We ask in week 1 and name accordingly, so the developer reads text.muted in Figma and finds text.muted in code.
Design QA on TestFlight and internal builds
An app that ships is built by people who did not design it, on devices nobody tested. Some drift is normal. Design QA is how we catch it before your users do, and on mobile it has to happen on real phones.
I install the TestFlight build on a small and a large iPhone, and the internal Android build on a mid range device, not a flagship. Then I go through a fixed list: spacing against the token scale, type styles including Dynamic Type at 1 larger setting, colour tokens in dark mode and disabled states, every state triggered for real including airplane mode, every permission prompt, safe areas with the keyboard open, touch targets at 44 by 44 points, and copy character by character.
Findings go into your tracker with a device screenshot, the expected behaviour, the token or component involved and a severity: blocker, major, minor or cosmetic. On a 20 screen app, expect pass 1 to produce a few dozen findings, most of them small spacing, token and copy fixes. Pass 2 a week later checks the blockers and majors, and we sign off on what goes to review.
Mistakes I see in mobile app UI design
Designing at 1 size
390 wide looks fine. Then the app opens on a 375 wide iPhone SE with a larger text setting and the primary button sits under the keyboard.
Designing with fake data
Real data has 47 character names, negative values, missing days and 1 user with 400 times more items than everyone else. On a 375 wide screen all of it changes the layout. We ask for an export of real records in week 1.
No screen before the system permission dialog
iOS gives you 1 chance to ask for notifications. If the app asks on launch with no explanation, a large share of users say no and you cannot ask again. The screen before the dialog is a design deliverable.
Dark mode as a filter
Inverting colours produces grey on grey and unreadable charts. Dark mode is a 2nd set of token values, decided per token.
Store screenshots made on the last day
They are the 1st thing a user sees and they are usually made in 2 hours by whoever is free. We make them from the same components and hand over the template.
Skipping design QA to save 2 days
The 2 days come back as 3 weeks of small visual bugs reported in public store reviews.
Where AI tools help and where they do not
AI tools save real time in 3 places here: generating the long tail of state variations from a component that is already correct, drafting error strings and permission reasons that we then edit, and producing SwiftUI or Flutter scaffolding from a finished frame so the developer starts from a layout.
Where they do not help is the decisions. Whether the back gesture closes the sheet, what the list does offline, which 5 platform exceptions are worth the extra work, what the notification prompt says. A model gives a plausible answer to each in seconds. The problem is that the 24 answers will not agree with each other, and half will be web patterns. Consistency across an app is still a person holding the whole app in their head.
FAQ
What do mobile app UI design services include?
The final interface of an app, designed so developers can build it without making design decisions. That means the platform decision, every state including offline and permission prompts, 3 screen sizes, dark mode, the copy, the app icon and store screenshots, a dev ready Figma file, and design QA on TestFlight and internal builds.
How long does it take to hire a UI designer for a mobile app and get the screens?
With us, the intro call is 15 minutes and a proposal follows within 2 business days. A scoped project of 15 to 25 screens takes 3 to 5 weeks for both platforms from 1 design, with 3 finished screens in 5 business days. Native patterns per platform add about 1 week.
Should the iOS and Android app have the same design?
For most startups at launch, yes, with a written list of 5 to 8 platform exceptions such as alerts, pickers and the share sheet. Native patterns per platform take 20 to 30 percent longer in design and longer in development, and they pay off in consumer apps where reviews mention how the app feels.
Do you design for Flutter and React Native or only for native apps?
All 3. The token set maps to a Flutter ThemeData, a React Native theme object or a SwiftUI extension, and we name the variables to match the stack you have.
Can development start before all screens are finished?
We recommend it. Once the component set is approved at the end of week 2, engineers build the components and the navigation shell while we finish the screens. It shortens the timeline by 1 to 2 weeks.
Working with us
We take on interface delivery for app teams whose flows are settled and who need the final iOS and Android interface designed and delivered to developers. A 15 to 25 screen app takes 3 to 5 weeks. You see 3 finished screens in 5 business days, and we stay through the build for handoff questions and 2 passes of design QA on real devices.
We also say when this is the wrong engagement. If your flows have not been tested with anyone on a phone, we will tell you to spend 2 weeks on that and come back.
If your structure is ready and your developers are waiting for the interface, book a free 15 minute intro call and send us the Figma file before it. We will tell you how far it is from dev ready.
