How pupils can design an AI school guide

During a project day, pupils can design an AI guide for school visitors that answers questions like these and addresses their needs. The most important part is not the artificial intelligence itself or the end result, but choosing reliable sources, writing answers, checking them thoroughly, meaningfully identifying needs and turning them into a working digital product prototype.

Start with questions people actually face at school

Begin by asking pupils what someone visiting the school for the first time needs to know. A new classmate is looking for the cloakroom and classroom, their locker, the library, canteen or after-school club. A parent needs to know where to bring an absence note or whom to contact. A visitor arrives for a school event and does not know which entrance to use. A teacher who joined in September is learning everyday procedures. Answers tend to be scattered across the website, noticeboards and documents — and often exist only in people’s heads.

Each group can choose one type of user. This avoids trying to create a guide that answers everything. A good pupil prototype does not need to know hundreds of answers. It is enough to provide reliable help in ten or fifteen situations the school genuinely encounters.

Preparing data — a guide is only as reliable as its sources

To avoid answering solely from AI’s general knowledge, the guide needs its own school-approved knowledge base. Gather materials from the school website, school rules, contacts, the school-year calendar, absence procedures and frequently asked questions from parents and pupils. Let pupils find these sources during the project day. This can produce useful materials as well as a valuable discussion about the guide’s purpose.

These materials are not entered into an AI tool’s ordinary public chat. An administrator or teacher uploads them to a separate environment accessible only to the school and the application itself. When a visitor asks a question, the system first finds the relevant passage in the school documents and then uses it to compose an answer. It can also identify the document it drew on. If it cannot find the information, it should not make it up: it should openly acknowledge that it does not know and direct the visitor to a specific contact.

The guide itself can run as a simple web application built, for example, in Lovable. With a little patience, even a less experienced teacher can create a separate knowledge base. For this project, however, we recommend using only test or public information, because AI processes both the data and the documents. Never use documents containing personal data, photographs of pupils or photographs of real personal documents.

Before pupils open an AI tool, they must collect source materials. They can explore the school website, operating rules, building map, admissions information or materials for parents. For each piece of information, they note where it comes from, who can confirm it and how often it changes. Dates, contacts and rules need particular attention: an incorrect answer here could genuinely mislead a visitor.

It helps to divide information into three groups: public and stable; public but subject to change; and non-public. The first group is suitable for the prototype. The second needs a last-updated date or a source link. Non-public information must not be entered into public AI tools. This gives pupils practical experience of protecting information that is more useful than a general safety warning. The guide can consist of just a chat window, so there is no need to spend much time designing the user interface. However, interface design can become a separate part of the project, for example in art lessons.

Pupils then prepare a simple version of the guide, design its knowledge base and test whether its answers match the actual school documents. Public deployment is a further step that requires school approval, a content administrator, security measures and regular updates to the source materials.

Test prompts just like any other part of the prototype

Only once sources are ready should groups try out how the guide might respond. One group prepares questions from a new pupil, another prepares parents’ questions, and a third tries to catch the system out with vague or overly broad wording. Look not only at accuracy, but also at whether the guide admits when it does not know something and directs users to the right person.

Pupils will quickly see that even a well-written instruction does not guarantee a correct result. They must compare every answer with the original source.

Finish by having someone outside the team test the guide

Groups can exchange prototypes or invite classmates who were not involved in preparing them. Testers receive a specific situation and phrase their own question. The creators observe whether the guide understands the question, whether its answer helps and where misunderstandings occur. Record not just system errors, but also questions the team never considered during preparation.

The day does not have to produce a finished chatbot. Its outcome might be a verified set of questions and answers, a simple conversation flow and rules for a future guide. For a school, this is often more useful than an impressive demonstration whose answers nobody has checked.

Collecting feedback from other teachers or classes can also help, for example through a simple star rating. If the project day works well, the outcome can be incorporated into the school website or School Digital Studio and followed by further projects described in other blog articles.