Written to be pasted straight into Stitch, Pencil or any other generative design tool. Two combined prompts for tools that want the whole thing at once, then eight individual screens for tools that work one at a time. The screen prompts stay deliberately brand-free so you keep getting divergent ideas. A separate brand-locked block near the bottom renders an idea in our actual system once you want that instead.
On purpose: every prompt ends without a visual direction, and the context block explicitly tells the tool to be opinionated about it. Run the same block through three different platforms and you should get three genuinely different looks. That divergence is the point of this exercise.
For tools that take a single input and do better with less hand-holding. Flow order, what each screen is, what it is for. The rest is left to the tool.
Eight screens in flow order, one short paragraph each. Start here.
Design a homeschooling app for families. The parent is the account holder. Children have no login of their own: the parent signs in, then hands the device over through a PIN switch, so the app has a parent mode and a child mode, and some screens differ completely between them. What it does: the parent sets up a child profile, the app generates a full term of lessons for that child, the parent approves it, and the child works through the term day by day. It also produces the compliance paperwork homeschooling families legally need. Who it serves: a time-poor parent who is not a trained teacher, and a child aged roughly 5 to 14 who works mostly unsupervised. They share one device. Design these screens, in this order. PARENT SETUP 1. Add a child. Four steps: name and year level, then what they love (interest chips), then what they are like (energy, how they learn best, solo or social, attention span), then confirm. Should feel like being asked about your child, not like filling in a form. 2. Parent dashboard. Readable in ten seconds. A greeting, one suggested next action, a card per child showing pace and this week's progress per subject, a flag when a child struggled or asked for help, and a compliance reminder when paperwork is due. Two routes off each child card: hand over the device, or review their work. HANDOVER 3. Switch to child. PIN entry, warm rather than corporate, clearly belonging to that specific child. Design the way back out as well; that direction needs a gate a young child cannot trivially pass. CHILD DAILY LOOP 4. Child home. One dominant next action, today's lesson with a single start control. Then pace for the term, a progress meter, an XP meter with streak and badges, and this week's subject checklist. 5. The lesson. Steps revealed one at a time so the child cannot skip ahead. An illustration, a materials checklist, explanation text, and questions typed into inline that autosave quietly. A help assistant in a persistent bubble, scoped to this lesson only. On the final step, a five-face confidence scale and an optional notes field. 6. Lesson complete. The badge earned and XP gained, then next lesson or back to today. The praise names what the child actually got right, never a generic "great job". 7. Progress map. Per subject, a winding trail of lesson nodes marked complete, next up, or not yet reached, with a milestone marker at the end and badges alongside. PARENT OVERSIGHT 8. Work review. A summary strip (lessons done this week, average confidence, lessons worth revisiting, help requests), then the actual work grouped by subject and week. Where a child struggled, tell the parent what to do about it and when to stop. Rules throughout: child mode contains nothing about money, plans, tiers or account settings. Parent mode avoids jargon and dense data tables. The parent must get value on day one, before configuring or approving anything. Do not apply a specific brand identity. No fixed palette, no chosen typeface. Treat the visual direction as completely open and show me something opinionated.
Five sentences. For tools with a small input box, or when you want maximum room for it to invent.
Design a homeschooling app used by a parent and their child on one shared device. The parent signs in; the child has no login and is handed the device through a PIN switch, so there is a parent mode and a child mode. The flow: the parent creates a child profile (name, year level, interests, how they learn), the app generates a full term of lessons, the parent approves it, the child works through it day by day, and the parent reviews the work and the compliance paperwork. The screens: add a child, parent dashboard, PIN handover, child home led by today's lesson, the lesson itself (steps revealed one at a time, questions answered inline, a help bubble), a celebration when it is finished, a progress map, and a work review for the parent. Child mode shows nothing about money or settings. Parent mode assumes no teaching background. No fixed brand, palette or typeface: treat the visual direction as open and be opinionated about it.
Paste this first. It sets up what the product is and who it serves.
Reusable. Paste once per session.
We are designing a Christ-centred homeschooling app for Australian families. The parent is the account holder. Children do not have their own logins: the parent signs in, then hands the device to the child through a quick PIN switch, so the same app has a parent mode and a child mode, and several screens render completely differently in each. What the product does: a parent sets up a child profile, the app generates a full term of lessons written around that specific child's interests and the way they learn, a real person reviews it, the parent approves it, and the child then works through the term day by day. The app also produces the compliance paperwork Australian homeschooling families legally need. Three things make it what it is, and they should be visible in the design: - It is Christ-centred. Scripture runs through the lesson content itself, not as a separate devotional bolted on the start of the day. - It is genuinely custom. Not a year level, not a generic scope and sequence. A term built around one child. - AI builds it, people stay in charge. A human reviews every term and the parent approves it before the child sees anything. The three people it serves: - The parent. Usually not a trained teacher, and often came to homeschooling because school was not working for their child rather than by choice. Time-poor, anxious about the legal side, wants to be taken seriously. - The child. Ages roughly 5 to 14. Works mostly unsupervised once started. In Australian data close to a third of home-educated children are autistic or have ADHD, so sensory load is a real design constraint. - Both share one device. Design constraints that matter: - Child mode must contain nothing about money, plans, tiers, or account settings. - Parent mode must be legible to someone who is not a teacher. No jargon, no dense data tables. - Faith should feel natural and lived-in, never performative. No stock piety, no crosses or doves used as decoration. - Do not apply a specific brand identity. No fixed palette, no chosen typeface. Treat the visual direction as completely open and show me something opinionated.
In the order I would draw them. The first two are where design effort compounds most.
The hub of the product. Everything routes through it. Draw this one first.
Design the home screen a child sees when they open a homeschooling app in child mode. It answers one question first: what do I do right now. Then it shows progress. Top to bottom: 1. Today. One clear next action. The lesson title and a single start control. This dominates the screen. 2. Pace. Whether they are ahead, on track, or behind for the term, with a supportive rather than punitive tone when behind. 3. Progress meter. Lessons completed out of the term total. 4. Rewards. An experience meter, a daily streak, and badges earned recently. 5. This week's subjects. A checklist of the current week's lessons, each marked done, up next, or not started. Earlier weeks are collapsed away. 6. A verse for the week, quietly present rather than shouted. Show it as a child mid-term with some work already done. Nothing about payment, accounts, or settings appears anywhere in child mode.
The product itself. If only one screen gets real design effort, it is this one.
Design the lesson screen a child works through in a homeschooling app. A lesson is delivered as a sequence of steps, revealed one at a time so the child cannot skip ahead. Only the current step is visible; completed steps collapse behind them. The screen contains: - An illustration for the lesson at the top. - A materials checklist, things to gather before starting. - A short Scripture passage tied to the lesson's theme, presented as part of the work rather than as a separate box at the top. - The current step: explanation text plus questions the child types answers into directly. - Answers save automatically as they type, with a quiet saved indicator. - A next control that advances one step. - A help assistant available the whole time as a small persistent bubble, scoped to this lesson only. It can be asked a question and answers in a thread. - On the final step only: a completion card asking how confident the child feels, on a five-point scale of faces, plus an optional notes field. Show the mid-lesson state: one step open, a question partly answered, the help bubble closed.
The celebration moment. The copy rule here comes straight out of the research.
Design the celebration moment shown when a child finishes a lesson in a homeschooling app. A modal or full-screen state. It shows any badge just earned and the experience points gained. Two ways onward: the next lesson, or back to today's plan. Important on tone: the praise must be specific about what the child actually did, not generic approval. Not "great job!" but naming the thing they got right. Write the copy that way. This is a Christ-centred product, so a short line of Scripture may appear here, but it should feel like encouragement rather than a lesson. Never preachy, never a second sermon.
Has to be readable in ten seconds by someone who is not a teacher.
Design the home dashboard for a parent in a homeschooling app, managing two children. The parent is not a teacher. This screen must be readable in ten seconds. It shows: - A greeting and this week's status in one line. - One suggested next action. - A card per child: name, how they are pacing, progress through the current week per subject, and a flag if something needs attention (a child struggled with a lesson, or asked for help). - Each child card offers two routes: hand the device to that child, or review their work. - A compliance reminder when paperwork is coming due. The parent must get something useful here on day one, before they have approved or configured anything. Do not gate the whole screen behind setup.
The screen that only exists because of our child model. No competitor does it quite this way.
Design the transition screen when a parent hands their device to a child in a homeschooling app. The parent taps a child's name and reaches a short gate before child mode starts: a four-digit PIN entry, warm rather than corporate, clearly belonging to that specific child. Also design the reverse: leaving child mode back to the parent's account. This direction needs a gate too, and it should be something a young child cannot trivially pass.
The parent's reason to keep paying. Currently our weakest screen.
Design the screen where a parent reviews what their child has actually done in a homeschooling app. A summary strip at the top: lessons completed this week, average confidence this term, how many lessons are worth revisiting, and how many times the child asked for help. Below, the work itself, grouped by subject and week, newest first. Each lesson expands to show what the child wrote, and any conversation they had with the help assistant. Critically: where a child struggled, the screen must tell the parent what to do about it and when to stop. Not just "Ruby seemed unsure." A specific action and a finish line.
The delight layer. Most likely to produce something unexpected.
Design a visual map of a child's journey through a term in a homeschooling app. Per subject, a winding trail of lesson nodes. Each node is either complete, the next one up, or not yet reached. A larger milestone marker sits at the end of each subject's trail. Badges earned this week sit alongside. Show it mid-term, roughly a third complete.
The funnel that decides whether anyone ever reaches a term at all.
Design a multi-step form where a parent creates their child's profile in a homeschooling app. Four steps, one per screen, with visible progress: 1. Name and year level. 2. What do they love? Selectable interest chips plus free entry. 3. What are they like? Energy level, how they learn best, whether they prefer company or working alone, attention span. 4. Confirm and create. This is the screen that makes the term feel personalised, so it should feel like being asked about your child rather than filling in a form. Show step 2.
Everything above is deliberately brand-free, and it stays that way. This block is the opposite, for when you want output that looks like the product rather than output that explores.
Use the brand-free prompts to find ideas, and this one to see an idea rendered in our actual system. Paste the context block, then a screen block, then this. If you paste this first you will only ever get variations on what we have already decided, which defeats the point of the exercise.
Light ground, one dark card, flame accent, Fraunces and Nunito. Matches /hybrid.
Apply this exact visual system. Do not invent a palette or pick your own typefaces. GROUND AND SURFACES The page is light. Warm cream #FDF8EE, never white. Most cards are white #FFFFFF with a 20px radius, a hairline #EFE4D2 border and a soft shadow. Body text #1B2436, secondary text #5A6478. THE ONE DARK CARD Exactly one card per screen is dark: #131E33, 22px radius, cream text #EFE8DA, secondary #A9B4C8. That card is always the next thing the user should do. A soft warm radial glow sits behind its top right corner. A glow is only ever used inside a dark card, never on the cream. THE ACCENT Flame #FFB454 is the primary action fill with #1B2436 text on it, and a 2px #D9862B bottom edge. Amber as TEXT or a link uses #8C5516 instead, because #FFB454 fails contrast on cream. Inside the dark card the primary button is #FFB454 with a warm halo around it. Amber is reserved for the lantern. No subject and no status may use it. TYPE Headings: Fraunces, weight 600, with SOFT around 80 and WONK on. Headings only, never body. Everything else: Nunito, weight 500 for body and 800 for labels and buttons. Body 1.0625rem at line-height 1.7. Exactly one accent-coloured phrase per headline, never two. SUBJECT COLOURS, used as a small spine or chip and never as a fill behind text English #D8604A, Maths #3D7FBF, Science #3E9E72, Humanities #9E63B8, The Arts #D4557F, Health and PE #3E9BA3 MOTION Transitions 180ms or less. Nothing loops, nothing autoplays, no parallax. Honour prefers-reduced-motion completely. This matters because close to a third of the children using this are autistic or have ADHD. BANNED Mascots. Cartoon illustration. Confetti. Leaderboards. Streak-loss warnings. Pure black or pure white as a text ground. Text over imagery. A third typeface. Crosses or doves as decoration.
Admin screens, the public marketing site, the state registration wizard and the compliance document generator. All four exist, all four are mapped on the flow map. None of them are where a fresh design idea is worth much right now. The wizard is already the most finished part of the product, and admin only has to be functional.
I also left the reference-hunting alone deliberately. I have Mobbin access now and could put real competitor screens in front of you, but doing that before you ideate would anchor you to how Khan and Duolingo already solved it. Go blue sky first. Bring concepts back and I will then pull the real-world comparisons against whatever direction you have chosen.
These are the findings that actually change what gets drawn, so they are written into the prompts rather than left for you to remember: