Android app design turns a user task into understandable screens and transitions on Android devices. Start with 4 design decisions: the main task, navigation, state feedback and accessibility. Then test the layout across relevant screen sizes and orientations. A phone-sized mock-up is one view of the product, not the complete design.
Search results include design examples, inspiration and tools. Use examples to compare patterns rather than copying an attractive screen without its context. A shopping list, a booking confirmation and a detailed work record have different information needs. The appropriate layout follows the task and the user’s next decision.
Which Android layout pattern suits the task?
Android’s layout basics recommends considering aspect ratios, size classes, orientations and safe areas. Its accessibility guidance addresses barriers affecting people with different access needs. These are platform design principles, not evidence that a particular application has already met them.
| Screen pattern | Useful task | Design question |
|---|---|---|
| List with detail | Find an item and inspect its record | Can the person return without losing context? |
| Focused form | Supply information for one action | Are required fields and errors understandable? |
| Summary with drill-down | Identify what needs attention | Does each figure or status lead to meaningful detail? |
| Guided sequence | Complete a task with dependent steps | Can progress and correction be understood? |
| Confirmation | Understand the result of an action | Does the message state what actually happened? |
These are original examples of layout choices, not a ranking of Android templates. A dashboard is not necessary for every app. If the main task is finding an assigned job, a clear list may be more useful than a collection of decorative charts.
Sketch the content before styling it. Use real-length names, ordinary descriptions and plausible empty or error states. A layout built only around short sample text can conceal clipping and hierarchy problems. Keep the task visible when text grows rather than shrinking everything until it fits the original picture.
How should navigation preserve context?
Identify the main destinations and how a person moves between them. Navigation should reflect stable areas of the app, while individual actions belong within the relevant task. Avoid making every feature a top-level destination merely because it has a screen.
Record what the Back action means in the flow. A person opening an item from a filtered list should understand where they return. If a form contains unsaved work, decide how leaving is handled. Do not make users discover through data loss whether a screen preserved their input.
Adapt to wider displays deliberately. A list and detail view may fit side by side where a narrow screen requires a sequence. The relationship should remain understandable in both arrangements. Merely stretching the phone design can create long lines and distant controls without improving the task.
Respect system areas and interruptions. Android’s layout guidance calls attention to safe areas and differing device configurations. Inspect the design with ordinary system bars, a visible keyboard and relevant display cutouts. Important actions should not become unreachable when the person starts entering information.
Which states need to be designed?
A screen has more states than its ideal populated view. Include loading, empty content, missing permission, failed requests and successful completion where relevant. The wording should explain what is known and what the person can do next.
Keep a request separate from a completed result. A button press may start a process that can still fail. Avoid a success screen that appears before the underlying action is established. Work with the implementation team to define the evidence that changes the visible state.
Use this original Android screen-state worksheet:
| State | Information to show | Interaction to test |
|---|---|---|
| First entry | Purpose and the starting action | Can a new user begin without coaching? |
| Loading | What is being retrieved or processed | Does the app discourage accidental repeated actions? |
| Empty | Why nothing appears and what can happen next | Is the distinction from an error clear? |
| Input error | The problem and an appropriate correction | Can the person find the relevant field? |
| Permission denied | The unavailable capability and a supported route | Can the task recover where recovery is possible? |
| Interrupted | What was retained and what must be repeated | Does the person understand the current state? |
| Success | The actual completed outcome | Is the next step clear without a false promise? |
This worksheet is an original practical artefact. It helps a designer and developer agree the state model before implementation. It is not evidence that a prototype performs a real network or device action.
How should accessibility be evaluated?
Use meaningful labels and a logical reading and focus order. Android’s accessibility guide discusses interaction for people with varied impairments and access needs. A visually obvious symbol may still be unclear to an assistive tool or to someone unfamiliar with the icon.
Check text enlargement and content variation. Essential information should remain available when the presentation changes. Do not approve a screen solely because it looks balanced at one default setting. Test the actual supported configuration with representative content.
Do not communicate important status through colour alone. Pair a visual treatment with understandable text or another appropriate cue. A warning must explain the condition and available action, not simply change a border from one colour to another.
Include relevant assistive-technology testing in the implementation plan. A design annotation can specify an intended label, but only the working app establishes whether it is exposed correctly. Retain the difference between a design requirement and a tested result.
What should the design handover include?
Provide the task flow, layout examples, state definitions and interaction rules together. Include actual wording and the exceptions that change it. An isolated collection of finished screens leaves developers to invent the transitions and recovery behaviour.
Record unresolved questions explicitly: a missing service rule, unknown permission behaviour or untested wide-screen layout. Resolve the important ones before they become hidden assumptions in code. Cosmetic polish should not obscure an unfinished task.
Inspect two documented layout examples
Use the official adaptive list-detail example alongside layout basics. It provides a real implementation route and an email-selection example, rather than an unrelated inspiration screenshot.
| Example route | Original task adaptation | State and layout trade-off |
|---|---|---|
| Layout basics: keyboard input do/don’t examples | A fictional visitor enters a long enquiry | Keep the focused input reachable when the keyboard appears; a clean empty-screen mock-up conceals this risk |
| Adaptive list-detail: list and selected email | A fictional technician selects an assigned job | Narrow screens show a sequence; wider space can retain list context beside detail. Back behaviour must be specified, not guessed from the drawing |
To compare them, sketch a job list with reference and subject, then a detail view headed by the selected reference. Add a loading message before the record arrives and an explicit “Unable to load” result with a retry action after failure. The examples and this adaptation describe intended behaviour; neither establishes that a working app has passed accessibility or device testing.
See web development for related application work. To explain an Android design requirement, get started with the main user task, supported devices and the states that currently cause confusion.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.