How to Design a Mobile App UI With ChatGPT: One Brief, 12 Screens, iOS vs Android

The worked example is CareCircle, a fictional shared pet-care planner. Its twelve selected images cover six states on each platform. Follow the brief, layout decisions, prompts, and repair examples to make your own screen set, then use the behavior notes to prepare a prototype or engineering handoff.

Choose the output you need before opening the chat

For a founder discussing an idea with a designer, a readable mockup and a short interaction description may be enough. A designer extending an existing app needs the component names, content rules, and missing states. A developer needs behavior and data definitions alongside the visual reference. Tell ChatGPT which of these deliverables you want so it does not spend the first response on decorative screens.

Begin in a ChatGPT chat with the text brief below. Once you approve the structure, explicitly ask it to generate an image. For edits, attach the accepted image and describe both the change and the parts to preserve. OpenAI's image-generation instructions cover these requests; image availability and limits depend on your plan and workspace settings. If your chat cannot generate an image, ask for the text wireframe and component specification, then use those in your design tool. You can complete the planning without an image.

You do not need twelve screens at the start. Use the first populated screen to settle hierarchy and reusable components. Add its empty and error cases next. Expand to another platform when those decisions are stable enough to compare.

Write a brief that fixes the product facts

CareCircle lets Alex and Sam see who is responsible for Milo's routines. Today contains Morning walk at 7:30 AM assigned to Alex, Breakfast at 8:15 AM assigned to Sam, and Brush coat at 6:00 PM assigned to Alex. The main action is Add routine. Today, Pets, and Settings are the persistent destinations.

These details let you catch a visually plausible error. Changing Breakfast to a completed task, dropping its assignee, or inserting a streak card changes the product. Keep a copy of the approved facts outside the chat so you can compare every output against the same source.

For your own app, replace the people, records, actions, and destinations in this suggested planning prompt. Keep the section that requires questions before the model invents behavior.

Help me plan the UI for CareCircle, a fictional shared pet-care app.
Do not generate images or code yet.

User task: Alex or Sam opens Today to see Milo's routines and assignees,
then adds a routine when something is missing.

Fixed facts:
- Pet: Milo, a golden dog
- Morning walk | 7:30 AM | Alex
- Breakfast | 8:15 AM | Sam
- Brush coat | 6:00 PM | Alex
- Main action: Add routine
- Destinations: Today, Pets, Settings

Scope:
- Phone layouts for iOS and Android
- Six states: onboarding, populated Today, Add routine,
  pet profile, empty Today, offline Today
- Synthetic data only
- No prices, accounts, subscriptions, streaks, or promotional cards
- Do not add features or claim that a change has synced

Return:
1. A text wireframe for each state
2. The purpose and result of each visible action
3. The information shared across screens
4. Questions about behavior that the brief does not settle

Mark proposed decisions as proposals. Wait for my answers before
using them as product requirements.

Read the questions before accepting the wireframes. For example, does a routine belong to one pet or several? Is the assignee required? Does Add routine open a separate screen or a sheet? Does saving close the editor? These choices determine the form and the return path. Asking the model to resolve them while drawing makes the decisions harder to notice.

Settle the navigation before drawing

For a small CareCircle exercise, use the rules below. They are proposed behavior, not a claim that the image set or downloadable demo implements saving. Today, Pets, and Settings remain peer destinations; Add routine is a temporary editor opened from Today.

Replace these rules if your app uses a sheet, keeps drafts automatically, or has a different navigation structure. State whether a saved item exists only on the device, is awaiting remote confirmation, or is confirmed by the service. The UI must show the outcome the implementation can support.

Turn the flow into a screen-and-state matrix

A screen is a location in the app; a state describes what the user encounters there. Today with records, Today with no records, and Today while offline can share a layout but need different copy and actions. Label them separately in your files and prompts.

The original twelve-image comparison covers these six states on both platforms. It leaves loading, invalid input, permission requests, deletion, large text, keyboard appearance, and shared-edit conflicts open. Add those where they could stop your app's main task; the next section shows how to choose them.

