Mobile UI&UX
Design
We create user flows, screens and design systems for iOS and Android apps. We settle the flows and wireframes first, then deliver a prototype you can try on your phone along with Figma files developers can use directly.
A finger is thicker than a cursor
On mobile, every button must be big enough to hit comfortably and must show what happened when it's tapped. Use the screen on the phone and toggle the touch areas and thumb zone.
↳ Tap the button on the phone; switch layers on the right.
Button state
- Guidelines suggest at least 44×44 pt on iOS and 48×48 dp on Android.
- The main action belongs in the lower area the thumb reaches easily.
- Every button gets pressed, loading, success and disabled states.
User flows
Step-by-step flow diagrams for key tasks such as sign-up, search, purchase and booking. Why each screen exists is settled before design begins.
Wireframes
Screen drafts drawn with content and layout only, no color or imagery. This is the stage where changes cost the least.
Clickable Figma prototype
A prototype you can try on your phone, with transitions between screens. It's used for internal reviews and user testing before development starts.
Design system
Components such as buttons, form fields, cards, lists and tabs, plus color, type and spacing values (design tokens). New screens are built consistently from these parts.
iOS and Android conventions
Navigation, back gestures, system fonts and platform-specific components following Apple's Human Interface Guidelines and Material Design.
Touch targets and accessibility
Touch targets of at least 44×44 pt on iOS and 48×48 dp on Android; WCAG contrast ratios, layouts that hold up with enlarged system text, and screen reader labels.
Screen states
A design for each state: empty list, loading, error, no connection, no permission. Nothing is left for the developer to guess.
First launch and permissions
Short intro screens; location, camera and notification permissions requested at the moment the feature is used, with the reason explained.
Store assets
App icon and App Store / Google Play screenshots, prepared to the stores' current size and content rules.
Four things we care about in mobile interfaces
Welcome
Intro 1/5
First-launch experience
When users open the app for the first time, they should immediately see what it's for and what to do first. Instead of long intro slides and forced sign-up, we design a start that can be tried without an account wherever possible.
What needs to be clear before design begins
Goals and users
- Whose job will the app make easier, and which job?
- In what situation will users open the app (in the field, at home, at work)?
- How will you measure success?
Features
- Features that must be in the first release
- What can wait for later releases
- User roles (customer, staff, admin)
Technical framework
- Will it be built native or with React Native/Flutter?
- Will it connect to an existing system or API?
- Are offline use, payments or maps required?
Brand
- Digital color values for your logo and brand colors
- Expected consistency with your website and other interfaces
- Language and tone of voice
The design package we deliver
Exporting · 1/6
How mobile design
progresses
Goals and users
We look at the problem the app solves, the user profile and competing apps, and list the key tasks.
Flows and wireframes
Task flows and screen drafts are drawn and the navigation structure is approved.
Interface and design system
Screens and the component library are produced in line with your brand identity, and the prototype is wired up.
Testing and handover
Task-based prototype tests are run with a few target users, fixes are made based on the findings, and files are handed over to the developers.
The next steps after design
Frequently Asked
Questions
We do both. You can get UI/UX design only and build with your own development team, or plan design and development together. When planned together, the design is shaped around the capabilities of the chosen technology (native, React Native, Flutter).
Most projects use a single design language, but each platform's conventions are followed for things like navigation, back gestures, date pickers and share menus. We decide at the start of design which screens will differ by platform.
Design files, the component library and exports are transferred to you at the end of the project. We recommend keeping the files in your own Figma account or your team's workspace.
Revisions are planned by stage: structure is worked on during the flow and wireframe stage, appearance during visual design. The number of revision rounds is stated in the proposal. If an approved stage needs to be revisited later, the impact is discussed separately.
A few people close to your target audience are given specific tasks on the prototype (e.g. "book an appointment") and we observe where they get stuck. Even small-scale tests like these reveal obvious flow problems before development begins.
Yes. First we review the current app's flows, store reviews and any analytics data, and list the problem areas. The redesign can be done in one go or in stages, screen group by screen group.
The number of screens, the number of user roles (e.g. separate customer and courier apps), the scope of the design system and the testing rounds. Once the flow list is ready, a stage-by-stage timeline is included in the proposal.