01 / Context
The problem and my role
Students may need help with registration, fees, documents, or university services without knowing which office or source to consult. The product concept brings common topics into one starting point.
I worked on the problem definition, support journey, knowledge-base structure, and prototype. The experience demonstrates a conversation, quick topics, and a ticket summary for cases that need more help. It is independent portfolio work.
Student
Find relevant guidance and understand what to do next.
Support staff
Receive a clear account of the issue instead of restarting the conversation.
The experience at a glance
- 01Choose a topic or ask a question
- 02Find relevant guidance
- 03Clarify an uncertain request
- 04Prepare a handoff when needed
02 / Product judgment
The choices that shaped the work
The central question
When should an assistant answer, clarify, or hand the question to a person?
01Make frequent topics easy to start
Offer quick actions for common student support needs.
- Why it matters
- A student should not need to invent the right prompt before receiving help.
- The tradeoff
- Topic coverage and wording need testing against the questions students actually ask.
02Treat uncertainty as part of the journey
Ask for clarification or escalate when the available information is not enough.
- Why it matters
- A plausible answer can still send a student to the wrong place.
- The tradeoff
- Escalation adds work for staff, so both answer quality and handoff quality need evaluation.
03Preserve the issue in a summary
Collect the relevant issue details and demonstrate a ticket summary.
- Why it matters
- The next person needs context to continue helping.
- The tradeoff
- A generated summary does not establish that a university office received or resolved a ticket.
03 / Evidence
What the prototype makes testable
The product concept separates a browser demonstration from the service operations a university would need.
| Journey | Demonstrated behavior | Operational requirement |
|---|---|---|
| Common questions | Quick topics and a conversational support flow | Approved, maintained sources and answer-quality review |
| Unclear requests | Clarification and escalation path | Rules for what staff should receive and how quickly |
| Handoff | Issue and ticket summary | A connected service desk, ownership, and confirmation of receipt |
04 / Evaluation
What I would measure and why
Measures to review or validate next. These describe the evaluation approach, not achieved improvements.
| Measure | What to examine | Why it matters |
|---|---|---|
| Answer quality | Review answers against approved university information. | Check correctness and relevance before optimizing for fewer escalations. |
| Task resolution | Ask whether the student found the correct next step. | A completed conversation is not necessarily a resolved issue. |
| Handoff usefulness | Have support staff review sample issue summaries. | Check whether the summary contains enough context to act. |
05 / Outcome
Where the work stands
The result is an accessible prototype for reviewing the support experience, with quick topics, conversation flow, and escalation summaries. Live university integration and measured service improvements are outside the demonstrated outcome.
What comes next
My takeaway
A support product needs a good path through uncertainty. Knowing when to clarify or hand over is part of providing a useful answer.
Based on the student support concept, prototype scope, and portfolio documentation.