Choose additional states for your kind of app

Change the state list to match the task. These planning examples show which interruptions deserve attention in other kinds of app.

For CareCircle, invalid input and offline changes deserve attention before an elaborate Settings page. For checkout, the uncertain payment result deserves attention before promotional banners. Select the next state by the decision it exposes, then reuse the approved components wherever possible.

Decide what deserves space on the screen

Before choosing colors, ask ChatGPT for a plain text wireframe of Today. The user needs to find a routine, its time, and its owner. Give those elements the clearest reading order. A large dog illustration or a cheerful banner may look appealing while pushing the next task below the visible area.

Decide whether routine rows need individual card surfaces. If each row has little content and the same action, a grouped list may use space more economically. Cards can help separate records with several controls or statuses, but extra padding must earn its place. Compare the same three records in each option so you can judge the layout rather than different content.

Give typography, spacing, and color specific jobs

Define a small set of text roles: navigation title, routine name, supporting time and owner, field label, and status message. Start with the existing app's text styles or the platform components you plan to implement. Keep the owner readable even if it is visually secondary. Avoid shrinking all supporting text just to fit an oversized title or illustration.

For a routine row, reserve room for the time and owner, let a long name wrap, and let the row grow with its content. Use a stronger gap between records than between a name and its own metadata. Align repeated labels to the same edges. These rules give the model something concrete to follow and give you something concrete to rebuild; a request for a "clean, modern layout" leaves them undecided.

The example uses off-white surfaces, a green action accent, and dark text. Assign colors to roles such as primary action, normal text, secondary text, surface, and error. For dark mode, choose and check another set of values for those roles instead of simply inverting the image. A pending label needs readable text and a recognizable marker in either theme. The contrast checks later in this guide apply to the actual color values used in the build.

Use one icon family and one treatment for equivalent actions. Keep a visible label for an unfamiliar action; a paw icon alone does not explain whether it opens a profile, a pet switcher, or settings. Save decorative choices for after the routine information and actions are clear.

Compare variants at a useful size

Ask for two versions only when you have a decision to make, such as a compact pet summary versus a larger summary. Keep the records, platform, copy, and other components fixed. Compare how much routine information remains visible and whether Add routine is easy to find. Changing the palette, text, and layout together makes it difficult to know which change helped.

Inspect the generated image at full size to catch spelling and data errors, then view it at the width of the phone layout you intend to build. A label that looks readable on a large desktop image may become tiny when the whole screen is reduced. Choose the implementation's logical viewport separately from the PNG's resolution; the image's pixel dimensions do not establish native points, dp, or a usable touch area.

Generate one populated screen with a full prompt

Use a new image request after approving the text plan. Include the fixed facts again, identify one state, and name the platform. Ask for a complete screen without an angled phone frame so the content can be reviewed at a useful size.

Use this iOS prompt as a starting point, replacing the records and layout choices for your app:

Generate one complete portrait UI mockup for CareCircle's populated
Today screen on iOS. Produce an image, not code or a written description.

Task: Alex and Sam need to see Milo's routines and their owners.
Show these records exactly:
- Morning walk | 7:30 AM | Alex
- Breakfast | 8:15 AM | Sam
- Brush coat | 6:00 PM | Alex

Layout brief:
- Large Today navigation title for this screen
- Milo summary above inset grouped routine rows
- One top-right Add routine action
- Tab bar: Today, Pets, Settings; Today selected
- Warm off-white background, forest-green accent, sage surfaces,
  and dark navy text
- Leave room for the status area and bottom safe area

Allowed product text: CareCircle, Today, Milo, Morning walk, 7:30 AM,
Alex, Breakfast, 8:15 AM, Sam, Brush coat, 6:00 PM, Add routine,
Pets, Settings.

Do not add slogans, promotional panels, recommendations, streaks,
completion badges, extra records, prices, or account controls.
Show the full screen straight on, without hands, phone hardware,
watermarks, clipped controls, or cropped navigation.

