Finding Out What It Has to Do
Ask, Don't Imagine
The prototype could be built from imagination, and it was: you pictured a person booking a slot, and the picture was close enough. The version real people rely on cannot be built that way, because imagination reliably produces the average case, and real life is made of the other kind. So the first work of this stage is conversation, not construction. Talk to the person whose business this is, and to the people who would use it. Ask what actually happens, not what should happen. You are not gathering feature requests — you are learning the shape of the job the software has to do. An hour of asking saves days of building the wrong thing beautifully. The groomer knows things about Saturdays that no amount of staring at your own screen will surface, and she will tell you, if you ask.
- Imagination built the prototype; it cannot build the reliable version
- Talk to the owner of the business and to the people who would use it
- Ask what actually happens, not what should happen
- An hour of asking saves days of building the wrong thing well
What a Booking Really Is
Spend a morning watching the business, and the product changes shape in front of you. The phone rings mid-groom, so bookings are taken with wet hands or missed entirely. Saturdays are chaos: everyone wants ten o'clock, and nobody wants February. Regulars book the same slot every six weeks, and would be puzzled to be asked for details the groomer already knows. None of this was visible from inside the prototype. And notice what a booking becomes once people rely on it. On your screen it is a row of text. In the world it is a promise two people plan around: the groomer sets aside an hour and turns other work away; the owner books the afternoon off and tells the dog, who has opinions. Software that holds promises has a different job from software that displays rows, and this whole course is about the difference.
- The phone rings mid-groom; Saturdays are chaos; regulars have habits
- None of this was visible from inside the prototype
- A load-bearing booking is a promise two people plan around
- Holding promises is a different job from displaying rows
The Requirements Nobody Volunteers
The most important requirements are the ones nobody volunteers, because to the people living with them they don't feel like requirements — they feel like weather. Ask the groomer what the system must do and you will hear about booking slots. Watch for a week and you find the rest. Cancellations, and the question of how late is too late. The dog that isn't well on the morning. The customer with two dogs who books one slot and expects both done. The week in August when the shop closes, which the calendar must know about, or the page will happily sell appointments that cannot happen. None of these are rare cases to the business; they are Tuesday. Your job at this stage is to collect them while they are cheap — a line in a plan — rather than later, when each one is a day of rework.
- The quiet requirements feel like weather to the people living with them
- Cancellations, the unwell dog, the customer with two dogs
- The August closure the calendar must know, or it sells impossible slots
- Collect them now as lines in a plan, not later as days of rework
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.