How to Design a Public AI Literacy Course

What the launch establishes — and what it does not

On 6 September 2026, the University of Hawaiʻi announced a free, open-access, self-paced course called Artificial Intelligence for Hawaiʻi. The university described twelve chapters moving from foundations and responsible use into education, strategy, workplace practice, and local applications. It also said the course uses videos, hands-on activities, Hawaiʻi-based examples, and guidance informed by people working with Hawaiian values, culture, language, and community knowledge.

That is useful launch evidence. It tells us what the institution says it has made available, who may enter, and how the curriculum is organized. It does not yet show how many people will participate, who will complete the course, whether disabled learners can use every activity, how knowledge will transfer to real decisions, or whether the experience changes practice. A thoughtful public AI course begins by keeping those two forms of evidence separate.

Launch evidence is not outcome evidence. Availability describes an opportunity. Learning evidence shows what people can understand, judge, and do after using it.

The distinction matters because public AI literacy is too important to be measured by registrations alone. Institutions need to design for access, learning progression, local relevance, responsible practice, human support, and honest evaluation from the beginning.

Start with the public, not the platform

The first design question is not which AI product to demonstrate. It is who the course is for and what decisions those people need to make. A public audience may include educators, students, government staff, nonprofit workers, small-business owners, parents, and community members. They enter with different devices, schedules, languages, prior knowledge, and reasons for learning.

Write a short audience map before writing lessons. Name the people who are likely to arrive confidently, those who may be uncertain, and those who may be excluded by the default design. Then specify the minimum learning action. A beginner might need to explain what an AI system can and cannot infer. An educator might need to judge whether a classroom use preserves learner thinking. A manager might need to identify where private or sensitive information should not be entered.

Open registration is only one layer of access. Test mobile use, keyboard navigation, text enlargement, captions, transcripts, contrast, language load, and the amount of data required. Offer a low-bandwidth route where possible. State prerequisites in plain language. If a task assumes a paid account or a powerful device, provide an equivalent way to examine the same idea.

The technology-adoption checklist offers a useful companion question: what new effort does the course create, and is that effort justified by the learning purpose?

Build a progression from concepts to guided practice

A public course needs more than a sequence of features. It needs a learning progression. Begin with a small conceptual model: what the system receives, what it produces, why outputs may vary, and where human judgment remains necessary. Give learners a chance to predict an output before seeing one. Ask them to compare responses, identify missing context, and explain what would need independent verification.

Only then move toward practical use. A staged pattern can repeat across the course:

• Notice: identify what the system appears to do and what information it uses.
• Predict: state what a useful or risky output might look like before generating it.
• Try: complete one bounded task with clear constraints.
• Inspect: check accuracy, bias, relevance, privacy, and the quality of reasoning.
• Revise: improve the prompt, the source material, or the human decision.
• Transfer: perform a similar task without step-by-step guidance.

This rhythm protects the learner’s role. The AI study-partner framework makes the same principle practical for individual study: attempt first, compare deliberately, and finish with a learner-made artifact.

Treat local culture and community knowledge as design inputs

Local context should change the course, not merely decorate it. Examples determine whose work feels visible. Language choices affect who can participate. Data choices determine what knowledge may be exposed or distorted. A public institution therefore needs a process for deciding which community materials are appropriate for AI-supported activities and which should remain outside them.

Create a small review group that includes educators, learners, accessibility expertise, privacy or information-governance staff, and people with relevant community knowledge. Ask the group to examine scenarios, not just policy statements. What happens when a learner enters a culturally sensitive story? How should the course discuss language resources that models may reproduce inaccurately? Which examples might invite stereotyping? Who can approve a revision when a lesson causes harm or confusion?

Consultation is not a guarantee that every decision will be right. It is a structure for making assumptions visible, documenting trade-offs, and improving the course when new evidence appears.

Make responsible use part of every practical task

Responsible AI should not be confined to one final ethics chapter. It belongs inside the work. A research activity should require source checking. A writing activity should distinguish assistance from authorship. A data activity should identify information that must not be entered. A media activity should examine consent, representation, and the possibility of deceptive output.

For each practical task, add four short prompts: What could be wrong? What information should remain private? Who might be affected by the output? What human check is required before use? These questions make responsibility operational rather than abstract.

Institutions should also be clear about environmental cost and tool dependence. Learners do not need a precise energy estimate for every prompt, but they should understand that digital services use physical infrastructure and that more generation is not automatically better learning. Activities should have a reason, a boundary, and a stopping point.

Keep human support visible in self-paced learning

Self-paced does not have to mean unsupported. A public course can provide clear orientation, worked examples, common-error explanations, and a route for reporting inaccessible or confusing material. It can also create optional community sessions or educator-led practice without making synchronous attendance a requirement.

Human support is especially important when a learner encounters uncertainty rather than a simple wrong answer. AI literacy includes judgment about ambiguity, bias, evidence, and consequences. Those questions benefit from dialogue with people who can ask why a decision was made and help the learner examine an alternative.

Support also needs boundaries. State what the course team can answer, expected response times, and where learners should seek help for account, privacy, accessibility, or safeguarding concerns. A visible support map builds trust more effectively than a generic promise that help is available.

Collect evidence that matches the learning claim

The evaluation plan should begin before launch. Registration counts describe reach. Completion describes persistence through the course. Satisfaction describes experience. None of these alone demonstrates AI literacy.

Use several modest measures instead of one inflated success number. Ask learners to explain a system limitation in their own words, critique an output, revise a risky workflow, and apply the same principles to a new context. Repeat one task after a delay to see whether the reasoning remains available. Invite learners to report where the course changed a real decision and where it did not.

Publish the limits with the results. If the course has high reach but low transfer, say so. If one audience benefits and another faces barriers, report the difference. Honest evidence makes the next version more useful.

Use a launch checklist that leaves room for revision

Before release, the course team should be able to answer a concise set of questions:

• Is the audience and minimum learning outcome explicit?
• Can every essential activity be completed through an accessible route?
• Does the sequence move from concepts to guided practice and independent transfer?
• Have local examples, language, and community knowledge received appropriate review?
• Are privacy, evidence, authorship, bias, environmental cost, and human responsibility embedded in tasks?
• Is human support visible, bounded, and reachable?
• Are registration, completion, satisfaction, skill, and transfer measured separately?
• Is there a named process for corrections, accessibility fixes, and curriculum revision?

A public AI literacy course is not finished when the lessons are uploaded. Launch creates the first opportunity to learn how the design works for real people. The institution’s responsibility is to observe carefully, report modestly, and improve the course without turning access into a claim of success.

Explore more evidence-aware guidance in AI & Learning, or browse the full EdTechLear library.