For the Android comparison, keep the records and allowed text. Replace the layout brief with this block; explicitly restate Android in the opening request:

Android layout brief:
- Material 3 treatment with one compact Today top app bar
- Milo summary followed by routine cards or list items
- One extended floating action button labeled Add routine
- Navigation bar: Today, Pets, Settings; Today selected
- The same off-white, forest-green, sage, and dark navy palette
- Account for the status and system-navigation areas
- Preserve every routine, time, and assignee
- Do not use the large navigation title selected for the iOS version

These are CareCircle's design choices. A large title is not required on every iOS screen, and a floating action button is not required in every Android app. Android's navigation guidance describes navigation bars for peer destinations and a FAB for an action of highest importance. Use the app's task and existing component system to choose the appropriate treatment.

Open the returned image at full size. Check Morning walk, 7:30 AM, and Alex as one record, then repeat for the other two. Confirm the selected destination and whether Add routine is discoverable. Review any text you did not supply. If it introduces a feature or a product claim, remove it before using the screen as the reference for later states.

Use the first failures to tighten the next request

The original baseline avoided naming iOS or Android. Its output chose an iOS-like large title, status area, disclosure rows, and tab bar, and added "Happier pets. Brighter days. Together." The image returned in 23.8 seconds. That is one recorded generation time, not an estimate for a finished UI or another run.

The retained iOS Today screen also added "Happier days together" and a promotional panel reading "Small care makes a happier tomorrow." The panel takes space that could show tasks. A readable result still needs a copy check: the exact records can be present while an unrequested feature changes the screen's priorities.

The generated dog changes across screens. The original run supplied no fixed source photograph or asset ID. If your product depends on a recognizable person, pet, product, or logo, use an approved source asset in the final design. A reference image can guide generation, but the final component should reuse the actual approved file.

Record each problem beside the output: which requirement failed, what stays approved, and what must change. This can be a short text note. Keep the rejected image so the next reviewer can see why it was replaced.

Create the other five states from the approved reference

Attach the selected Today screen for each subsequent request and include the shared brief plus its platform layout block. Request one state per image. The blocks below describe the original state plan; where a field rule or interaction was never tested, treat it as a specification to confirm before implementation.

Onboarding

Generate the first onboarding screen for the same CareCircle app
and the selected platform. Reuse its palette and typography.

Use this copy exactly:
CareCircle
Share pet care without the guesswork
Plan routines, divide tasks, and see what is already done.
Continue

Show a restrained pet-care illustration and a page indicator.
Do not show bottom navigation, routines, testimonials, prices,
or sign-in claims.

Write down what Continue opens. If the actual product has one introduction screen, remove a page indicator that suggests several. If it has several, name the remaining steps and whether the user can skip them. A generated indicator does not establish an onboarding flow.

Add routine

Generate CareCircle's Add routine screen for the selected platform.
Use the approved Today screen as the visual reference.

Fields: Routine name, Pet, Time, Assigned to.
Show Milo as the pet and Alex and Sam as the available assignees.
Use only approved values; do not invent another pet or household member.

iOS treatment: grouped editor rows, Cancel and Save navigation actions.
Android treatment: visibly labeled fields and one Save routine action.
Keep field labels readable and distinguish input from supporting text.
Do not invent a successful save, permission prompt, or keyboard state.

For the exercise, define a routine as one occurrence on the day selected in Today. Make Routine name, Time, and Assigned to required, with Milo preselected as Pet. This keeps recurrence outside the form. A real repeating schedule needs a frequency rule and a way to distinguish changing one occurrence from changing the series.

Here is a proposed behavior specification to use with the form image. It still needs implementation and testing:

Write errors beside the relevant fields rather than in a disappearing message alone. If your app saves only locally, replace the remote-submission states with that behavior. If it allows offline editing, define whether the device can retain the draft and queued change before promising either in the UI.

Pet profile

