Student Companion

Research & Methodology

Our approach combined several methods to build a grounded understanding of the problem space. We ran stakeholder interviews, a Qualtrics screener survey, in-depth student interviews, and a Wizard of Oz pilot study. Each method was chosen to fill a specific gap in what we knew.

Phase I: Discovery & Context

About the Client

Unisys is a global technology company with an existing product called Student Companion, a GenAI tool built to help students search through textbooks. The product handled textbook Q&A well, but it didn't touch the everyday service journeys students actually struggle with. Our goal was to expand it into a platform capable of handling financial aid, IT support, and academic advising through a single conversational interface.

Archetype Mapping & Journey Prioritization

To scope the work, we ran a workshop mapping service journeys across two axes. The first was domain (Academic Success, Administrative Services, Financial Support, Technology Access, Career & Community) and the second was service pattern (Guidance/Q&A, Troubleshooting, Scheduling, Case Management, Proactive Notifications). Working closely with Unisys leadership, we narrowed 25 potential areas down to three priority journeys: Academic Advising, IT Service Requests, and Financial Aid. We made these cuts by cross-referencing our initial qualitative observations with Unisys's strategic goals which made sure that we targeted high-friction user pain points where the business could deliver immediate value.

Surveys & Interviews

To validate early assumptions and explore the student experience, we deployed a Qualtrics screener survey followed by semi-structured interviews with four Cornell graduate students. The screener confirmed our baseline: 67% of students sometimes walk away without getting an answer, citing "not knowing who to ask" and "scattered information" as the biggest barriers.

Our in-depth interviews revealed two distinct types of friction:

• Academic Advising: Answers take anywhere from 2 days to 3 weeks. 60% of interviewees reported near-miss errors with real financial or academic consequences (e.g., almost missing an insurance waiver deadline). Furthermore, graduate students resent using valuable advisor meeting time for administrative questions.
• IT & Administrative Troubleshooting: "Not knowing who owns the problem" causes students to bounce between offices, and re-explaining the issue at every handoff compounds frustration. Opaque resolution timelines lead many to give up entirely rather than navigate the paperwork loop.

"Google usually pulls up PDF handbooks from 2018."

"Two misses and I delete the app."

"It feels really scattered, and it's hard to tell which source is the most current or official."

"I'd also use it late at night when offices are closed, because that's when it's most frustrating to not know what to do next."

Phase II: Pilot User Study

Before moving into the pilot testing, I designed a comprehensive Figma prototype based on the user journeys mapped in Phase I. To test this, my teammate built four targeted mockups based on my prototype and ran usability tests with 30 Cornell students. Each participant experienced all four conditions, which allowed us to compare reactions directly rather than relying on implications.

Baseline Prototype & User Journeys

Below are the initial user journeys and corresponding prototype flows I designed to map out the core interactions before we tested access preferences.

The Four Conditions

1. The Specialized App gave each topic type its own entry point, requiring students to categorize their own question first.
2. The Unified App presented one general Q&A interface and handled routing internally.
3. The Email-Style Mockup framed the interaction as a formal, asynchronous Gmail-like experience.
4. The Chat-Style Mockup used a Teams-like interface for a low-friction, synchronous feel.

Key Findings

• Students preferred the unified interface. They don't want to classify their own questions.
• Chat was the preferred channel over email, feeling more natural and lower-friction.
• Canvas is the strongest integration point. Students want the service where they already work.
• Students valued bullet-pointed answers with embedded links and a Sources section.
• Contingency steps were significantly more useful than confidence scores.

Strategy & Design

Our strategy translated discovery insights into a structured product specification, combining technical architecture with a robust governance framework for responsible AI.

Product Definition

I authored the PRD that translated discovery insights into a structured specification, covering the capabilities to build, the metrics to track, and the business case for investment. This gave the team a shared reference point as we moved into design and architecture.

Prioritized Capabilities

Feature 1: Q&A Academic Adviser

Students ask questions in plain language and receive answers with source citations, including the document name, section, and a direct link. When the system isn't confident, it flags the limitation and routes to a human with full context pre-filled. We set a target of 95%+ response accuracy based on what students told us would make them trust the tool.

Feature 2: Troubleshooting Support

