Helping students
get unstuck.
Keep them thinking.

Help at the moment a student needs it.

Students often work independently, outside the hours when a teacher or tutor is available. When they get stuck, they retry a problem, check notes, ask someone they trust, or turn to search, video, and AI tools. Their goal is immediate support, but getting an answer is not necessarily the same as understanding how to solve the problem. [3]

Stride K12’s AI Tutor provides on-demand learning support through homework upload, skill practice, and educator-assigned sessions. The experience combines step-by-step guidance with tools such as video, graphing, and a whiteboard. Educators can assign targeted practice and review student work and insights; guardian support and broader subject coverage were part of the expansion plans. [2]

That meant designing more than a chat window. Students needed to understand how to begin, use tools without losing the problem, and receive guidance that felt manageable when they were already confused.

I connected the interface to the tutor’s behavior.

I owned the UX/UI design and ran research, while partnering with researchers on additional studies. I influenced feature priorities with product, designed multimodal learning tools, and shaped how the tutor communicated with students—including step-by-step guidance, response length, and empathy.

To make those expectations implementable, I translated AIX guidelines into decision matrices and behavioral communication graphs, then worked directly with machine learning developers to implement them. This gave design and engineering a shared reference for decisions that otherwise risked becoming subjective discussions about tone or style.

Students wanted the help.
They needed a clearer path.

The August 2025 moderated study followed seven students in grades 8–10 through onboarding, problem solving, error recovery, progression, and ending a session. A post-session survey captured their perceptions. [4, pp. 2–3]

August 2025 · n = 7 · Moderated sessions and post-session feedback. [4, pp. 6–7, 15]

The enthusiasm did not erase the friction. Five of seven students did not finish the given problem during the roughly ten minutes allocated to problem solving. Two accepted incorrect tutor answers without recognizing the error. Students could value the help and still struggle to complete the task or judge the output. [4, pp. 9, 12]

Later research reinforced the same pattern: confidence shaped how students used the tutor. More confident learners explored and recovered from friction; less confident learners were more likely to pause when the next action was unclear. The January 2026 readout identified onboarding, prompt interpretation, tool expectations, latency, and reliability as recurring concerns. [5, pp. 5–6, 13–14]

Help students begin.

A useful tutor is hard to use if the student does not know what to do first.

What the research revealed

Students hesitated at the beginning, sometimes unsure where to type or whether to answer the tutor or a suggested prompt. The prompts were useful once understood, but some learners interpreted them as questions they were required to answer. [3, pp. 5, 12]

How I approached the design

I focused on orientation and clear next actions: explaining where to respond, making the relationship between the problem and conversation visible, and clarifying that suggested prompts were optional ways to ask for help. In the supplied interface, the opening message explicitly points to the assignment, the chat box, and the blue help buttons.

The tradeoff was how much to explain before learning begins. Too little orientation leaves students guessing; a long walkthrough adds another task before they can get help. The February testing plan therefore assessed the onboarding message directly: whether students would read it, whether it made starting easier, and whether they preferred a walkthrough or video. [6, pp. 3–4]

Support the work students do
between messages.

Learning happens in the scratch work, the graph, and the moment a concept becomes visible.

What the research revealed

Students asked for a whiteboard, videos, and richer graphing. They described switching between paper and the screen and wanting explanations close to the problem they were solving. The existing graph tool could also obstruct the equation and chat; students tried to move or dock it. [3, pp. 5–7]

How I approached the design

I designed multimodal tools as part of the tutoring workspace, with the problem, related media, and skill explanation organized alongside the conversation. Video offered another way into an explanation, while the whiteboard gave students a place to write and sketch within the experience.

The tradeoff: more capability, more to manage

Adding a tool does not automatically make the task easier. A tool that blocks context, behaves unexpectedly, or is difficult to find can add friction. Students’ expectation that Math Keys would calculate—rather than only enter notation—made that mismatch especially clear. [3, pp. 5–6]

See the graphing state and its design tension

Make the guidance manageable.

The response itself is part of the interface.

What the research revealed

Students valued step-by-step help that explained mistakes without doing all the work. But when they were confused, several wanted one question at a time rather than multiple requests in one response. Repetition and long explanations could leave them stuck even when the tutor appeared to be helping. [3, pp. 3–4, 13]

Tone preferences varied, too. Supportive correction worked well for many students, while some found excessive cheerfulness irritating. The evidence supported a more nuanced approach to empathy than simply making every response more enthusiastic. [3, p. 3]

How I translated feedback into behavior

I turned expectations for step-by-step guidance, response length, and empathy into AIX decision matrices and behavioral communication graphs. I worked with machine learning developers to implement those guidelines and adapted them as the system’s capabilities changed.

The research gave those rules a concrete purpose: keep the next request focused, make correction understandable, and use support that fits the student’s situation. The design tradeoff was between providing enough explanation to help and giving so much information that the learner could no longer identify the next action.

These are the research-informed design aims; the exact implemented thresholds and branch rules need the original guideline artifact.

Designing for a system
that kept evolving.

Initial requirements were ambiguous, and dynamic AI outputs made it difficult to define every interaction in advance. We worked iteratively: prototype an experience, observe how the system and students responded, and refine the interface and behavior together.

Early agent capabilities and latency constrained what the experience could reliably support. Engineering moved from larger agents toward smaller, specialized agents, including responsibilities for Socratic guidance and answer generation. I adapted the designs and AIX guidelines as those capabilities changed, working with product and engineering to keep the intended experience aligned with the system.

That engineering evolution belongs to the engineering team. My contribution was translating changing capabilities into interactions and behavior expectations students could understand. The retrospective also identified the need to distinguish prototypes, MVPs, and the desired end state, and to strengthen feedback loops for tutor responses. [7, pp. 2–3]

A promising pilot.
A clear boundary on the claims.

The product moved from beta testing into summer school pilot use. The September 2026 research overview reported that students reached a correct answer 80% of the time, with an engaged subsample reaching 93.3%. It also reported an average session of 9.25 minutes. These are product-level observations, not a before-and-after measurement of my design changes. [8, p. 4]

Sources: August analysis [4]; January readout [5]; May overview [2, p. 6]; September overview [8, p. 4]. These are separate reports and cohorts, not a single trend series.

The strongest claim about my contribution is specific: I owned the UX/UI, ran research, and worked with machine learning developers to implement AIX guidance. The product research shows why that work mattered and where it should continue—not that every positive result was caused by it.

Design the next action,
not just the next response.

This project reinforced that AI experience design includes what the system says, what the learner can do, and whether those two things make sense together. A supportive response can still fail if the graph hides the problem, the prompt is misread, or the student does not know where to start.

My most consequential contribution was connecting research to both sides of that experience: the interface students used and the behavior guidelines developers implemented. In an evolving system, the shared decision framework was as important as the screen design.

What I would evaluate next

I would test whether students can begin without moderator help, use visual tools without losing context, and recover from confusion after the response-guideline changes. To evaluate learning, I would look beyond satisfaction and supported correct answers to whether students can solve a new problem independently.