Generate Milo's pet profile in the same CareCircle app.
Reuse the selected platform's components and the approved pet asset
if one is supplied. Provide an Edit action.
Show only profile facts approved in the brief.
If age, breed, health notes, or other values are missing, omit them.
Do not invent medical data, activity statistics, or premium features.

For an existing app, list the fields already stored by the product and which ones the current user may edit. Ask for the empty-value treatment too. A believable age or breed in a generated profile is invented data unless it was provided.

Empty Today

Generate CareCircle's Today screen after loading succeeds but there
are no routines for the selected day. Keep the platform's navigation
and Milo context. Remove the routine records.

Use Nothing planned yet and an Add routine action.
Explain that adding a routine puts a task into this plan.
Do not show fake sample records, a loading spinner, an error notice,
completed progress, or a second competing primary action.

Specify what is empty. No routines today, no pet profile, and no household access are different situations with different remedies. If a date filter caused the empty result, keep the date visible and offer a way to change it. A request failure needs retry information; it should not instruct the user to create data that may already exist.

Offline Today

Generate CareCircle's offline Today state using the selected Today
screen as reference. Keep Milo and all three routines, times,
and assignees visible. Morning walk has a local change awaiting sync.

Show You're offline, Retry, and Pending sync beside Morning walk.
iOS: use an inline connection notice.
Android: use a snackbar above the navigation bar for this comparison.
Do not label the change Synced or show server-confirmed completion.
Do not remove existing records or add another routine.

Both example images show the intended offline notice and Pending sync label. The iOS offline image also omits the required Alex and Sam assignee labels; Android keeps them. Restore those labels before using the iOS image as a final reference. An image can show the connection state correctly while dropping information the user still needs.

For the implemented product, decide where a pending status remains discoverable after a temporary message disappears. Define whether edits are allowed offline and what happens after restart. Use the model to draft these questions, then answer them from your actual storage and network design. A screenshot cannot establish a durable queue or a successful retry.

Repair a specific defect while preserving accepted decisions

The original Android Today V1 included cards, an extended Add routine FAB, and bottom navigation, but used an oversized Today title despite a prompt excluding the iOS-style large-title treatment. This failed the chosen brief. It does not establish that Android interfaces can never have large titles.

The recorded repair attached V1, restricted the edit to the header and resulting spacing, and preserved the remaining components. Its core instruction was:

Change only the top header and first content spacing so this reads
as Android Material 3 instead of iOS. Replace the oversized two-line
CareCircle / Today treatment with one compact Material 3 top app bar:
title Today on the left and one small circular paw/profile action
on the right. Remove the huge display-sized Today title.
Move the Milo card upward to use the recovered space.

Keep the Milo card, all three routine cards, their exact text and
assignees, the extended Add routine floating action button, bottom
navigation, colors, dog identity, icons, status bar, gesture indicator,
and overall canvas unchanged.

V2 replaced the large title and kept the rest recognizably close to V1. Compare the full images after every repair: read the records again, inspect the bottom navigation, and check the pet asset. An edit request limits the intended change; it does not guarantee that other pixels stay identical.

For the iOS offline defect, a proposed repair would name the missing labels and their record associations: Morning walk belongs to Alex, Breakfast to Sam, and Brush coat to Alex. Ask to restore those labels without removing Pending sync or the offline notice. That repair has not been generated in the retained example.

If successive repairs keep changing accepted data, rebuild the text and controls in an editable tool. Continuing to regenerate a screen is less useful once the decision you need is a stable label, field, or spacing rule.

Keep components, assets, and copy consistent across screens

The reference image helps communicate a direction, but it has no component instances or shared variables. Maintain a small inventory beside the screen set so a designer or developer can recreate the accepted decisions without guessing from pixels.

Record the text styles, color roles, spacing, and corner-radius choices you settled earlier in the same inventory. When an existing design system provides them, give the model those values. Ask for proposed values only where the system leaves a choice open.

Use a fixed text inventory for critical labels. If the image misspells a routine or makes text unreadable, typeset the approved copy in the editable design or implementation. Repeated requests to "make the text clearer" can change other parts of the screen without resolving the content rules.

