App design from the first flow to a build-ready UI kit
The screens people screenshot are the easy part. App design is mostly the states nobody photographs: empty, loading, offline, permission refused, partially synced and plainly wrong.
What is app design?
App Design is the product design work behind a mobile or web application: user flows, information architecture, every screen state, platform conventions and a documented UI kit developers can build from. It suits Australian teams building an iOS, Android or web app who need the interface resolved before engineering time is committed to it.
Get a fixed written quote- Typical timeline
- 5 to 10 weeks
- What drives cost
- The number of distinct flows, how many user roles exist, whether you need one platform or several, and how much research and testing is in scope.
- Best for
- New apps, or existing apps where usage drops after the first session
- You own
- Every design file, the UI kit and all icon and font licences
- Built with
- Figma, platform pattern libraries, tokenised UI kits, prototype testing
Your handover
The states nobody screenshots are most of the work
A design shown in a pitch deck has ideal data: three items in the list, a short name, a strong connection and a user who has already completed onboarding. Real apps spend a lot of their life outside that condition. There is the first launch when the account is empty. The moment a request is in flight. The train tunnel between Redfern and Central. The user who declined the notification prompt, the one whose payment failed, the one with two hundred items and the one whose organisation has not finished setting them up.
- 01Task flows for every core job
- 02Navigation model and information architecture
- 03Screen inventory covering all states
- 04Low fidelity prototype and test findings
- 05Platform aware visual design for iOS, Android or web
- 06Tokenised UI kit with components and variants
- Interaction and motion specifications
- Accessibility annotations to WCAG 2.2 AA
- App store screenshot and listing asset guidance
The full list
Every one of those is a screen someone has to build, and if the designer did not draw it a developer will invent it at eleven at night with no guidance. That is where inconsistent apps come from. So our screen inventory covers the full set of states per view, with the empty state treated as a design opportunity rather than an apology, because for a new user the empty state is the first real screen they see and it is the cheapest place to teach the product.
- Empty states that explain the next action rather than saying no data
- Loading and skeleton states matched to realistic latency
- Offline and reconnect behaviour, including queued actions
- Errors written as a fix, not a code
- Permission priming before the system prompt appears
- Long content, long names and the two hundred item list
The first ninety seconds decide retention
Most apps lose the majority of their new users in the first session, and the causes are consistent. A signup wall before any value is shown. A permission prompt for location or notifications that arrives with no explanation, gets declined, and cannot easily be asked again. A five step onboarding carousel that teaches nothing. An empty home screen with no obvious first action.
More on the first ninety seconds decide retention
We design that opening sequence deliberately, treating it as a product problem rather than a marketing screen. That means deferring account creation where the product allows it, priming permissions with a plain sentence explaining what the user gets before the system dialog appears, seeding the first useful state so nothing looks abandoned, and getting a person to their first genuinely useful moment inside a minute or two. We instrument those steps as well, because the drop off point is a fact rather than an opinion once analytics is wired in properly.
How the engagement runs
How an app design engagement runs
We sequence around flows rather than screens, because a screen list produced too early always turns out to be wrong. Once the flows are agreed, the screen inventory falls out of them and the estimate becomes reliable. Working the other way around, screen first, produces the classic mid project discovery that a whole branch of the experience was never accounted for.
- 01Product framingThe jobs the app does, who does them, and what a successful first week looks like for a user
- 02FlowsTask flows for the core jobs, including the recovery paths when something fails
- 03Information architectureNavigation model, content hierarchy and naming
- 04Low fidelity prototypeTested with eight to ten people who resemble your users, on their own devices
- 05Visual designPlatform aware screens with all states, dark mode where relevant
- 06UI kitComponents, tokens, spacing and interaction specifications documented for engineering
- 07Build-ready handoverAnnotated screens, prototype, accessibility notes and app store asset guidance
Two decisions on your side that keep the project moving
Testing happens twice, not once at the end. An early prototype tests whether the model makes sense to someone who does not work at your company, which is where the expensive mistakes hide. A later prototype tests whether the specifics work: labels, layout, whether people notice the primary action. Doing both is faster than doing neither and rebuilding after launch reviews start arriving.
Choose the right level
iOS and Android conventions: where to follow and where to diverge
Users do not read your app in isolation. They read it against every other app on their phone, and their expectations about navigation, gestures and system behaviour were set elsewhere. Fighting those expectations to keep the two platforms pixel identical is a common decision and usually the wrong one. It saves a little design time and spends it back many times over in confusion, support contacts and store reviews.
Element
01
Primary navigation
Keep it native
Tab bar on iOS, platform appropriate navigation on Android
Keep it yours
Which destinations exist and how they are labelled
02
Back and dismiss
Keep it native
Follow each platform, including the Android system back gesture
Keep it yours
Nothing. Overriding this is where most complaints start
03
Typography
Keep it native
Respect dynamic type and system scaling
Keep it yours
Your typeface and hierarchy, within the scaling rules
04
Forms and pickers
Keep it native
Native inputs, keyboards and date pickers
Keep it yours
Field order, help text and validation wording
05
Illustration and empty states
Keep it native
Nothing platform specific required
Keep it yours
Fully yours, and a strong place to build recognition
How we work this out during scoping
The rule we apply is to keep your brand consistent and let the platform own the platform. Identity, tone, colour, illustration and content are yours everywhere. Navigation patterns, date pickers, share behaviour, back gestures and system dialogs should feel native. The table sets out where we usually diverge and where we do not, though the specifics change with what the app actually does.
Accessibility on a handset is not the same as on a desktop
Phone accessibility has its own failure modes. Text that ignores the user's dynamic type setting and clips at larger sizes. Tap targets crowded so tightly that a thumb on a moving bus cannot hit the right one. Custom controls that VoiceOver and TalkBack announce as unlabelled buttons. Colour used as the sole indicator of status, which fails for a significant share of Australian men. Focus order that jumps around once a sheet opens.
More on accessibility on a handset is not the same as on a desktop
We design to WCAG 2.2 AA and test with the screen reader on each platform, because automated checks pass plenty of screens that are unusable in practice. This matters commercially as well as ethically. Apps used in health, education and disability services are frequently assessed against accessibility requirements before procurement, and retrofitting is far more expensive than designing it in. Teams delivering under the NDIS should assume it will be examined, and we scope those requirements alongside the wider provider needs up front.
When you do not need an app yet
Plenty of the app briefs we receive describe something a website already does well. If your product is browsed occasionally, needs no offline behaviour, no camera, no push notifications and no device sensors, an app adds two store review processes, two codebases and an install barrier for no functional gain. A responsive site or a progressive web app delivers the same value at a fraction of the cost, and people can reach it from a search result.
The rest of the answer
An app earns its place when it is used frequently, needs to work without a connection, relies on device capability, or benefits from notifications that people genuinely want to receive. If you are building it mainly because competitors have one, be aware that the install is the hard part and marketing an unremarkable app is expensive. We will say this before design starts rather than after, and if the honest answer is a web application, that is a different engagement we can scope instead.
How we scope it
Four ways to scope your App Design project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
App Essentials
The core of it, scoped and quoted
Fixed written quote, agreed before work starts
- Task flows for every core job
- Navigation model and information architecture
- Screen inventory covering all states
App Growth
The version most businesses need
Fixed written quote, agreed before work starts
- Everything in App Essentials
- Low fidelity prototype and test findings
- Platform aware visual design for iOS, Android or web
- Tokenised UI kit with components and variants
App Platform
The largest version, built around your operation
Fixed written quote, agreed before work starts
- Everything in App Growth
- Interaction and motion specifications
- Accessibility annotations to WCAG 2.2 AA
- App store screenshot and listing asset guidance
App Care
Ongoing support once it is live
Rolling monthly, quoted in writing
- A named engineer rather than a ticket queue
- Patching, monitoring and a tested backup
- Changes and improvements worked through monthly
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
Working with us
Can you design for an app our developers are already building?
Yes, and joining mid build is common. We start by auditing the existing screens for inconsistency and the missing states, then produce a system that can be adopted incrementally rather than requiring a stop and restart. Where engineering has already made structural decisions, we design within them and flag in writing anything that will cause a usability problem later.
Will you test the design with real users?
Yes, and we recruit people who resemble your actual users rather than colleagues. Eight to ten sessions on their own devices surfaces the great majority of serious problems, and a session takes under thirty minutes. If your users are hard to reach, such as clinicians or field crews, we plan recruitment early because that is the part that takes time rather than the testing itself.
What do you hand over to the development team?
Annotated screens with every state, a component library with tokens named the way the codebase will name them, interaction and motion specifications, accessibility notes and a clickable prototype. We also run a walkthrough with the engineers and stay available during the build to answer questions, because handover documents never anticipate everything a developer will hit.
Detail and edge cases
How long does app design take before development starts?
Usually 5 to 10 weeks. Framing and flows take the first two weeks or so, prototype testing the next, and visual design plus the UI kit the remainder. Apps with a small number of core jobs sit at the shorter end. Apps with role-based permissions, admin interfaces or complex data entry sit at the longer end because the screen count multiplies quickly.
What drives the cost of an app design project?
The number of distinct flows, how many user roles exist, whether you need one platform or several, and how much research and testing is in scope. Screen count is the visible driver but roles are the hidden one, since an app with three user types is close to three apps in design terms. We work it out on a call and put a fixed price in writing.
Do we own the design files and the UI kit?
Yes. Figma files, the component library, exported assets and any icon or font licences transfer to your business, purchased in your name. If a different studio or an internal designer continues the work, they inherit a documented system rather than a folder of flattened screens. Nothing is held back to keep you engaged with us.
Related services
Get a fixed written quote for your app design
Describe what the app has to do and who has to use it. We reply within one business day, including an honest view on whether an app is the right format at all.