Building Your Chatbot Assistant

A Design Thinking Approach

1. The Mindset: Process over Product

You aren't just writing code or prompts. You are training a digital assistant. Approach this project with a Process over Product Mindset:

View this process as a continuous interview. You discover how to talk to your AI to get better results, and you learn about your own blind spots in communication.

Project Brief

  • You will build a chatbot in Mizou or Google Gemini Gems that helps a user practice a Habit of Mind.
  • Choose one habit from this list: Meeting deadlines, Managing impulsivity, Thinking flexibly, Metacognition.
  • Your bot should ask questions, guide a quick reflection, then give one small action for the user to try. It should ask better questions, not just give answers.
  • You must pass Gate A (Ready to Build) before building and Gate B (Tested & Improved) before submitting.
  • You will test your bot with at least one other person and make at least one improvement.
  • You may use GenAI tools to help you on Step 2 Define and Step 3 Ideate only.
  • You will submit your bot link, your completed Project Worksheet (PDF/screenshot), and a 60–90 second screencast demo. QuickTime Player is an easy option.

2. The Process: Design Thinking

1. Empathy
2. Define 🤖
3. Ideate 🤖
4. Prototype
5. Test

ChatBot Template (use this structure)

Your bot is designed to help a user practice a habit. To do that, it needs to ask questions before giving suggestions.

Required conversation structure:

  1. Ask 2 questions (before giving advice)
  2. Explain the Habit of Mind briefly (define it and what it looks like in real life)
  3. Get the user to name their current state + desired state (“What’s happening right now?” “What do you want to be able to do instead?”)
  4. Give 1 small action the user can do right now (2–8 minutes)
  5. Ask 1 reflection question (what changed?)

Reminder: the AI only does what you tell it.

  • What to be like: role + tone (persona)
  • What to do: the job + the required conversation steps
  • What not to do: guardrails (what it must refuse or avoid)

Required Documentation

You must complete the Project Worksheet. That worksheet is your documentation.

Everything you need to include (user, pain point, bot plan, guardrails, success criteria, safety check, and peer test + improvement) will be written directly on the Project Worksheet.

Submission Requirements

Submit on our LMS:

  1. Mizou or Google Gemini Gems so the teacher can test it
  2. Project Worksheet (completed): submit as a screenshot or a downloaded PDF
  3. 60–90 second screencast demo: show the bot in action and how it supports the chosen Habit of Mind

Build a Chatbot Project Planner

Complete this worksheet before building your bot.

Student Name:

Project Choice

1. Empathy

2. Define 🤖

How do you know the engagement was successful? How should it conclude?

What data would it be risky to share with your bot?

3. Ideate 🤖

Bot Template (fill this in)

Gate A: Ready to Build (Teacher check)

Before you build in Mizou or Google Gemini Gems, show sections 1–3 to the teacher. If approved, the teacher fills the Teacher Approval box at the bottom.

  • User + pain point are specific
  • Habit is chosen (one of the 4)
  • Conversation structure is planned
  • Guardrails are written

4. Prototype

Build your bot using your plan above. You may use either Mizou or Google Gemini Gems. If working in pairs, only one of you needs to open an account.

4A. MVP build notes (Version 1)

MVP = Minimum Viable Prototype. That means the smallest working version that follows the required structure. It does not need to be “good” yet. It just needs to work.

  • It starts with a welcome/hook
  • It asks 2 questions before giving any advice
  • It explains the Habit of Mind briefly (what it is + what it looks like)
  • It asks the two prompts (current + desired)
  • It gives 1 small action (2–8 minutes)
  • It ends with 1 reflection question
  • Guardrails are in place (it won’t do the work for the user)

5. Test

5A. Test scenario (guardrail check)

Example: "I will demand the bot just tell me what to do. The bot should ask two questions first and then give one small action."


5B. Peer test + improvement

5C. Final bot link (V2 after improvements)

Gate B: Tested + Improved (Teacher check)

Show proof of the peer test and your one improvement before final submission. If approved, the teacher fills the Teacher Approval box below.

Teacher Approval (Screenshot Evidence)