A single entry point for IT, HR, Facilities, and enrollment issues. The system classifies the problem, delivers step-by-step guidance, and if it can't resolve the issue, generates a pre-filled support ticket with an estimated response time. The 60%+ self-resolution target was grounded in our ticket analysis, which showed most submitted issues were procedural rather than complex.

Key Success Metrics

The primary targets were 95%+ response accuracy for the Q&A Adviser and a 60%+ deflection rate for Troubleshooting. Secondary metrics included escalation accuracy (correct routing), follow-up rate (repeat queries indicating incomplete resolution), time-to-resolve, and handoff quality (specifically whether staff found the pre-populated ticket context actionable).

Where the 60% Deflection Target Comes From

To ensure the friction points identified in our qualitative interviews represented a scalable business case, I analyzed 4,109 historical IT support tickets going back to 2020 at Cornell. The data confirmed what interviews had suggested. 18.76% of tickets met near-certain deflection criteria, 21.49% had a repetitive title, and 97.91% were classified as low or medium priority. Most of the support workload was procedural rather than complex, which meant a well-built RAG system had a realistic path to handling the majority of it.

Based on my analysis of these 4,109 historical tickets, a 60% deflection rate translates to about 600 hours of Level-1 support time saved. At the same time, this reduces student wait times from days to under 30 seconds which transforms the service experience while also allowing the university to reallocate support staff toward complex escalations.

The issue categories with the clearest deflection potential included computer-related issues (11.27%), printer-related (6.72%), access/account issues (6.55%), classroom AV (5.30%), Adobe licensing (4.48%), and VPN (1.58%). All had repeatable, documentable resolution paths, the kind of content a RAG knowledge base is built to handle.

What Changes for Students

• A unified RAG knowledge base provides instant, cited answers to policy questions, replacing a fragmented landscape of central and department websites.
• The companion classifies questions and routes students to the correct person internally, removing the need to navigate college-specific directories that varied across departments.
• A single conversational intake creates a pre-populated ITSM ticket upon escalation, replacing an inconsistent support process that varied by office.
• Estimated response times are surfaced at the point of escalation, giving students visibility into resolution timelines that were previously not communicated.

Design & Architecture

I designed the complete MVP prototype and mapped the end-to-end integration architecture connecting the student-facing interface to backend systems. The prototype covers the complete interaction flow from onboarding and topic selection through the Q&A interface, troubleshooting walkthrough, and escalation handoff. Core design goals throughout included reinforcing trust, keeping source citations always visible, confidence indicators surfaced, and the path to a human advisor always accessible.

Integration Architecture

To ensure the interface decisions could be implemented, I mapped the full system architecture from the moment a student asks a question to when they receive an answer or are connected to the right person.

• Student access layer (web, mobile, chat)
• Authentication & session management
• Conversational interface layer
• Natural language understanding + distress detection
• Query type classification (Financial Aid, Academic, IT/Technical)
• RAG retrieval from Academic Policies, IT Troubleshooting, and Financial Aid knowledge bases
• Confidence scoring & routing decision engine
• Output paths: cited responses, student record updates, ticket generation, session analytics

Responsible AI & Governance

I authored the responsible AI framework covering how the companion should handle high-stakes decisions, protect student data, and address risks specific to AI in a university context. The framework was structured to align with Unisys's existing corporate AI principles while addressing university-specific concerns not covered there.

Alignment with Unisys Corporate AI Principles

• The system is scoped to defined student benefit and complies with FERPA, CCPA, and ADA Section 508.
• AI identity is disclosed at session start, all responses surface cited policy sources, and low-confidence answers are flagged explicitly.
• Bias audits run across demographic personas, with a 95%+ citation accuracy target enforced through human QA sampling.
• Human escalation is mandatory for all consequential decisions and any detected student distress.
• PII scope is limited to the session, data is encrypted, and strict vendor processing agreements are in place.
• The interface meets WCAG 2.1 AA standards, supports multiple languages, and is built mobile-first.

Hallucination Mitigation & Citation Accuracy

We set explicit quality targets to keep the framework accountable. The targets include 95%+ citation accuracy verified through human QA sampling, <2% hallucination rate for transactional guidance, 100% source link availability via automated link checks, and 100% escalation for any query falling below confidence thresholds.

Escalation Routing

