Inside ImaginAi: Designing an AI Learning System Around How Students Actually Study

Start from the study session

A feature list can describe what a product contains while leaving the learner’s journey unclear. The more useful unit for design is a bounded session: what brought the learner here, what they are trying to understand and what would allow them to stop with a useful result. That result may be small: identifying the missing step is already different from staring at an unfamiliar solution.

The public ImaginAi overview describes guided learning, exercises, quizzes, corrections and progress tracking for learners. For teachers, it describes class management, reporting, resources and activities. These are the confirmed product areas used in this article; they should not be read as evidence that every possible connection between them already exists. [1]

From that starting point, a design review can ask where a learner changes mode and whether the context survives. Does an explanation lead to an appropriate attempt? Does a correction help identify what to revisit? Each transition needs a purpose. Adding another screen without clarifying that purpose can increase the amount of navigation without improving the study session.

Different questions need different learning modes

Explaining a concept, attempting an exercise and reviewing a correction place different demands on the learner. An explanation needs a clear structure. Practice needs room to try. Review needs a way to compare the attempt with what was expected. A conversation can support these activities, but it should not dictate every interaction.

A useful design hypothesis is to make the next step easier to recognize. After an explanation, that might mean a related exercise. After a correction, it might mean revisiting one concept. These are proposed transitions to evaluate, not an assertion that a particular automated recommendation system is deployed in ImaginAi.

Consistency matters across modes. The wording of a topic, the level of the material and the purpose of the task should remain understandable as the interface changes. A learner should not need to restate their entire problem simply because they moved from reading an explanation to attempting a question.

Learning material changes the meaning of an answer

An exercise belongs to a context: a lesson, an instruction, a method or an expected level. An answer that ignores that context can be technically plausible while failing to help the learner follow the work in front of them. Product design should make it possible to establish the relevant material before interpreting the question.

If a future workflow accepts a document or an image, that would introduce additional questions: was the content read correctly, is a diagram missing, which page supports the explanation and is the material appropriate to use? Those checks belong in the design of such a workflow. This article does not claim that document analysis or a particular upload experience is currently available.

Even without adding a new input mode, the principle is useful. Make the subject, activity and instruction clear. Ask for clarification when the task is ambiguous. Avoid presenting an unsupported interpretation as if it came from the learner’s course material. Good context reduces the distance between an answer and the work it is meant to support.

Practice needs a path back from the answer

A correction should do more than mark an endpoint. It should help the learner locate the difference between their reasoning and the expected approach. That can mean comparing one step, clarifying a definition or returning to a simpler example. The interface should make that return possible without treating every mistake as a request for a longer explanation.

In a proposed evaluation, we would distinguish seeing a correction from using it. Can the learner explain what changed? Can they attempt a related task with less help? Such questions would require a proper study design before supporting claims about learning. They are more informative product questions than counting how many generated answers were displayed.

There is also a pacing decision. Too much explanation can overwhelm the immediate task; too little can leave the learner guessing. A useful review should examine the minimum support that enables the next meaningful attempt, with a clear way to ask for more. That balance should be evaluated across subjects and levels rather than fixed by one universal response length.

Teachers remain part of the system

A learning product does not need to replace the teacher’s judgment to be useful between lessons. It can help organize practice and make questions easier to identify. The teacher experience should support interpretation: what activity took place, what information is available and what still needs a conversation with the learner.

UNESCO’s guidance places human agency and pedagogical suitability at the centre of educational AI. For our product thinking, the implication is to evaluate support in relation to teaching and learning, rather than assume that more automated output is inherently better. [2]

Connecting learner and teacher experiences also requires decisions about visibility. A private question, an assigned activity and a progress report may need different sharing rules. Explain those rules and avoid collecting information simply because it could fill a dashboard. The value of a teacher view depends on whether its information is appropriate, understandable and actionable.

Progress should help someone continue

Progress tracking is part of the public product scope. The design challenge is what a learner can reasonably infer from it. Completed activities can describe participation, but they should not automatically be presented as mastery. A useful indicator states what it measures and supports a decision about what to do next.

For a future iteration, one question is whether the product can help someone return to a specific unfinished task without reconstructing the whole session. Another is whether review can connect a recurring difficulty to an appropriate next activity. These are directions for investigation; their usefulness and feasibility need to be established rather than assumed.

Continuity does not require keeping everything forever. Retention, shared-device use and the ability to remove personal material belong in the same design conversation. A learning history is useful only if people understand it and can rely on the boundaries around its use.

1. Does the learner understand the purpose of the current activity?
2. Is the next step clear after an explanation or correction?
3. Does a progress indicator say what it actually measures?
4. Can the teacher interpret the available information without overreading it?
5. Are proposed capabilities clearly separated from the current product?

The next product lesson needs evidence

The ecosystem gives us a coherent place to ask these questions, but it does not answer them automatically. A responsible product story should distinguish what exists, why a design choice is worth exploring and what evidence would justify the next decision. It should also be willing to describe a trade-off without presenting it as a solved problem.

Future accounts of changes in ImaginAi should be grounded in documented user feedback, permission to share the context and a clear description of what was observed. We have not introduced those claims here. The purpose of this article is to make the product logic visible and to define the questions that deserve investigation. See the ImaginAi product overview.