When you already have a screenshot or design system

Upload a screenshot you are authorized to use, with private information removed. Add component names or a short description of the actual system. A screenshot reveals appearance but may not reveal spacing tokens, hidden states, or whether a control is custom.

Review this existing Today screen. Do not redraw it yet.
Problem to solve: a user cannot easily identify who owns each routine.

Inventory the visible components and text.
Treat my supplied component names and rules as authoritative.
Mark any inferred behavior as unknown.
Propose a change limited to routine rows and assignee presentation.
Keep navigation, the pet summary, approved colors, and all records.
Return the revised hierarchy, copy, and missing interaction decisions.

Approve the proposal, then request a mockup of that change using the original as reference. Compare the same records before and after. An attractive redesign that hides assignment information has missed this task, even if it improves the colors.

Design the interruptions the six pictures leave open

Ask for these states after approving the base components. They are additional design exercises; they were not generated or tested in the original CareCircle run. Choose the ones needed for your flow and describe the state in terms of an event and its result.

Loading and failed requests

For Today, separate first load from refreshing existing routines. A proposed first-load state shows Loading routines without invented task rows. Show Nothing planned yet only after the request succeeds with no routines for that day. If the request fails before any records are available, show Couldn't load routines and Retry, keeping the selected day visible.

During refresh, keep previously loaded routines visible with a refreshing indicator. If refresh fails, use Couldn't refresh routines and Retry above that list. Show the last update time only if the app actually records it. This allows someone to use the available plan while understanding that it may be out of date.

Write these as mutually exclusive outcomes of a request. A spinner, empty message, and failure notice should not appear together because the model treated them as independent decorations.

Form errors and keyboard appearance

For Add routine, specify the exact invalid input and message, where the message appears, and whether Save is disabled or validates on activation. Keep entered values after an error. If the user dismisses the form with changes, decide whether those changes are discarded, saved as a draft, or require confirmation.

Describe three additional Add routine states before drawing them:
- Routine name is empty and Save is activated
- Routine name is being edited while the software keyboard is open
- Saving fails after valid input was submitted

Proposed rule: Routine name is required.
Keep the draft's other values after validation or submission failure.
For each state, specify visible copy, action availability, focus,
scrolling, and what happens when the user retries or leaves.
Identify any behavior that needs an implementation decision.

Check that the focused input and its error remain reachable when the keyboard is open. Decide how the form scrolls and how Save remains accessible. Android's layout basics specifically includes software keyboards, system bars, cutouts, and flexible input layouts. Drawing extra space below a field does not test keyboard avoidance.

Long text, localization, and larger text settings

Make a separate test copy with deliberately long names, such as "Evening walk and paw check after the park" and a long household member's name. Keep the Milo baseline beside it for comparison. Let the routine name wrap; keep its time and owner available. If a secondary note is shortened, provide a detail view where the full note can be read.

Check a narrower phone layout and a larger text setting in the implementation. For translated copy, provide the actual reviewed strings rather than asking the image model to invent a language variant. If the app supports languages written right to left, specify the navigation and icon-direction review too. Do not shrink the entire screen to make the text fit.

Permissions and destructive actions

If CareCircle later adds reminders, plan what happens when notification permission is denied. The routines should still have an explicit outcome in the brief; permission refusal must not leave an unexplained blank screen. For deleting a routine, write down exactly what is deleted, whether it affects future occurrences, and whether undo is available.

A prompt can propose the permission explanation or deletion confirmation. The actual permission request and deletion behavior must come from the implementation. Avoid generating a fake system dialog and treating it as an approved platform control.

Offline recovery and conflicting edits

Choose an offline design that the implementation can support. Here are three possible policies, rather than one assumed behavior for every app:

For example, Alex might move Morning walk to 8:00 AM offline while Sam moves the same occurrence to 7:45 AM on another phone. If the product asks the user to resolve conflicts, show both times and identify which choice is theirs. If it uses an automatic policy, explain the final result when necessary. The designer and developer must agree on that policy before drawing a Keep mine or Use latest action.