Escalation paths were defined for each domain. Academic advising questions route to the advising queue (<1 day SLA). Financial aid disputes route to Financial Aid staff (<2 days). Tier 2 IT issues generate an ITSM ticket (<6 hours). Detected student distress triggers an immediate transfer to counseling, with no automated delay and a required confirmed human handoff.

Data Privacy & Governance

• FERPA requires that student education records cannot be disclosed without written consent.
• Under CCPA, students have rights to know, delete, and opt out of data sale.
• ADA Section 508 requires that platform interfaces are accessible to users with disabilities.
• Only data necessary for the immediate request is collected, with no caching of sensitive records beyond session scope.

Cybersecurity Disclosure Ethics

The framework also defined disclosure timelines for adverse events. Confirmed AI quality failures affecting a student outcome are disclosed within 24 hours. Unauthorized access to student PII within 48 hours. Security intrusions are flagged for immediate escalation. Systematic bias patterns affecting an identifiable student group are reviewed and disclosed within 5 business days.

Responsible AI Risk Summary

• Model hallucination in high-stakes policy responses is mitigated via confidence thresholds and human QA sampling. (Medium likelihood, High impact)
• Bias in financial aid guidance is addressed through bias audits, diverse persona testing, and SME reviews. (Medium likelihood, High impact)
• FERPA violation via unintended data disclosure is prevented through strict data minimization and legal review. (Low likelihood, Critical impact)
• Student distress escalation failure is managed with sentiment guardrails and a mandatory human transfer protocol. (Low likelihood, Critical impact)
• Outdated policy content causing incorrect guidance is addressed using versioned RAG and 30-day content review cycles. (High likelihood, High impact)

Launch & Operations

I designed the pilot plan and operating model to define how the expanded Student Companion would be validated, measured, and scaled. The goal was to move from a student research prototype to a structured, replicable deployment across university campuses.

Pilot Plan

The pilot is designed for a CSU campus already operating Student Companion, running over 12 weeks across four phases with a cohort of 200–500 opt-in undergraduate and graduate students. It covers all three prioritized features: Q&A Academic Adviser, Troubleshooting Support, and Financial Aid Support.

Phased Rollout

Roles & Responsibilities

To ensure clear accountability during the pilot and beyond, I mapped every key operational activity against the five stakeholder groups involved in the deployment. This RACI matrix defined who was driving each area and who needed to stay informed with the intent of reducing gaps during go-live.

Measurement Framework

Six primary metrics were identified for the pilot. Deflection rate (>60%) is tracked weekly. Citation accuracy (>95%) and hallucination rate (<2%) are reviewed bi-weekly. Escalation accuracy (>90%) is tracked weekly. Student satisfaction (>4.0/5 CSAT) is collected on an ongoing basis, and distress escalation (100% confirmed transfer) is verified per incident.

Scaling Decision Criteria

At the end of the pilot, results feed into a binary go/no-go decision for campus-wide rollout. Go thresholds include deflection rate above 60%, citation accuracy above 95%, student satisfaction above 4.0/5, and no unmitigated critical incidents. Falling below 40% deflection, 90% citation accuracy, or 3.5 CSAT, or any confirmed distress or PII failure, would block scale-out and trigger a feature iteration cycle before re-evaluation.

Reflection

What I Learned

• The responsible AI framework and pilot plan were the most strategically demanding artifacts I produced on this project. Research findings and design decisions carry limited weight in a client context without a credible plan for getting from prototype to production. Building those documents taught me how to make that case by grounding targets in real data, defining governance structures that reduce institutional risk, and giving stakeholders the specific criteria they need to commit resources.
• Several critical workstreams on this project didn't have a clear owner as things moved from discovery into delivery. The integration architecture, the operating model, and the governance structure all needed someone to take them on, so I did. That turned out to be where I made the most substantial contributions, and it reinforced something I'll carry forward. A PM's value is often highest in the spaces the playbook hasn't covered yet.
• Working through the responsible AI framework before the product was built changed how I think about AI product design. Defining what the system is and is not permitted to do, who is accountable when it fails, and how disclosures are handled before you start building means those decisions actually shape the architecture rather than getting layered on afterward. That process convinced me that governance work upfront is where a lot of the real product thinking happens.