FROM THE EXCEED IT BLOG
Android App Interface Design: Make Everyday Tasks Easier to Complete
Published · Updated
An Android interface should help a person recognise what they can do, complete the task and understand the result. Attractive screens matter, but a booking form that loses information when the keyboard opens still creates a poor experience. Design the changing states of a task alongside its default appearance.
Organise navigation around user tasks
Group destinations using language customers or employees already understand. A technician might look for “My jobs”, “Parts” and “Completed work”, rather than internal database names. Keep the most frequent actions easy to reach and make the current location clear.
Decide what the system back action should do at each stage. Returning from a photograph preview should not silently discard an unfinished job card. Where leaving a screen would lose substantial work, save a draft or explain the consequence before proceeding.
Design forms with the keyboard visible
Test labels, input areas and the primary action on a small screen while typing. Choose suitable input behaviours and preserve entered values when validation fails. An error message should identify the field and explain how to correct it, rather than showing a generic failure at the top of the page.
Distinguish optional information from required information. If a delivery address is needed only for a delivery booking, reveal it at the appropriate point. Avoid collecting details merely because the database has somewhere to store them.
Include permission and connection states
Request a device permission when its purpose is understandable. A customer trying to attach a receipt can recognise why camera access is relevant. Show an alternative route where the product allows one, such as choosing an existing file.
An unsuccessful upload should preserve the user’s work and offer a clear retry. Show the difference between a locally saved draft and a record successfully received by the business. For field applications, these states belong in the design brief before implementation begins.
Adapt the layout without hiding essential work
Use larger screens to provide useful context, such as a job list alongside the selected job. On smaller screens, keep a clear route between those views. Test long names, translated content, enlarged text and empty datasets as well as the ideal sample data.
- Keep text readable against the actual background.
- Provide labels for unfamiliar icons and assistive technology.
- Make focused and selected controls distinguishable.
- Avoid using colour as the only indication of an error or status.
The WCAG reference is useful when planning accessible interfaces, particularly shared web experiences. Native Android behaviour also needs testing with the platform’s accessibility tools and representative users.
Review a complete scenario
Example: an appointment form before and after review
This original illustration is a planning prototype, not a screenshot of a client app. The same appointment request moves from an ambiguous form to a recoverable error and then a confirmed result.
- Before: a generic error gives no field-level instruction. If the selected time disappears, a customer must repeat work and may submit the wrong slot.
- After validation: preserve the appointment and entered values. Put the correction beside the email field, provide a text error and keep the action reachable when the keyboard opens.
- After confirmation: show the confirmed date and time, explain where the confirmation was sent and provide a route to manage the booking. If the request has not reached the server, show a pending state instead of a success message.
Use this state table to brief the designer and developer together:
| State | What the person sees | What the system preserves or checks |
|---|---|---|
| No available times | A clear empty state and another date or assisted route | The chosen service and customer details |
| Invalid input | The affected field and a specific correction | Other entered values and selected time |
| Sending | A progress state with repeated submission prevented | The request identity so retries can be handled safely |
| Connection interrupted | An explanation that confirmation is still pending and a retry route | The draft, with a clear distinction from a confirmed booking |
| Slot no longer available | Updated availability and a choice of another time | Customer details, with no claim that the old slot was booked |
| Confirmed | Date, time, reference and next action | The server-confirmed booking and agreed notification |
Reusable Android interface review checklist
- Can someone find the main task and understand the result without coaching?
- Are the selected date, time and entered values preserved after a validation error?
- Can someone correct the field and reach the action with the keyboard open and text enlarged?
- Are loading, empty, offline, permission-denied and retry states designed?
- Do labels and text explain errors without depending on colour alone?
- Does the back action preserve a draft or explain what will be lost?
- Does confirmation reflect the server's result rather than a tap on the button?
Check platform patterns against the official Android mobile design guidance, including adaptive layouts and Android accessibility guidance. Review the result on representative devices with the people who will use it.
Give a participant a task such as rescheduling a confirmed appointment. Observe whether they can find the action, understand the consequences and verify the new time without coaching. Record the points of hesitation and test a revised flow.
Use user acceptance planning to connect design decisions to business rules.