You must pass Gate A and Gate B, before handing in your assignment.

Gate A: Ready to Build

Gate B: Tested + Improved

Project Rubric (100 points)

5 criteria × 20 points each. Performance levels: Not Meeting Expectations, Approaching Expectations, Meeting Expectations (Low), Meeting Expectations (High), Exceeding Expectations.

Criteria (20 pts each) Not Meeting (0–7) Approaching (8–10) Meeting Low (11–13) Meeting High (14–16) Exceeding (17–20)
Design Thinking Application Little to no evidence of user consideration; “solution looking for a problem.” User/pain point unclear or missing. User is mentioned but vague or generic. Pain point is unclear or not specific enough to guide design. User is identified. Pain point is mostly clear. Bot purpose generally connects to the user’s need. Evidence of user empathy. Problem is clearly defined. Bot purpose and design choices mostly match the user’s specific pain point. Evidence of deep user empathy. Problem is sharply defined. Solution directly addresses a specific user pain point with clear, intentional design choices.
Habits of Mind Coaching Content The habit is unclear or mostly missing. The bot mainly gives generic advice or “motivational talk.” Little evidence of practice, reflection, or habit-focused questioning. The habit is mentioned but is still vague. Bot sometimes focuses on advice more than practice. Action/reflection is inconsistent or weak. The habit is present but sometimes vague or inconsistent. The bot sometimes slips into giving answers too quickly. The action/reflection exists but may not clearly support practice of the habit. The bot teaches/practices the chosen habit (more than advice). Usually asks better questions before suggesting anything. Provides a realistic small action and ends with a reflection prompt. The bot clearly teaches/practices the chosen habit (not just advice). It consistently asks better questions before suggesting anything. It provides a realistic small action and ends with a reflection prompt that makes thinking visible.
LO3 (combined): Media Production (Write + Design & Produce) Purpose and target audience are unclear or inconsistent. Limited or inappropriate use of chatbot conventions. Product lacks focus and/or does not hold attention. Little evidence of design/planning/reworking. Limited control of production technology. Purpose/audience is stated but not well matched. Some conventions used but choices feel random/inconsistent. Some planning visible; limited reworking. Control of tools is uneven. Crafts a media text and chatbot for a specified purpose and audience. Conventions mostly appropriate. Product has focus and some creativity. Some evidence of design/planning and some reworking. Mostly practised control of production technology. Crafts a clear media text and chatbot for a specific purpose and audience. Uses appropriate conventions and mostly holds attention. Clear evidence of design/planning and reflection/reworking. Strong control of production technology. Crafts a clear media text and chatbot for a specific purpose and audience. Effective control of chatbot conventions and media language. Sustained focus, creativity, and well-considered choices that hold attention. Clear evidence of planning, reflection, and reworking. Consistent, precise control of production technology.
Bot Functionality (Prototype) Bot fails to load or does not perform the basic task requested. Bot sometimes works but is unreliable or confusing. Guardrails/persona/logic frequently break. Bot generally works but breaks character easily. Guardrails are weak or easily bypassed. Bot works reliably most of the time. Persona is mostly consistent. Guardrails usually hold and the flow is logical. Bot adheres to guardrails. Persona is consistent. Handles inputs logically and effectively guides the user.
Process Evidence (Documentation + Testing & Iteration) Documentation missing or sparse; no mention of challenges or safety. No evidence of testing or improvement. Documentation minimal and mostly descriptive. Missing Gate A and B. Testing mentioned but evidence weak/unclear. Improvements minor or not linked to feedback. Basic documentation present, but may be missing Gate A or B; lists steps but limited reflection on why. Testing mentioned; no clear change based on results. Documentation mostly complete with some reflection. Evidence of testing included. At least one improvement clearly linked to feedback/failure. Detailed log of decisions, challenges, and safety review. Clear evolution from V1 to Final. Clear evidence of testing scenarios and documented changes based on feedback/failure.

Note

To reach Meeting High or Exceeding in Process Evidence, include peer testing evidence and at least one improvement based on what failed or what a peer reported.