Turning AI principles
into decisions
teams can use.
Creating a shared AI experience framework that connects learner needs with chatbot behavior, interface choices, and evaluation criteria.
Guidance created and organized; implementation collaboration recorded in the source document. Project dates, evaluation results, and adoption evidence are still to be added.
A shared standard
for an unpredictable experience.
AI products need design intent that survives beyond a screen. A tutor can respond differently to the same question, and the right response depends on a learner’s age, reading ability, and emotional state.
Stride’s teams were building AI learning experiences without an established internal experience standard. Broad expectations such as “be empathetic” and “provide helpful guidance” left important decisions open to interpretation. The CoE’s charter identified fragmented experiences, duplicated effort, inconsistent quality, and difficulty scaling as the problems it aimed to address. [1][2]
Turn human-centered AI principles into decisions teams can implement, discuss, and evaluate.
I created and organized the AI Experience Center of Excellence (AIX CoE), establishing the organization’s first shared AI experience guidelines. The framework connected chatbot behavior, communication, accessibility, and interface recommendations in a reusable reference for designers, product managers, and ML engineers.
Creating the standard.
Connecting it to implementation.
I owned the CoE’s structure and guidance: age-specific communication matrices, behavioral flowcharts, emotional-response guidance, evaluation criteria, and interface recommendations, including support for nonreaders.
I also worked with ML engineers to translate the guidance into AI Tutor behavior. My influence covered response length, step-by-step guidance, empathy, encouragement, and age adaptation. I defined the desired experience and made it actionable for the people implementing it.
What I owned
The shared framework, its organization, and practical resources connecting learning and UX needs to implementation and evaluation.
What collaborators owned
PMs owned priorities and feature scope. ML engineers owned model and agent implementation; engineering owned architecture and interface development. Research partners contributed studies and findings. Product designers applied the guidance within their products.
The leadership contribution was a shared reference for concrete decisions: what should the tutor do when a learner is confused, how should it encourage different age groups, and what would count as meeting those expectations?
Add the project timeline, first publication date, and version of the guidance shown here. These details were not supplied.
Principles were the starting point.
Team needs made them specific.
The initial framework drew on prior internal UX research on AI and Microsoft’s HAX guidelines, as recorded in my case study document. AI Tutor response testing then supplied stakeholder feedback, while business requirements defined expectations for communication across age groups. [1]
As implementation progressed, ML engineers identified a specific need: criteria that AI judges could use to evaluate tutor conversations with simulated AI student agents. I expanded the framework from descriptions of desirable behavior into age-specific guidance and individual evaluation questions.
That evolution mattered because “helpful” was too broad to guide a consistent implementation. Teams needed to discuss recognizable behaviors and review whether a response exhibited them.
Add the internal UX research report, exact HAX reference, dated response-testing feedback, and business age-group requirements. Pair an earlier guideline with its revision to show how a specific finding changed the guidance. The source document describes these inputs but does not include the underlying records.
Give principles
an operational layer.
A principle can set direction. A concrete behavior can guide implementation. An explicit question can support evaluation.
I chose to pair human–AI interaction principles with resources that teams could apply directly: communication matrices, response flowcharts, and a Boolean question matrix.
The alternative: principles alone
A principles-only framework would have left room for product-specific judgment. But it would also have left engineers to interpret expectations such as “age appropriate” and “empathetic,” making implementation and review depend on individual readings of the same guidance.
The choice: make expectations inspectable
I broke those expectations into age-specific behaviors, possible response paths, and yes/no questions. That gave design and ML teams a more explicit reference for discussing a response, while keeping the principles as the rationale behind it.
Structured criteria make expectations easier to apply, but binary answers cannot capture every nuance of a conversation. The matrix supports evaluation; it does not replace contextual judgment or research with real learners.
Define what support
looks like in context.
Adapt the communication, not just the wording.
The communication matrix organized guidance across K–5, grades 6–8, and grades 9–12. It differentiated explanation, inquiry, emotional support, and reinforcement: simpler language and approachable encouragement for younger learners; more inquiry and reassurance for middle school; reflection and independence for high school. [3]
These were authored starting points for implementation, rather than a claim that every student in an age band has the same needs.
Turn encouragement into a response path.
The struggle flowchart mapped different situations: a student does not understand, gives a wrong answer, or says the task is too hard. Each branch connects an initial response to what the student does next—more practice, another hint, a slower explanation, or a break. [4]
This gave engineers more than a tone instruction. It showed how support should change when the learner continued to struggle, rather than treating encouragement as a generic phrase added to every answer.
Make “supportive”
a question teams can inspect.
The Boolean matrix responded directly to the ML team’s request for a checklist that could be provided to AI judges evaluating tutor conversations with simulated student agents.
I translated communication expectations into individual yes/no questions, grouped by behavior and age band. For supportive behavior, the matrix distinguishes positive reinforcement for younger students, acknowledgment of effort for middle school, and motivation that avoids sounding patronizing for high school. [5]
Encourage persistence.
The tutor should help a learner keep trying when a task is difficult.
Respect maturity.
For high school students, encouragement should avoid a patronizing tone.
Inspect the response.
Does the chatbot encourage students to keep trying without sounding patronizing?
The operational change was from “we want a supportive tutor” to a shared set of expectations teams could examine. The matrix’s creation is documented; its execution and effect on review quality or effort remain unverified.
Add the evaluation configuration, dated run logs, sample conversations, and ML owner confirmation. Include comparison with human review to assess whether the questions produce useful judgments. Simulated conversations alone cannot establish the experience of real students.
Support extends beyond
the chatbot’s words.
A framework for learning AI also needs to consider how students access the conversation. Text-based support alone cannot serve learners who do not yet read independently.
Make nonreader support part of the framework.
I included guidance for audio narration, speech input, verbal feedback, and step-by-step spoken microinstructions. The goal was to support participation through listening and speaking, with recommendations for adjustable voice speed, tone, and language. [6]
Connect the task to the interaction pattern.
The interface guidance considered full-screen, embedded, and floating experiences, along with placement, invocation, and dismissal. It described when deeper assistance may need a dedicated workspace and when a lighter interaction could support a quick question. Age-related recommendations provided another starting point for teams to consider. [7]
Organizing behavior and interface guidance together helped frame the experience as a whole: what the AI says, how users reach it, and how they remain in control.
A shared reference
between design and ML.
I worked with ML engineers to apply behavioral guidance to the AI Tutor, translating expectations around response length, step-by-step support, empathy, encouragement, and age adaptation into implementation discussions. This collaboration is recorded in my case study document. [1]
The Confluence hub brought the work into one place: strategy and charter, an AIX guidelines library, safety and ethics resources, an AI UX toolkit, and research resources. The supplied hub marks the toolkit as work in progress. Its existence establishes an organized reference; it does not establish how often teams used it.
Add dated ML implementation records and a before-and-after tutor response tied to a specific guideline. Identify the model or agent version, what changed, and how the response was evaluated.
A documented foundation.
Impact still to verify.
The concrete deliverable is a shared, organized framework with implementation and evaluation resources. The supplied screenshots show the hub, behavioral flows, communication matrices, nonreader support, and evaluation questions.
My source document records collaboration with ML engineers to implement AI Tutor guidance. It also mentions broader adoption in its status summary, while its detailed outcome section says adoption has not yet been established. I therefore leave that claim open until adoption records clarify the scope.
| Change | Evidence | Status |
|---|---|---|
| Shared AI experience guidance was created and organized. | CoE hub and supplied guideline screenshots. | Documented deliverable |
| Behavioral guidance informed AI Tutor implementation. | Ownership and collaboration described in the case study document. | Reported; implementation records to add |
| A Boolean matrix was created for ML evaluation needs. | Matrix screenshot and recorded engineering request. | Documented deliverable; use unverified |
| Communication became more consistent or age appropriate. | No comparative response evaluation supplied. | Intended benefit |
| Review effort decreased or adoption expanded. | No confirmed efficiency or adoption records supplied. | Not established |
Add teams and products using the framework, dated examples of decisions it informed, and evaluations of implemented responses. For any efficiency claim, include the task, baseline, timeframe, and measurement method.
Reusable guidance needs
a path into the work.
The most consequential shift was recognizing that principles alone could not carry the design intent into model behavior. Teams needed an operational layer: age-specific expectations, response paths, and questions that fit their implementation and evaluation workflows.
I learned to make the guidance specific enough to support decisions while acknowledging the limits of that specificity. An age band cannot describe every learner, and a yes/no question cannot explain an entire conversation.
What I would evaluate next
I would trace a small set of guidelines through implementation, compare AI-judge judgments with human review, and observe how real learners experience the resulting responses. I would also ask product teams which resources they use and where they still need to reinterpret the guidance. That would show whether the framework is useful in practice and where it needs to evolve.
The contribution was creating a bridge between design intent and engineering decisions. The next step is to verify the quality of that bridge in the experiences it supports.
Evidence behind the story.
Ownership, rationale, collaboration, and evidence limits come from the AIX case study document. The supplied screenshots establish the resources shown here. Underlying research, implementation records, and evaluation results remain clearly marked for addition.
- AIX Case Study.docxProject scope, ownership, decision rationale, ML collaboration, and outcome limitations. Project dates and version not supplied.
- AI UX Center of Excellence hub“where the coe actually lives.png” · Confluence purpose, problem, and resource structure. Toolkit labeled work in progress.
- Age-Appropriate Communication MatrixSupplied screenshot · section 1.3, page 6.
- Encouragement During StrugglesSupplied screenshot · behavior flowchart, section 1.2b.
- Boolean Questions Matrix for AIX EvaluationSupplied screenshots · section 1.5. Displayed artifact is the behavior portion of the matrix.
- Supporting Non-Readers in Chatbot InteractionsSupplied screenshots · section 1.6, beginning on page 9.
- AI Interface Design GuidelinesSupplied screenshots · interface selection, floating-widget guidance, and age-related recommendations.