The User Manual

Part 1: the counter's card

This is the whole of page 1, and it is the page that matters most, because it is used by two people at the busiest moment of the day.

The counter, every day

Sign in at the canteen tablet with your own email and password. You stay signed in all day.

1. At 11:00, check the stock. Open the Menu page and read down today's dishes. Before the canteen has sold anything, no dish should say Sold out or Only 2 left. If any does, the owner has not set today's numbers: telephone her before the break. Nothing else in the day matters as much as this.

2. During the break, work the slot. On the Counter page choose the Pickup slot you are serving. The list updates itself every ten seconds; you never need to reload it.

For each order, in order:

| When | Tap |

| --- | --- |

| You begin making it | Start preparing |

| It is on the counter, waiting for the student | Mark ready |

| The student has taken it and paid | Collected and paid |

| The slot is over and nobody came | Not collected |

3. Use the kitchen list. Still to make on the same page counts what this slot still needs, dish by dish. Read it out to the kitchen at the start of each slot.

4. Read the order number aloud when the food is ready. It is the large number at the top of each order.

Two things you cannot do, and that is on purpose: you cannot change a price or the stock, and you cannot cancel a student's order. Only the owner sets prices and stock; only the student cancels, and only before you tap Start preparing. The owner's pages do not open for a counter account: the screen answers "Your account is not allowed to do that."

Everything in that card is a task the counter performs, in the order of the day, with the words that are on the tablet in front of them. Nothing in it explains how any of it works.

What the card cannot say, because the system cannot do it. The counter has no screen showing the stock numbers: the owner's pages are closed to a counter account, and the students' menu names a count only when a dish is down to single figures. Writing this page is what made that plain, so the 11:00 check reads the sold-out notes instead, which is enough to catch a morning the owner has forgotten, and a stock view for the counter went into the report's limitations and its future work (Chapter 66). A manual is a design review of its own kind: writing down what a user must do, step by step, finds the steps the system has not given them.

Part 2: the owner's morning routine

Assumption A-2 of Chapter 14 is the reason this section exists, and the reason it begins where it does. The stock is one number per dish and nothing resets it overnight, so the manual's first instruction of the day is to set it:

Your morning, before 11:00

1. Open the canteen page on your phone and Sign in.

2. Tap Owner. Everything in this part of the manual is on that one page.

3. Under Menu and today's stock, put today's number in the Stock left box for every dish you are offering, and tap Save on that dish. This is how many of it students may pre-order today. Food you sell over the counter to people who have not ordered is not counted here.

4. Put 0 against anything you are not making today, and it shows to students as Sold out. For a dish you have stopped making altogether, clear its On today box instead: it then reads Not on the menu today and comes back the day you tick it again.

5. Check the Price (₹) box of anything whose price has changed, and Save.

Why this is the first thing you do. The system holds one stock number for each dish, and it does not empty overnight. If you do not set today's numbers, students are offered yesterday's, and the kitchen will be asked for food you have not made. The counter staff check at 11:00 and will telephone you. A later version will store the date with each number so that an old one can never be offered; until then, this routine is the safeguard.

Then the tasks that come up less often, each in the same shape: Add an item (name, category, price in rupees, then set its stock), Add a counter staff account (name, email, a password of 8 or more characters, which you give them and they may change), and:

The day's takings, at closing

1. Tap Owner, and read Today's report. Its first line names the day and counts the orders on it.

2. Collected today is the total of every order a student collected and paid for today.

3. The table below it lists each Item sold, its Quantity and its Takings.

4. Orders that were placed and not collected are not in these totals. Nothing is owed for them.

The report counts pre-orders only. Money taken at the counter from walk-in customers is not in it, because the system never sees those sales.

That last paragraph is the sentence that saves a support call, and it is the kind of sentence only a manual carries: it says what the number does not include.

Part 3: students

Students get one page, because a queue does not read a manual. The team wrote it as a poster for the canteen wall and the same words on the college notice board:

Order lunch before the break

1. Go to the canteen page on the college Wi-Fi and Create an account with your college email and a password of 8 or more characters. You only do this once.

2. Sign in, and on Today's menu tap + for each dish you want, up to 5 of a dish and 10 items in all. Your order on the right adds up the Total.

3. Choose a Pickup time. A slot closes 15 minutes before it begins, so the 12:40 slot closes at 12:25.

4. Tap Place order. One order for each slot.

5. My orders shows your order and updates itself every 15 seconds: Placed, then Being prepared, then Ready to collect.

6. Collect it at the counter at your slot and pay there. Say your order number.

Changed your mind? Cancel this order on My orders, then Yes, cancel it. You can cancel until the counter starts preparing it, not after.

Six steps, no jargon, and it ends with the thing a student most needs to know: pay at the counter.

Part 4: when something goes wrong

This is the part students skip when writing and users turn to first. Each row is a message the system really shows, in the words it really uses:

