Last Spring I taught a User Interface Design course to 200+ engineering students and the thing they struggled with the most was not code, or prototyping, or critique. It was identifying a problem to solve.
The second half of the semester is one long build: a web application that teaches a classmate an introductory topic. Students can pick any domain they want — sports, music, cooking, chess — as long as the topic is focused enough to teach in under ten minutes, ends with a quiz, and uses the quiz feedback to keep teaching. Total freedom, three constraints.
Learning to choose is hard. Learning to choose well is harder. And learning to choose well in a world of unlimited possibilities is harder still, perhaps too hard. — Barry Schwartz, The Paradox of Choice
I’ve come to realize that the problem isn’t having too many options; it’s that they couldn't yet see the shape of a good one. So, I did what professors do and put up a slide — there's always a slide. Broad domains on top: chess, basketball, art history, music. Focused topics below: how to run a pick and roll in basketball, for casual NBA fans. How to tell impressionist paintings from post-impressionist paintings, for ArtHum students.
Look at the pairs. See the difference. Go and do likewise.
The shape of a good topic
"Basketball" is a domain — a territory some know. "How to run a pick and roll, for casual NBA fans" is a topic: a concept, a specific learner, and something observable that learner can't yet do. Too broad a topic is only half the problem. The course warns them explicitly: a topic must be small enough to learn in ten minutes but hard enough that your classmate doesn't already know it. Notice what every good topic carries that the bad ones don't: a learner, attached like a clause. Drop the clause and the same concept floats free — musical intervals are a great topic for casual listeners and a pointless one for music majors. Students sometimes copy the how to X shape and treat the for whom like decoration.
The thing is, an example only works if you can see what makes it good. To see why “pick and roll” is well-scoped, you have to know basketball. I don’t — it’s the example on my own slide, and I couldn’t tell you about it because it’s not my interest. Students who’ve played ball get it instantly. For everyone else, the example is noise. If they can’t see the scope then they cannot extract the pattern.
The example that actually works is the one built from what the student already knows. A student tells me they’re into mechanical keyboards, and we can get somewhere in five minutes: what does a beginner always get wrong? Could you fix that by just telling them, or does it take practice? By the end they don’t just have a topic — they’ve felt the difference between a territory and a teachable slice of one, from inside territory they know cold.
That conversation can’t be put up on a lecture slide. It has to be constructed live, one student at a time, inside whatever domain they walk in with — all 200+ of them.
So I built the conversation instead.
Discovery Coach
It has one job: have a conversation —any domain, any hour. Just as important is what it doesn't do. It will not pick the topic. It will not generate the domains or topics required for the homework assignment. It will not do the assignment. It’s a coaching agent, and making it behave like one is no simple task.
What is your job, again?
The first thing I did was write the job description for the agent. I kept it simple:
You are the User Interface Design Discovery Coach. Your purpose is to coach students through product discovery. You do not complete assignments. You help students think.
The rest of the job description is broken up into six parts that spell out for the agent what “good” means in this job, how the work gets done, and what gets them fired.
Playing in the sandbox
I pasted the instructions into Google AI Studio — a sandbox for testing agents before students ever see them — and set up a test log before running anything. A simple document, one entry per test run:
Student: what I typed
Result: what the coach did — right and wrong
Action: the diagnosis
Update: the new rule that went into the instructionsThe instructions file tells the coach what to do. The log, it turned out, would become a record of every way it found to follow the rules and still miss the point.
Test #1
Student: Hi. I'm taking User Interface Design. I have no idea what topic I should teach. I like basketball and chess. Can you help me?
Result:
It stayed in character
It followed the Process
It didn’t solve the assignment
It followed the feedback framework
It asked too many questions – four
It reveals the stages — students don’t need to see that
It sounds a little robotic
It answered too much
Action: Create a new section under Process called Conversation Guidelines and add the following rule.
Update: Guide students through one step at a time. Ask only one primary question per response. Wait for the student's answer before moving on. Keep it conversational, not survey-like. Do not overwhelm students with long lists of questions unless they explicitly request a comprehensive review. Avoid exposing internal implementation details such as "Stage 1" or "Stage 2" unless the student asks about the HW7 workflow.Every line is an instruction to do less.
Test #2
Student: Same opening message.
Result: The coach asked one question, but it also gave the student a little scaffolding. “Help me list 2 or 3 specific concepts…” is a good coaching prompt because it is concrete and easy to answer.
Student: I am working on brainstorm domains. I think my classmates might find these basketball concepts confusing 1. how to run a pick and roll confusing. 2. defense and defensive rotations and 3. reading a fast break
Result:
Action:
Have the coach ask only one domain at a time.
Update:
When students provide multiple possible domains, ask them to choose one before continuing. Do not ask them to develop multiple domains simultaneously.Test #3
Student: Same opening message.
Result:
Student: basketball
Result:
Student: How to run a pick and roll. Reading a fast break. Defense and defensive rotations.
Result:
It asked one primary question
It waited for the user response
It used my answer instead of jumping ahead
It narrowed the scope naturally
Action: Don't expose the process. Students don't need to know they're in "Stage 2.
It's drifting back into lists.
Update: Keep the internal coaching process hidden. Do not refer to stage names or stage numbers unless the student explicitly asks about the HW7 workflow. Do not expose your internal feedback framework as headings unless the student requests a formal review. Prefer natural coaching language during conversations.Three tests in, the pattern was unmistakable. I never once had to make the coach smarter. Every update made it quieter. These observations didn’t come out of nowhere — they’re a rubric someone had already written. "It answered too much" is a violation of what the linguist Paul Grice called the maxim of quantity: say as much as the exchange requires, and no more. "It sounds robotic" violates his maxim of manner — be clear, be natural, don't talk like a form.
The coaching agent showed up knowing how to brainstorm, how to scope, how to evaluate a topic against constraints — all of that came free with the underlying AI. What I built was everything it shouldn’t do.
What comes next?
I should be honest about what three passing tests prove: almost nothing. Every one of them had the same participant — me, playing the part of one of my students. I am the easiest student this coach will ever meet. I know what a good topic looks like; I wrote its job description; I can't be confused in the ways that matter.
So the next phase is design research, run the way I'd run any usability study — except the participants are fake and the prototype is a conversation. I'm writing a roster of student personas, one for each way this assignment goes wrong: the student with a domain and no topic, the student whose topic is trivia, the student who wants the coach to just do the assignment.
The one persona I expect to break it first: the student with an excellent topic who needs to hear yes — because so far I’ve spent every revision teaching this coach to push back, and a coach that can’t recognize good work is its own kind of failure. Each transcript gets scored against one question that outranks the rest: would this response actually help one of my students? It's the standard Erika Hall sets in Conversational Design — hold the system to the bar of a good human conversation partner — except my conversation partner is being graded on whether it teaches.
The fake students exist solely to break the coach before the real ones can.
Further reading: Erika Hall’s Conversational Design is the short, designer-friendly book on all of this; Cathy Pearl’s Designing Voice User Interfaces is the practical manual for turn-taking — the voice-assistant people solved one-question-at-a-time a decade ago because audio forced them to.