Puff Pray
A mobile app that helps Muslims log their five daily prayers with a single tap, see how long remains until the next one, and stay consistent through gentle rewards. I designed it end to end and built it in Flutter with an AI coding assistant, so no intent was lost between design and code.
Outcome: logging went from four separate cards and two buttons in v1 to a single “Now / Next” card with one toggle in v3. Users see what to do the moment they open the app and finish it in one tap.
(01) Context
You don’t need any religious background to read this case. One constraint shapes every design decision: five daily tasks, each with a time window that moves every day.
- Practising Muslims perform five prayers a day. Each can be performed any time inside its window, which opens at a set point and closes when the next one opens.
- The windows are tied to the sun’s position, so they shift by a minute or two each day and differ by city. A user can’t memorise them the way they would a fixed alarm.
- The five prayers, with the names used in the app: Fajr (dawn, ends at sunrise), Dhuhr (midday), Asr (afternoon), Maghrib (just after sunset), Isha (night).
- Times are calculated from the user’s location using a published method; several regional methods exist, and the user can pick one in Settings.
In product terms this is closer to medication or hydration reminders than to a to-do list. The patterns here — surfacing the current window, one-tap logging, preventing future-dated entries and non-punitive streaks — transfer directly to those products.
(02) The problem
Logging a prayer is a short, time-bound action that happens five times a day. Existing apps either only show the times, or bury logging behind menus and turn it into a chore.
I identified five friction points:
- 01Lost contextA list of times exists, but the user has to work out “which window am I in right now?” themselves.
- 02High action costLogging means opening the app, switching screens and finding the right row.
- 03Error riskIt is possible to mark a prayer whose window hasn’t opened yet as done.
- 04Forgotten entriesThere is no clear way to log a prayer after the fact.
- 05MotivationThere is no feedback loop that makes consistency visible without making people feel guilty.
Who it’s for: a busy young adult who wants to pray regularly but sometimes misses a window during the workday. Their phone is always at hand, they have no patience for long flows, and they expect an interaction as quick as dismissing an alarm.
Design questionHow can a user, within 3 seconds of opening the app, see which window they are in, log whether they’ve prayed, and see how long until the next one?
(03) Users and goals
Each user need became a design goal with a concrete measure of success.
| Need | Design goal | Success measure |
|---|---|---|
| “Which window am I in?” | Current prayer and time remaining visible at a glance | 0 taps from app launch to the answer |
| “I’ve prayed, let me log it” | Log the current prayer in one tap | 1 tap; possible from the widget without opening the app |
| “I forgot to log this morning’s” | Fast access to earlier prayers | 2 taps from any screen |
| “I don’t want to make mistakes” | Prayers whose window hasn’t opened can’t be logged | 0 future-dated entries |
| “I want to keep going” | Make consistency visible, never use punitive language | Share of fully completed days, weekly return rate |
| “I don’t want to miss a window” | Remind ahead of time | Notification 45 min before and when the window opens |
These measures are design targets; they will be replaced with real values once usage data is collected.
(04) The character
The app’s mascot is a puffer fish, and the name Puff Pray comes from it. The joke at the heart of the brand: praying should feel as effortless as a puff — open the app, tap, puff, done.
It turns a serious, private routine into something light and friendly, without making fun of the practice itself. The character also does real UX work:
- 01Sets the tone.A soft, slightly comic creature signals “no judgement here”, which supports the decision to drop penalty language.
- 02Gives the home screen a reason to exist.The aquarium at the top of the home screen is the fish’s home, so the calm visual area is part of the story rather than decoration.
- 03Makes the brand memorable to anyone.A puffer fish needs no religious context to be understood, which keeps the app approachable for newcomers.
(05) Designing with AI
I used AI not as a code generator but as a prototyping partner that let me test design decisions on a real device, fast. I made the decisions; the AI turned them into working Flutter code; I used the result on my phone, critiqued it and steered the next round.
Every round followed the same loop
- 01Intent.Write down the question the screen must answer and the user goal (e.g. “On launch: current prayer + one-tap logging”).
- 02Prompt as spec.Hand the AI the component hierarchy, states (loading, error, empty, completed), copy and constraints (e.g. “a future prayer can’t be logged”), the way I’d write a developer handoff.
- 03Try it on device.Use the generated screen on my phone with real, location-based data.
- 04Critique and simplify.Review hierarchy, tap count and tone, cut what wasn’t needed, and start the next prompt from those decisions.
| Date | Iteration | What changed |
|---|---|---|
| Aug 2025 | v3 — Focus | Animated aquarium, four cards merged into one “Now / Next” card, single toggle, future-prayer lock, punitive copy removed |
| Aug 2025 | v2 — Beyond the app | Android home-screen widget: current prayer, points, Done / Missed buttons |
| Aug 2025 | v1 — Core | Location-based times, notifications, calendar, settings, points; four separate cards in a draggable bottom panel |
| Jun 2025 | v0 — Setup | Project scaffold and Material 3 foundation |
A question like “would one toggle beat these two buttons?” got settled by trying both on a phone within minutes, instead of debating it over static mockups. The codebase is about 2,900 lines of Dart across 8 services and 3 screens.
(06) Key UX decisions
The biggest win is on the home screen: a first design of four cards and two buttons became one card and one toggle.
| Area | v1 (before) | v3 (after) | Why |
|---|---|---|---|
| Home hierarchy | Static “Aquarium” placeholder; information in a draggable panel opening at 25% of the screen | Animated aquarium on the top 60%, one scrolling flow below | The drag gesture was hard to discover; key information had to be visible at a glance |
| Time information | Four separate cards: current prayer, next prayer, clock, all times | One card: “Now: Asr” and “Next: Maghrib in 1 h 12 m” | Answers the user’s two questions at once; the phone already shows the clock |
| Logging | Separate “Completed” and “Missed” buttons | A single “Mark as Completed” toggle | Two buttons added decision load; a toggle handles both logging and undo |
| Error prevention | Any prayer could be logged at any time | The toggle is disabled until that prayer’s window opens | Prevent wrong entries instead of asking users to fix them later |
| Feedback tone | “You lost 20 points.” / “(points removed)” | Neutral “marked as not completed” on undo; “+20 points” on completion | In a personal, spiritual context, loss framing creates guilt and drives people away; positive reinforcement stayed, loss emphasis went |
Decisions in the newly added flows
- Logging earlier prayers
- An always-visible “Mark Prayer” button opens a bottom sheet listing all five. Sunrise appears in the list as information but can’t be logged, because it isn’t a prayer — it marks the end of the dawn window. Information and action are kept apart.
- Logging without opening the app
- The Android widget brings the current prayer, points and two action buttons to the home screen, removing the need to open the app for the most frequent action.
- Instant launch
- Times load from a local cache immediately; a loading spinner only appears on first setup. Every night at 00:10 the next day’s times are prepared in the background.
- Timely reminders
- A notification 45 minutes before each window and another when it opens. For sunrise the copy reads “Fajr time ending”: sunrise is framed as the dawn prayer’s deadline, not as a prayer of its own.
- Making consistency visible
- The calendar is a heatmap — green for all five done, orange for some, grey for none — with a “3/5” counter on each day and a per-prayer breakdown on tap.
- Reward model
- 20 points per prayer, plus a 15-point daily bonus for completing all five. The bonus is automatically withdrawn if an entry is undone, so the system can’t be gamed, yet users are never penalised.
(07) Visual language
The visual language is built on calm. The top 60% of the home screen is an aquarium with slowly rising bubbles, so the app feels like a moment to breathe rather than a to-do list. The aquarium is the puffer fish’s home, and is positioned to become a reward space that grows with the user’s points.
- Colour
- Material 3 palette generated from a green seed colour (#2E7D32 light, #4CAF50 dark)
- Theme
- Light / dark mode following the system
- Shape
- 16 px corner radius on cards, 12 px on buttons, 20 px on bottom sheets
- Status colours
- Green done, orange partial, grey none; same meaning across screens and the widget
- Typography
- 22 px bold “Now” heading, 16 px secondary “Next” line; current prayer bold with a highlighted background in the list
- Iconography
- Puffer fish (brand character), star (points), check mark (completed); a generic mosque icon is still used in the menu and widget
Theme values are defined in one place for the whole app; Home and Settings use theme roles (primaryContainer, onSurface) instead of hard-coded colours. Calendar and the widget still contain hard-coded colours, addressed under next steps.
(08) Outcomes, learnings and what’s next
On opening the app, users now see their current prayer and the time until the next one with zero taps, and log the current prayer with one. The journey from design to working product was carried out by one designer and an AI assistant.
| Measure | v1 | v3 |
|---|---|---|
| Information cards on home | 4 | 1 |
| Logging the current prayer | Open panel + choose one of 2 buttons | 1 toggle |
| Logging a future prayer by mistake | Possible | Prevented |
| Messages with loss (penalty) framing | 2 | 0 |
Learnings
- 01AI speeds up the designer’s decisions; it doesn’t make them.The best results came when I wrote prompts like a handoff document: states, copy, constraints.
- 02Testing on a real device ends debates.One toggle versus two buttons became obvious once I had both versions in hand.
- 03Context sets the tone.In a sensitive, personal domain like faith, gamification should be a gentle nudge, never a penalty.
- 04Reviewing AI output is the designer’s job.The consistency gaps listed below only surfaced through an end-to-end UX review.
UX debt prioritised for the next iteration
- 01Ask for permissions in context.If notification permission is denied, the whole app is blocked. Ask when the first reminder is set, with a one-line benefit, and keep tracking working if it’s declined.
- 02Connect the widget to real times.The widget estimates the prayer from fixed hour ranges; it should match the location-based times in the app, and log without opening it.
- 03Make Settings real.“Use Current Location” fills in placeholder text and the chosen calculation method isn’t applied. Resolve location to a city in one tap and default the method by region.
- 04Localisation.Add a plain-language subtitle under each prayer name (“Dawn”, “Midday”) so newcomers aren’t expected to know the terms, and prepare the copy for translation.
- 05Calendar theme and accessibility.Hard-coded colours cause contrast problems in dark mode; status should also be shown by icon or pattern, not colour alone.
- 06Bring the puffer fish to life.Let it puff up when a prayer is logged, and add plants and friends to its aquarium as points grow. Replace the leftover mosque icon with the character.
- 07Validate.A moderated usability test with 5 users; measure the share of fully completed days and 7-day retention.