Separate queued, failed, and confirmed updates. Specify what Retry does and what prevents repeated activation from creating duplicate records. Keep unsupported persistence or conflict behavior out of the UI promises and list it as an open implementation decision.

Review readability and touch behavior at the right level

A screenshot can reveal a tiny label or clipped button. It cannot establish the hit area, accessible name, focus order, or response to text scaling. Review the picture first, then measure and operate the rebuilt controls.

Apple's UI design tips recommend controls measuring at least 44 by 44 points. Android's accessibility guidance specifies touch targets of at least 48 dp and alternatives to actions that rely only on gestures. A small icon can have a larger interactive area, so inspect the control's bounds rather than measuring its drawn symbol.

For the browser reconstruction, WCAG 2.2's target-size minimum uses 24 by 24 CSS pixels with exceptions. That is a web criterion. A 48-pixel HTML button does not prove a 48-dp native target, and a high-resolution PNG provides neither measurement.

For text in a web prototype, WCAG's contrast criterion requires at least 4.5:1 for ordinary text and 3:1 for qualifying large text, with specified exceptions. Measure the defined foreground and background colors rather than sampling softened screenshot edges. Use a named text status alongside color for Pending sync, then inspect its readable equivalent in the actual control.

In an executable build, navigate to Today, identify a routine's name, time, and owner with the platform's screen reader, activate Add routine, and return to the changed list. Review any icon-only action's accessible name. If it is announced only as "button," the visible icon has not provided a usable label.

Open the downloadable prototype and inspect its limits

The original review kit contains fourteen retained PNGs, eight comparison boards, the historical prompt pack, a screen ledger, a generation record, file hashes, and an independently written HTML/CSS/JavaScript prototype. Twelve selected images form the planned comparison; the unconstrained baseline and rejected Android Today V1 are the extra two.

Download the original UI review kit or download its recorded prompt pack. The planning and testing prompts in this article supplement that pack.

1. Extract the ZIP and find the folder containing README.md and prototype/.
2. Open a terminal in that folder. If Python 3 is available, run the command below.
3. Open http://127.0.0.1:8098/ in your browser.
4. Use the platform and state selectors to inspect all twelve combinations. Compare the routine facts and action placement.
5. Try a narrow viewport and keyboard navigation. Record what you observe separately from the retained test report.
6. Stop the local server with Ctrl+C when finished.

python3 -m http.server 8098 --bind 127.0.0.1 -d prototype

If the command reports that the address is in use, choose another available port and change the URL to match. If the browser shows a directory listing, check that you ran the command from the extracted kit's root and that prototype/index.html exists. The demo needs no mobile build toolchain.

The September 16 browser run passed four tests after correcting a favicon 404 and enlarging an Android back control from the demo's 44-CSS-pixel iOS minimum to its 48-CSS-pixel Android minimum. The checks covered all twelve combinations, console health, horizontal overflow at 390 × 844 and 412 × 915, and those chosen control sizes. They describe the browser demo; native safe areas, screen readers, text scaling, software keyboards, persistence, and synchronization still need their own tests.

Fourteen image calls took about 419 seconds of tool wall time. That excludes brief writing, prompt revision, review, repair decisions, file work, OCR, comparison-board construction, prototyping, testing, and article writing. The generation interface did not expose a served model identifier or seed. Neither that total nor the first image's 23.8 seconds predicts how long your design process will take.

Turn the approved screen set into an editable design

Place the selected images in a reference area, then recreate the accepted layouts with editable text, components, and constraints in your design tool. Reuse your existing system if one exists. Importing a PNG into Figma keeps it a bitmap; it does not create the routine row's fields or its state variants.

Begin with the routine row because Today, offline Today, and the long-name example all use it. Create variants for normal and pending status, with a documented rule for errors if your product needs one. Keep the required labels editable. Build the pet summary from the selected asset, then assemble the platform-specific navigation and form controls.