Two rules for a table like this. Quote the message exactly, because the reader is looking for the words in front of them, not a paraphrase. And give an action, not an explanation: "wait fifteen minutes, or ask the owner" is help; "the rate limiter has been triggered" is not.

The half-hour that goes with it

Chapter 8 promised a training session, and the manual is what makes it short. The worked team's session, at the canteen, lasted thirty minutes: the owner set that day's stock herself while they watched, each counter person worked one slot's orders through the four buttons, the card went up beside the counter, and the last five minutes were the troubleshooting page, read aloud.

Watch, do not help, the rule of Chapter 54, applies here too. Every hesitation is a line of the manual to rewrite. Two came out of that half hour: the stock box needed the sentence about walk-in customers not being counted, and the counter card needed "you stay signed in all day", because Ganesh signed in again each time the tablet slept.

Who to call, and what it does not do

The last part of the manual is two pages that no student thinks to write:

• Who to call, with names: the team for the first term, the IT lab in-charge for the machine, and what each can help with.
• What the system does not do: no online payment, no delivery, no SMS, no notification when an order is ready, no orders from earlier days, no penalty for a student who does not collect. The same list as the report's limitations and future work (Chapter 66), in the reader's words rather than the examiner's.

Saying what it does not do is part of the manual, not an admission. A user who knows there is no notification looks at My orders; one who assumes there is, waits.

Where it goes

• Printed and taped beside the counter, which is the copy that gets used.
• An appendix of the report (Chapter 66), and a page of the submission (Chapter 73).
• In the repository, beside the project's other documents, so that it is versioned with the code it describes and a label that changes can be followed by the sentence that quotes it.

The README of Chapter 69 is a different document for a different reader: it tells a developer how to run the project. A user manual never mentions npm.

Do this for your project

1. List your users' tasks, in the order of their day, and make each one a section.
2. Write each task as numbered steps, one action each, with the screen's own words in bold.
3. Say what the reader should see after each step.
4. Put the daily work on one page, and print it.
5. Write the troubleshooting table from your code's actual messages, and give each an action.
6. Say plainly what the system does not do, and who to call.
7. Watch a real user follow it without help, and fix every hesitation.
8. Keep it with the code, and change it when a label changes.

Mistakes that cost marks

A manual that is the report again, with architecture and test results in it.

Screens described instead of tasks: "The owner page has four sections."

Paraphrased error messages, which the reader cannot match to what they are looking at.

No troubleshooting at all, which is the section users actually read.

Jargon: endpoint, payload, session, validation, transaction.

Labels that do not match the application, usually because the manual was written from the design and never checked against the built screens.

A booklet for a counter, when what was needed was one page.

Quick revision

• The manual is task-oriented, for the user, in the user's words and the screen's words.
• Report: how it was built, past tense. Manual: how to do your job, imperative.
• One action a step, say what success looks like, bold the screen's labels.
• The worked manual: the counter's one-page card, the owner's morning routine, the students' poster, the troubleshooting table, who to call and what it does not do.
• The owner's routine begins with setting the day's stock, and the counter checks it at 11:00: that is how assumption A-2 is guarded.
• Quote error messages exactly and give an action for each.
• Watch a user follow it; every hesitation is a defect in the manual.

Questions you must be able to answer

1. How does a user manual differ from a technical report? In reader, organisation and voice. The report tells an examiner or a developer how the system was built and why, arranged by the project's phases, in the past tense. The manual tells a user how to do their own work, arranged by their tasks, in the imperative, with nothing in it that the user cannot see on the screen.

2. Why is the manual organised by task rather than by screen? Because a user arrives with a job to do, not with a screen to explore. "Set the day's stock" is what the owner wants; "the owner page" is how the system happens to be laid out, and it may change.

3. Why must the manual quote the application's exact words? Because the reader is matching what they read against what is in front of them. A paraphrased button or a reworded error message costs them the one thing the manual is for, and it is also a sign the manual was written from the design rather than the built system.

4. Why does the worked manual begin the owner's day with setting the stock? Because the system holds one stock number per dish and nothing resets it overnight (assumption A-2). If the owner does not set today's numbers, yesterday's are offered to students. The routine, plus the counter's check at 11:00, is the guard the team chose for the first release, and the limitation and its proper fix are recorded in the SRS and the report.

5. What belongs in a troubleshooting section? The system's real messages, quoted exactly, each with what it means in the user's terms and an action to take. It should also cover the failures that show no message at all, such as a page that will not load because the device is off the college Wi-Fi.

6. Why does a manual say what the system does not do? Because a user who does not know waits for something that will never happen, or telephones about it. The same list as the report's limitations, written in the reader's words, prevents both.

7. How do you know the manual is good enough? One of its users performs the task from it, watched and unhelped, and does not hesitate. Anything they hesitate over is rewritten, which is how two sentences of the worked manual came to exist.