Four lessons with no App Builder at all. You meet Turnout's users, decide what version 1 includes, find the tables in the stories, and sketch the pages, so every later click has a reason.
How Part 1 works
You finish Part 1 with four short pieces of paper, real or digital: a list of user stories, a scope list, a list of tables, and page sketches. Part 2 turns the tables into SQL; Parts 4 to 9 turn the sketches into pages.
This part is deliberately tool-free: all you need is paper, or a notes app. Beginners who start in App Builder tend to build what the wizard offers instead of what their users need. Fifteen minutes of thinking here saves hours of rework later.
| Lesson | You produce | Used again in |
|---|---|---|
| 1.1 Users and stories | 15 user stories in “As a … I want … so that …” form | Every part |
| 1.2 Scope | In / later / out list for version 1 | Part 13 (what ships) |
| 1.3 Stories to tables | 12 table names with one-line purposes | Part 2 |
| 1.4 Page sketches | 5 sketches and a page-flow map | Parts 4, 7 and 9 |
Lesson 1.1 — Turnout's users and their stories
Outcome: name Turnout's five kinds of user and write what each needs as short user stories.
The question. Who uses Turnout, and what are they trying to get done?
The decision. Write every need as a user story: As a … I want … so that …. The “so that” is the important part: it's the reason, and reasons decide design.
The cast comes from the sample data, so you'll meet them again in every part:
| Who | Example person | What they care about |
|---|---|---|
| Visitor | Someone who just moved to Tampa | Finding a group to run with, without signing up first |
| Member | Grace Kim | Getting a spot, knowing where to meet, getting in at the door |
| Organizer | Priya Raman (Tampa Runners) | Posting events quickly, knowing who's coming, checking people in |
| Owner | Marcus Lee (Tampa Runners) | Running the club, choosing organizers, handing over one day |
| Site admin | The Turnout team | Approving new clubs, keeping the site healthy |
Fifteen stories, which the rest of the course builds:
- As a visitor, I want to browse upcoming events near me so that I can find a club without signing up first.
- As a visitor, I want to sign in with Google, Microsoft or GitHub so that I don't need another password.
- As a member, I want to join a club so that I can see and RSVP to its events.
- As a member, I want to RSVP and bring a friend so that we both have a spot.
- As a member, I want to join the waitlist when an event is full so that I get a spot if someone drops out.
- As a member, I want an email when I'm moved off the waitlist so that I know I'm going.
- As a member, I want a ticket on my phone so that check-in is quick.
- As a member, I want to see where we meet and the weather so that I arrive prepared.
- As an organizer, I want to create, publish and cancel events so that the club knows what's on.
- As an organizer, I want to approve people who ask to join so that our club stays the right fit.
- As an organizer, I want to scan tickets at the door so that I know who came.
- As an organizer, I want attendance numbers so that I can plan the next event.
- As an owner, I want to make members organizers so that I don't run everything alone.
- As a site admin, I want to approve new clubs so that only real clubs appear.
- As a Spanish-speaking member, I want Turnout in Spanish so that I can use it comfortably.
Try it. Write two stories of your own for a club you know. Keep the “so that” honest: if you can't finish it, the feature probably isn't needed.
Check yourselfWhy does every story end with “so that”?
The reason decides how to build it, and shows when a feature isn't worth building.
Lesson 1.2 — Version 1 scope: in, later, out
Outcome: sort features into version 1, later, and never, and explain each choice.
The question. Every club organizer has a wish list. Which wishes does the first version grant?
The decision. Version 1 covers the 15 stories from Lesson 1.1. Everything else waits, with a reason written down so the decision isn't argued again next week.
| Feature | Decision | Why |
|---|---|---|
| Clubs, events, RSVPs, waitlists | In | The core of every story |
| Social sign-in and email codes | In | Visitors won't create another password |
| Per-club roles | In | Organizer here, member there is how clubs really work |
| QR check-in and attendance | In | Stories 7, 11 and 12 |
| Weather and maps | In | Small to build, big help to members (story 8) |
| Spanish | In | Story 15, and it shapes how we write every label |
| Public REST API | Later | Useful once there are clubs to integrate with; its own part after version 1 |
| Recurring events (“every Saturday”) | Later | A good capstone: it touches the model, the API and the pages |
| Paid events and payments | Later | Needs a payment provider and refunds; too much for a first version |
| Chat between members | Out | Members already have group chats; Turnout links to them instead |
| Native phone app | Out | The web app works on phones; Part 9 makes sure of it |
Try it. Pick one “Later” feature and list which tables, packages and pages it would touch. That list is a rough cost estimate.
Check yourselfWhy write down the reason for each “Later”?
So the decision isn't reopened every week, and so it can be revisited when the reason no longer holds.
Lesson 1.3 — From stories to nouns: finding the tables
Outcome: find the tables hiding in the user stories, and spot the two that nobody mentions.
The question. How do you go from 15 sentences to a data model?
The decision. Underline the nouns. Each noun people want to keep, list or change is a candidate table; the verbs between them are relationships.
From stories 3, 4 and 9: As a member, I want to join a club … to RSVP to its events.
| Noun or verb in the stories | Becomes | Table |
|---|---|---|
| person, member, visitor, organizer | One kind of thing: a person | TO_USERS |
| sign in with Google, Microsoft, GitHub | How a person signs in | TO_USER_IDENTITIES |
| club | A thing with its own settings | TO_CLUBS |
| kind of club (running, chess) | A short list people pick from | TO_CATEGORIES |
| join, organizer, owner | A person's place in a club | TO_CLUB_MEMBERS |
| invite | A membership that doesn't exist yet | TO_CLUB_INVITES |
| where we meet | A place reused across events | TO_VENUES |
| event | A thing at a time and place | TO_EVENTS |
| RSVP, waitlist, ticket, check in | A person's place at an event | TO_RSVPS |
| email when I'm moved off the waitlist | A message to send | TO_NOTIFICATIONS |
| weather | Something fetched from outside | TO_EVENT_WEATHER |
Two lessons hide in this table:
- Roles are not nouns of their own. “Member”, “organizer” and “owner” sound like three kinds of person, but they are one person in different relationships. That insight becomes
TO_CLUB_MEMBERSin Lesson 2.4. - Some tables no story names. Nobody says “I want an audit log”, but story 5's waitlist will be disputed one day.
TO_RSVP_LOGcomes from asking “what will we need to prove later?”
Try it. Do the same for your two stories from Lesson 1.1. Which of your nouns already have a table here?
Check yourselfWhy isn't “organizer” its own table?
It's a role a person has in one club, so it belongs on the membership, not the person.
Lesson 1.4 — Sketching pages on paper
Outcome: sketch Turnout's five most important pages and draw how people move between them.
The question. What will people see, and how do they get from one page to the next?
The decision. Sketch first, on paper or a whiteboard, with boxes for regions and words for buttons. No colors, no fonts. A sketch takes two minutes to change; a built page takes an hour.
Five sketches carry most of Turnout:
| Page | Who | Must show |
|---|---|---|
| 1 Discover events | Everyone | Upcoming events as cards, filters by category and date |
| 20 Event page | Everyone | Title, time in the club's zone, meeting point map, weather, spots left, RSVP button |
| 35 RSVP | Members (dialog) | Guests, current status, cancel option |
| 31 My ticket | Members (phone) | Event, name, large QR code |
| 100 Club dashboard | Organizers | Upcoming events, RSVPs vs capacity, pending join requests |
Then connect them. This map is the plan Part 4 builds:
The page numbers aren't random: 1–29 are public, 30–99 need a signed-in member, 100–199 need an organizer, 200–299 a site admin. Anyone reading the app later knows who can open a page from its number alone.
Try it. Sketch page 20 for the Saturday Long Run (Saturday at 7:00 AM on Bayshore Boulevard, no limit on spots, up to 2 guests each; Priya is an organizer of the club, Grace is a member): what does Grace see, and what does Priya see that Grace doesn't?
Check yourselfWhy does a visitor reach the event page before signing in?
People decide whether to join after seeing what's on; asking for sign-in first loses them.
Part 1 quiz
5 questions. Get 4 right to pass. You can retake it as often as you like.