Specify what happens when content grows: the routine name wraps, the time remains available, the assignee stays identifiable, and rows can become taller. Set that behavior in the editable layout instead of copying a fixed height from a screenshot. Repeat the review with larger text before treating the component as settled.

Map the same product model to each platform. The iOS Add routine reference uses grouped rows with Cancel and Save; the Android reference uses labeled fields and one Save routine action. Onboarding is similar on both. Keep differences that help the task and avoid adding them solely to make the pair look different.

Give the developer behavior alongside the images

A handoff should identify the selected files, required copy and data, component inventory, state transitions, and unresolved decisions. Mark rejected images clearly so a coding agent does not implement the iOS promotional panel or the first Android header simply because it looks complete.

Use a separate implementation request after selecting the design. OpenAI's documented iOS workflow includes building and simulator review, while its Expo workflow covers a runnable mobile flow. Choose the path that matches the project you already have. The original CareCircle kit contains neither a native project nor an Expo app.

Implement one CareCircle flow using the attached approved UI references
and this behavior specification. Inspect the existing project first.
Reuse its components and platform conventions.

Flow: Today opens Add routine. Valid submission returns to Today
with the new routine visible and an accurate storage/sync status.

Keep Milo, Alex, Sam, the three baseline routines, and the destinations.
Implement empty, populated, editing, validation error, saving,
submission failure, and offline states needed by this flow.

Confirm before implementation:
- required fields and recurrence rules
- Cancel and unsaved-draft behavior
- local storage and remote confirmation
- retry and duplicate-prevention behavior
- conflict policy for shared edits

Verify:
- invalid input keeps the user's other entered values
- keyboard appearance leaves the focused field and Save reachable
- failure never displays server-confirmed success
- larger text preserves task, time, and assignee information
- icon actions have usable screen-reader names
- each platform's controls respect its touch and inset requirements

Return the runnable project, exact run commands, checks performed,
tested device or simulator, and unresolved or untested behavior.
Do not describe simulated data or status as a working backend.

For a design discussion, you can stop with a reviewed screen set and a list of open decisions. For a clickable demo, inspect its specified flows. For an app release, require evidence from the actual implementation and device environment. Record the object of approval, such as "Today layout approved; offline persistence unresolved," so the next person knows what remains to build.

Check whether another person can complete the task

Show the selected Today mockup to someone who has not followed the prompts. Ask, "Who is responsible for Breakfast, and at what time?" The expected answer is Sam at 8:15 AM. Then ask where they would add another routine. Let them point to the action before explaining the layout. These questions check information and action discovery; they do not test whether saving works.

In a prototype that implements the flow, ask them to add "Evening walk" for Milo at 6:30 PM assigned to Sam, then verify the resulting record on Today. Follow with a blank-name attempt and a failed-save case if those are implemented. Watch for lost values, unclear feedback, and difficulty returning. Record what happened in that version; do not count a described interaction or a static picture as a completed task.

If someone misses the owner, revise the routine row's grouping and text hierarchy before changing the theme. If they tap Pets to add a routine, inspect the action label and placement. Use the observed confusion to choose the next edit. These are suggested review tasks, not results from a CareCircle user study.

Check the work before handing it over

Use the list below with the selected images and specification open together. Each item should point to a file, visible result, or written decision.

• The core task is clear: the user can identify a routine, its time, and its owner, then find Add routine.
• All six planned states exist for both platforms, and any additional task-blocking states have a named owner or next step.
• Names, times, assignees, destinations, and copy match the approved inventory. Unrequested claims and features are removed.
• The selected Android header follows its brief, and the rejected V1 is labeled as rejected.
• The iOS offline assignee omission is documented or repaired before that image becomes an implementation reference.
• The pet asset, routine rows, fields, and status meanings have reusable definitions.
• Long-content, keyboard, error, retry, and permission behavior are specified wherever the chosen flow requires them.
• The handoff distinguishes a selected layout, an executable prototype, and the checks still needed on the native build.

Send the selected screen set with its component inventory and behavior notes. Keep unresolved requirements beside the relevant screen, including who must answer them before implementation.