Role: UX Research Intern · Timeline: May – Aug 2026 · Methods: Contextual Inquiry, Agentic Evaluation, Usability Testing, Thematic Analysis

This project is under NDA. Specific findings, user insights, and product recommendations cannot be disclosed. What follows is an overview of the research structure and methods employed.

Overview. As a UX Research Intern, I led three end-to-end research studies spanning generative research, agentic usability evaluation, and moderated usability testing across the Sensor Fusion and Tracking Toolbox and a Simulink product.

Context. Technical computing environments such as MATLAB and Simulink present unique UX challenges when conducting UX Research: users are domain experts, workflows are highly non-linear, and software interaction models increasingly blend traditional GUIs, coded solutions, and autonomous AI agents. In this environment, conducting UX research involves understanding these unique workflows and adapting traditional methodologies to the research context in order to derive insights that can drive product impact.

Process. Before running sessions, I spent the first week getting technically ready to interview domain experts and fluent in the team's internal processes, leaning on AI to compress that ramp-up. From there, the internship combined two research tracks running in parallel: generative research to inform workflow requirements and capabilities within the Sensor Fusion and Tracking Toolbox, and an evaluation of how autonomous AI agents perform on the same category of work. Following the completion of these 2 projects, I took on a third project which involved Usability Testing for a Simulink product, planned and executed during the remainder of the internship period.

Project 1: Requirements Research for SFTT. The objective was to inform requirements for core workflows and capabilities within the toolbox. Because these were highly specialized internal experts rather than a general participant pool, recruiting relied on referrals through developer and engineer contacts. I ran contextual interviews with domain-specialist engineers and thematic analysis translating recurring friction points into prioritized requirements, working closely with the developer on the project throughout. As a result of rapid analysis and enablement through agentic AI, I was able to synthesize qualitative user insights into actionable design and architectural recommendations, and establish clear baseline mental models for how specialized engineers map intent to system execution.

Project 2: Agentic Capability & Usability Evaluation. Run in parallel, this track evaluated both traditional user interaction and agentic AI capabilities in executing multi-step technical workflows within the same toolbox, via a three-stage evaluation loop — mapping human intent and task scenarios, benchmarking agentic execution and workflow performance, and analyzing the resulting usability gaps and capability mismatches — through workflow mapping, capability benchmarking, and gap analysis. At the end of the project I presented the team with evidence-backed areas of focus for AI usability for the toolbox features and a reusable framework to evaluate how automated agents navigate domain-specific toolbox structures.

Project 3: Usability Testing for a Simulink Product. Following the parallel research and evaluation work, the final stretch of the internship focused on a third study: usability testing for a Simulink product. My objective was to evaluate the user experience, feature discoverability, mental model alignment, and workflow continuity for the product, primarily through moderated remote usability testing sessions, through 8 task-based sessions and thematic analysis of recurring issues. At the end of my project, I delivered prioritized design revisions, feature-level user feedback, and UI recommendations directly to design and engineering leads for the product, identifying critical navigation paths that required further iteration to reduce cognitive load during complex tasks.

Innovation. Beyond executing research studies, I focused on optimizing how qualitative insights are delivered and consumed across technical organizations: tailoring standard UX research deliverables to mirror MathWorks artifacts, structuring research taxonomies and thematic findings into standardized, machine-readable formats to streamline cross-functional insight sharing so teams could query user feedback and research insights on demand without having to parse unfamiliar files, and partnering directly with developers, product managers, and customer-facing engineers to ensure recommendations respected technical constraints while keeping user intent front and center.

Outcomes.

“I have to say I'm impressed by the use of Agentic AI in reporting your findings.” — Project Sponsor, UX Research Manager, MathWorks. My Sponsor and UX Research Manager during my internship at MathWorks.

2 — Product spaces researched · 1st — Structured agentic usability evaluation on this product

MathWorks taught me that the hardest users to research are the ones who are best at the tool. Expertise doesn't just reveal what works - it conceals what doesn't. The real job was learning to read the workaround as the finding, not the fluency.

Rethinking traditional usability for agentic usability workflows was my biggest learning experience of this internship. Without an existing playbook, I had to reason from first principles about how to evaluate product performance when an automated system rather than a human user executes complex tasks. Designing a structured, defensible evaluation model and seeing it adopted as a reusable template across the team validated that the methodology landed.

Role: UX Researcher · Timeline: 2 Months - Summer 2025 · Tools: Figma, Miro, Google AI Studio

Overview. I led UX research to map emergency coordination workflows between public safety and utility companies, proposing an AI-enhanced shared operating picture that reduces response delays, improves field safety, and supported a $100K grant application.

The Problem. Even when every minute counts, public safety and utility crews still operate on entirely different systems, maps, and timelines. When disasters strike, public safety relies on dispatch logs and whiteboards, while utilities depend on localized outage dashboards. With no shared system, coordination defaults to analog phone calls and emails. Hazards linger, restoration is delayed, and crews on both sides face unnecessary, life-threatening risks.

The Users. From emergency command centers to the field, coordination breaks down differently for each user group. We grounded our research in the realities of emergency operations directors, fire department leadership, technologists, and field data scientists. For a commander, the priority is a high-level operational picture; for a field crew, it's knowing exactly which downed power line is still live.

Our Vision. What if every agency, from the EOC commander to the utility crew could see the same live map without abandoning the systems they already rely on? We weren't trying to replace dispatch logs, outage dashboards, or radios. Instead, our vision was a shared common operating map that for the most part maintains itself through automated integrations pulling in updates from existing systems, monitoring live radio traffic using transcription powered by OpenAI's Whisper, and automatically updating the map with status changes. We defined three guiding principles through the project: public safety continues using their CAD or GIS systems; utilities continue using their outage management tools; AI ingests those inputs (plus radios, transcripts, and reports) and updates the common operating picture in real time. The result is a shared picture of the incident visible to any agency without forcing a system overhaul.

What is TAK. The Team Awareness Kit (TAK) is an open-source situational awareness platform originally developed by the U.S. Air Force. At its core, TAK is a live, shared map that shows the real-time location of people, hazards, and assets across an incident. TAK runs on Android (ATAK), Windows (WinTAK), iOS, web, and even wearables. Users can drop pins, draw perimeters, and broadcast alerts, all of which appear instantly for others on the same feed. A rich plugin ecosystem allows TAK to ingest new data sources (like outage systems, drones, or air quality sensors) and integrate with external systems. In practice, TAK has already been deployed at scale in Colorado, Texas, and California. For our project, TAK served as the canvas where AI could do its work: transcribing radio chatter, ingesting outage management data, and automatically updating the shared map so that both public safety and utilities could trust they were seeing the same picture.

The Process. This project was about laying the foundation for the project while mapping how coordination really happens today, and where we could make a difference. In preparation for a funded proposal with a national telecommunications utility provider, IU RedLab was exploring foundational research on how TAK could support real-time coordination between utilities and public safety. Our role was to map the workflows, surface pain points, and gather evidence to guide future solutions.

As part of this effort, we conducted five in-depth interviews with emergency operations directors, fire department leadership, technologists, and data scientists. These conversations gave us frontline stories of coordination breakdowns from command staff juggling multiple maps, to utility crews waiting in unsafe zones, to field responders overloaded with radio chatter. We analyzed the transcripts by breaking them down into >100 different data points and coding them using thematic analysis, documenting every mention of frustrations, workarounds, and gaps. This surfaced recurring themes like technology limitations, lack of a shared view, information overload, and delayed communication.

To connect these insights, we built an end-to-end workflow map tracing both command-level and field-level actions across a large-scale emergency. Each step showed who acts when, how information is exchanged, and where delays or gaps emerge. By combining literature review, stakeholder interviews, and workflow mapping, we surfaced clear opportunities for how TAK + AI could transform coordination: a Shared Map as a Common Operating Picture (a TAK-based map that all agencies can trust), AI-Driven Data Ingestion (AI monitors multiple feeds, de-duplicates the noise, and auto-populates hazard pins), and Faster Situational Reports (AI filters and prioritizes critical updates to generate live reports).

Proposed Design Direction. “Imagine a summer storm knocks down a high-voltage line onto a major road.” In an emergency situation such as this, public safety arrives quickly, securing the scene and directing traffic. Utilities mobilize crews, but they're working off a different map, notified through phone calls or outage dashboards. The two teams are aligned in priorities to restore safety, restore service, but their systems don't align. That mismatch costs minutes, money, and sometimes lives. Our design direction positions TAK as the shared common operating picture, while AI works in the background to keep it current. How it works: AI listens (radio chatter, EOC transcripts, outage management data), AI updates (auto-populates TAK with hazard pins, statuses, and role-specific markers), everyone sees (command, responders, and utility crews all view the same live map, tailored to their role). We wrapped with a structured handoff of research artifacts, workflow maps, and stakeholder insights, documented for the next team to advance into design and testing.

Outcomes.

“A well-structured report with thoughtful insights and modern research techniques. Terrific work” — Sonny Kirkley, Professor, Indiana University

$100K — Grant application. Our foundational research supported our project sponsor IU RedLab's proposal for a national utilities provider, supporting continued research and development of AI-enhanced coordination tools.

This project taught me how to unpack complex, cross-agency workflows and translate them into clear design opportunities, and perhaps even more importantly, I gained experience in communicating research to an audience agnostic to a field, while influencing stakeholders and guiding real-world next steps.

Role: Consultant (teams of 3–8) · Timeline: 2–11 months per project (8 total) · Tools: Oracle EPM, Groovy, SQL, Python, Miro, JIRA

Specifics of client engagements are confidential. The following is a structured overview of methods, process, and outcomes. All assets shown are generic representations.

Overview. I redesigned complex legacy enterprise financial systems into intuitive, scalable Oracle EPM architectures, drastically reducing manual reporting hours and system friction for analysts and executives.

The Problem. Legacy costing systems built on convoluted logic take over 3-5 days, 12+ file loads, and costly delays over $100k to run a complete planning and costing cycle. For many companies, the tools that track where their money comes and goes are more than a decade old. Running a single planning or costing cycle often means navigating complex, code-heavy, and intimidating systems, creating situations where analysts had to call IT for even the smallest fixes. During high-pressure times like month-end close, that meant wasted hours, missed insights, and frustrated teams.

The Users. Behind each of the eight projects, from U.S. healthcare giants to Fortune 500 firms, were finance teams tired of wrestling with outdated tools. In these projects, I typically worked with three key user groups across client teams identified through rigorous workshops, discovery sessions, and background research. The industries varied, but the user patterns stayed the same. Enterprise finance systems users weren't chasing innovation for its own sake. They wanted efficiency without losing control.

What is Oracle EPM? Oracle Enterprise Performance Management (EPM) is a cloud platform used by large enterprises to manage planning, costing, and financial reporting. Instead of juggling dozens of spreadsheets and outdated tools, they use EPM to bring everything into a single, integrated environment. Think of it like Wix for finance systems: the platform provides the building blocks, but every implementation has to be designed and configured for each client's unique needs. Done well, it helps finance teams close the books faster, build reports, and make decisions with confidence. That's where my role came in, working with finance teams to translate their complex, legacy processes into custom Oracle EPM solutions that were both easier to use and more scalable for the future.

The Process. From discovery to go-live, every step of our process was tested, refined, and improved through direct input from the people who would rely on the system. To understand how costing really worked inside these companies, we started with two tracks of discovery. User Research: we conducted workshops and interviews with finance teams, costing SMEs, and leads to map workflows and frustrations. I led several of these sessions, documenting processes step by step and surfacing where time was lost. System Analysis: in parallel, we audited legacy systems, digging through SQL rules, reconciliation spreadsheets, and documentation to see how years of patchwork fixes had shaped the way costing was done. This combination revealed both the technical debt and the cultural barriers as well as the three core needs that shaped every design decision we made.

Methods: Contextual Inquiry · Semi-Structured Interviews · Workflow Mapping · Technical Audits

Ideation & Design. One insight stood out from research: different users needed very different things. Costing SMEs wanted deep access to allocation rules and configuration. Analysts needed quick, accurate reports. Executives cared about top-line dashboards they could trust at a glance. A one-size-fits-all interface would have failed all of them. Instead, we used Oracle EPM's navigation flow capabilities to design role-specific UIs. Each group only saw the modules, reports, and tools relevant to their work. This cut down noise, reduced time on task, and helped users feel the system was built for them rather than forced on them.

Prototype. Finance teams live in spreadsheets, so instead of jumping straight into complex software mockups, we started with what they knew: Excel prototypes. These prototypes recreated layouts, flows, and even formulas inside spreadsheets, letting users explore ideas in a tool they already trusted. Once the logic and layouts were validated, we rebuilt the designs inside Oracle EPM's demo environment. These high-fidelity prototypes simulated real navigation flows, forms, and rule structures, giving stakeholders a clear picture of how the system would feel in practice. We ran live walkthroughs and workshops with analysts, SMEs, and directors. Seeing their workflows come to life early not only surfaced usability issues but also built confidence, turning skepticism into buy-in.

Implementation & Testing. Once prototypes were validated, we moved into system configuration and build. I worked hands-on in Oracle EPM to set up allocation models, data flows, and validation logic, using Groovy scripting and templates to keep the system flexible and scalable. To ensure adoption, we ran usability testing cycles that mirrored real-world close activities. Users followed task-based scripts, running models, validating outputs, and troubleshooting issues in a secure environment. Testing with both neutral users and finance SMEs surfaced navigation problems, unexpected data movement, and formula discrepancies.

Outcomes. Users reported that month-end costing, which previously took multiple days, could now be completed in a fraction of the time. This was due to automated integrations, role-based UI design, and the ability to schedule calculations and loads. Simplified allocation logic reduced hundreds of code-heavy scripts into a lean, maintainable set. In some projects, rule counts dropped by over 90%, leading to improved performance and greater flexibility for users.

“Thanks for your efforts in delivering the solution. There were multiple challenges and minimal time to deliver, but you have overcome them all.” — Deloitte Award

60–90% — reduction in process execution time · ~80% — fewer allocation rules

They say the smartest character a writer will ever create is only as smart as themselves. I believe the same holds true in design. The systems we build are only as thoughtful as the people who design them. On these Oracle EPM projects, that meant first understanding each client's domain and shaping solutions that were not just powerful but actually usable for the experts who relied on them every day.

Role: UX Designer · Timeline: 6 Months · Tools: Figma · OpenAI API · Oracle EPM · REST API

Specifics of this project are confidential and cannot be disclosed. However, I have provided a basic overview of work I have done as part of this project. All assets and details displayed herein are generic representations.

Product Overview. A conversational AI assistant designed for financial analysis teams, capable of integrating GPT 4 with Oracle EPM. It enables users to query financial data in natural language, reducing dependency on manual reports and dashboards.

Problem. Finance teams spend hours navigating dashboards, filters, and formulas. What if they could simply ask their ERP questions in plain English? According to public industry studies, 42% of FP&A work remained manual, consuming up to 10 hours a week in spreadsheets and error-correction. For analysts, that means hours wasted pulling reports. For executives, it meant delayed clarity on critical decisions. And for planners, it meant models and assumptions were rarely consistent across teams. In 2023, as generative AI tools like ChatGPT were rising to prominence, Deloitte launched an internal initiative to explore how large language models could transform enterprise finance. I joined this effort as the UX designer tasked with defining the user interface and underlying integration for how financial planning and analysis (FP&A) teams can use AI to interact with Oracle EPM Cloud.

The Users. Our solution focused on three key user groups with distinct needs within the financial planning and analysis ecosystem. Analysts spent hours pulling numbers into spreadsheets, applying filters, and reconciling formulas. Their biggest pain point was speed: they wanted a faster way to get answers without drowning in manual work. Executives needed high-level clarity for board decks and reviews but often received dense, technical outputs. Their challenge was translating raw numbers into clear insights, quickly enough to act on. Planners worked across multiple scenarios and departments, often with inconsistent assumptions. They needed consistency and alignment, as well as a way to ensure everyone was working from the same numbers.

Our Vision. Transparency, reusability, and approachability formed the core of the design vision for the conversational solution. Our goal was to design an assistant that felt like a teammate, not a black box, delivering speed, clarity, and consistency without jargon or uncertainty. To ground our design process, we conducted a competitive analysis, looking at other generative AI tools to identify best practices and trends. Both tools lowered the barrier to entry for conversational AI, but neither addressed the enterprise need for trust, transparency, and repeatability. These gaps became central to our design vision for an enterprise finance-focused assistant, becoming the three tenets for the user experience design: Transparency, Reusability, and Approachability.

The Process. We followed an iterative process through research, design, prototyping, and testing with each stage shaped by direct user feedback. We began with informal interviews and internal discussions to understand reporting pain points. To ground feasibility, I also explored REST API integrations and EPM query capabilities to see how data could realistically be pulled and surfaced.

Ideation & Design. Because this was an MVP exercise, we prioritized speed, simplicity, and confidence over breadth of features. Rather than trying to replicate every capability of Oracle EPM, the goal was to rapidly design and develop a version of the assistant that could start getting real-world use and stakeholder feedback.

Prototyping. We translated the design concepts into a mid-fidelity prototype that simulated the core ask-and-answer flow. The goal wasn't to showcase visual polish but to validate whether the conversational model felt natural and whether users trusted the responses. We built our design prototype to test the conversational flow, focusing less on visuals and more on usability and trust.

Handoff & Development. Unlike many projects where design work ends at handoff, here I played a dual role as both the UX designer and the integration developer. I documented flows, states, and edge cases in Figma providing artifacts that served as the blueprint for the build. On the development side, I leveraged my knowledge as EPM SME to help shape the integration architecture of the solution. I also had the opportunity to present this MVP to senior leadership, walking them through both the design vision and the technical feasibility of the tool. This visibility reinforced the impact of the work and opened discussions about extending the assistant into client-facing solutions.

Outcomes. Early feedback suggested that non-technical users were able to complete insight queries independently without assistance from analysts or IT support, thanks to the intuitive interface and context-aware integrations. Based on a benchmark taken for reporting and insight synthesis process in traditional BI systems, the new system allowed users to extract insights in minutes as opposed to days.

“Thanks for your tremendous work in building the Oracle EPM Gen-AI solution. Your energy, enthusiasm and attention to details is amazing !!” — Deloitte Award

2 Step ↓ — Support dependency · ~75% ↓ — Time to insight

This project marked my first hands-on experience designing for an AI-driven product. I learned how critical it is to manage user expectations in generative systems and ensure traceability in AI outputs, especially within enterprise environments. Working on the integration between GPT and structured financial systems gave me a new appreciation for the complexity of data mapping and integration and deepened my confidence in designing AI-driven interfaces.

Role: First Author · Qualitative UX Researcher · Advisor: Dr. Dong Whi Yoo · Community Board: Active Minds · Chancellor's Student Mental Health Council · Accepted · CSCW 2026

Overview. I conducted a 22-person interview study to understand why students sometimes prefer AI chatbots over human support for mental health, resulting in a first-authored paper accepted to CSCW 2026.

The Problem. College students are using AI chatbots for emotional support - not occasionally, but regularly. And they aren't just doing it because human support is out of reach. Sometimes they reach for AI when human support is available, and deliberately choose the AI instead. This research set out to explain that pattern. The answer turned out to be structural: rooted not in AI's conversational capabilities, but in a specific social gap it fills that no human node in a student's support ecology can.

The Users. College students experiencing varying levels of mental health distress, particularly those facing friction points in their existing support ecologies - such as long therapy waitlists, the fear of burdening peers, or acute overwhelm at 3 AM. We focused on understanding how different student populations (e.g., international students, those without established local peer networks) leaned on AI differently as a resource of last resort.

Methodology. Semi-structured interviews with 22 college students at a large Midwestern research university. The interview protocol was deliberately structured to start from the full support ecology - peers, family, therapists, faith - before arriving at AI. We needed to see where AI fits, not study it in isolation. Analysis used Braun and Clarke's reflexive thematic analysis. A Community Advisory Board from Active Minds and the Chancellor's Student Mental Health Council reviewed interpretations monthly throughout.

Six Entry Points. Students didn't adopt AI for mental health support generally. They adopted it at six specific friction points where their existing ecology couldn't meet them in that moment: Planning Under Overwhelm (breaking paralyzing workloads into steps when initiation was impossible), Supplement to Therapy (filling continuity gaps between sessions when the therapeutic relationship was unavailable), Navigating Interpersonal Conflict (scripting difficult messages before engaging in real relational work), Journal & Brain-Dump Analysis (converting private written reflection into interactive, responsive dialogue), Acute Emotional Regulation (sub-5-minute stabilization windows when no human was reachable), Companionship After Relocation (responsive presence for students newly relocated without peer networks yet).

The Disclosure Spectrum. Support nodes are arranged by the perceived social cost of disclosure. In the published model, there are five core nodes: Therapist/Professional Care, Close Friend/Family, Anonymous Online Forum, Diary/Private Journal, and the AI Chatbot. AI occupies the zero-cost position: the only node that combines responsiveness with the absence of perceived social reception.

The Construct: Non-Perceiving Listener. AI is the only node in student support ecologies that combines responsiveness with the absence of perceived social reception. Anonymous forums carry social memory. Diaries have no responsiveness. Friends carry reciprocal burden. AI resolves the exact barrier that makes peer-embedded support costly at certain moments.

“It is 100 percent the way that I do not have to be perceived on these issues.” — P14

Implications for Practice. This academic finding has direct implications for applied enterprise UX. While AI acts as a "non-perceiving listener," this is ultimately a perceived affordance—systems still retain data. If users are disclosing highly sensitive information precisely because they feel unperceived, then data-retention transparency is no longer just a legal requirement; it is a core UX problem. It must be surfaced at the moment of disclosure, rather than buried in terms of service.

The Risk. The same affordance that made AI valuable also made it risky - no social consequence means no incentive to challenge - students identified unconditional validation as a problem even while continuing selective use. Students with fewer resources - international students far from home, those without therapy access, those with limited peer networks - described heavier reliance. If AI is functioning as a resource of last resort for the most under-resourced students, its limitations fall hardest on those least able to absorb them.

“If I was on the brink of suicide, that should not be handled by AI.” — P20

Outcomes.

“A timely and relevant look at how general-purpose AI chatbots fit into broader mental health support ecologies. The introduction of the non-perceiving listener offers a useful theoretical lens for understanding why students sometimes prefer AI over human support.” — 1AC Meta-Reviewer, CSCW 2026

Strong Accept — 5/5, Very High Confidence · Open Access — CC-BY, ACM Digital Library

Reflection. This project taught me that the most useful research questions are often the ones that resist a clean technology framing. I went in expecting to study how AI chatbots work as tools; I came out having learned that the more important question was structural, about the gaps in care that make any tool feel necessary in the first place. Sitting with 22 students' stories about loneliness, therapy waitlists, and 3 AM parking lots reshaped how I think about design: not as building better AI, but as noticing where a system is quietly asking a person to go without.

Academic Project, Indiana University · Role: UX Designer & Researcher · Timeline: 2 Months – Spring 2025 · Tools: Figma, FigJam, Excel, Qualtrics

Overview. I led UX research and design for Nest, a student-focused financial platform built to alleviate financial anxiety by providing clear visibility across scattered tools and unpredictable income.

The Problem. For students, income is irregular, expenses are often shared, and financial apps feel overwhelming. In interviews, most students tracked expenses manually or juggled multiple tools - but still felt anxious and confused. 30 exploratory interviews and 15 task-based testing sessions surfaced four recurring pain points: Unpredictable income (scholarships, part-time jobs, and family support arrive irregularly, making budgeting stressful), Fragmented tools (students juggle spreadsheets, banking apps, and mental math - none provide a unified view), Financial anxiety (poor visibility makes students feel anxious; many reported skipping meals or avoiding events to cope), Low awareness of support (few knew about resources like campus financial counseling or food pantries).

The Users. Our research uncovered three primary student financial mindsets, each representing a distinct financial lifestyle and pain point. Alex's Journey: Irregular income and loan stress created constant anxiety, highlighting the need for clear debt tracking and goal-based savings tools. Maya's Journey: Scattered tools and inconsistent tracking caused friction, pointing to the opportunity for a unified system combining budgeting, saving, and investment readiness. Rita's Journey: Small, frequent purchases and a lack of structured tools led to overdrafts, emphasizing the need for simple budgeting and real-time spending alerts. These artifacts helped us prioritize features like goal-based saving, supportive nudges, and simplified dashboards.

Our Vision. Nest's vision was to reimagine everyday financial tasks through an app that feels supportive rather than punishing. We asked: what if money management felt like guidance instead of guilt? To ground the vision, we ran a competitive analysis of existing finance tools. The review made one thing clear: while competitors automate, reward, or educate, none of them addressed the specific stack of irregular income, shared expenses, and financial anxiety students face. To bridge that gap, we ran observational studies with 15 students, watching their real financial workflows and identifying five essential tasks that defined how they currently managed money. Mapping baseline metrics against those tasks gave us the foundation for the design and testing that followed.

Design Process. We followed an iterative process through research, design, prototyping, and testing, with each stage shaped directly by user feedback. Our approach combined divergent exploration with iterative refinement - starting from multiple low-fidelity concepts, converging into a consolidated mid-fidelity prototype, and refining it into a cohesive high-fidelity system. At every stage, we ran 15 task-based testing sessions with students, measuring completion rates, satisfaction, and time on task.

Low-Fidelity Prototype. Each team member created an independent low-fidelity prototype exploring a different approach: budgeting clarity, shared bill management, AI-powered guidance and habit-building. Testing showed students gravitated toward card-based layouts and clear progress indicators, but disliked cluttered dashboards. Rather than choosing one direction, we used the results from testing across all three parallel explorations as a foundation for convergence.

Mid-Fidelity Prototype. We merged the strongest elements from each exploration into a single consolidated prototype, emphasizing modular financial task flows (budget, bill, loan, recurring charges, review), visual clarity and approachable hierarchy, and contextual assistance tailored to student behaviors. This version resonated significantly more with users; we weighed tradeoffs before consolidating into the high-fidelity system.

High-Fidelity Prototype. We refined the system into a polished high-fidelity product with a unified dashboard displaying net worth, loan progress, recurring bills, and active budgets, along with visual progress indicators to reduce cognitive load. Through iterative design and testing, the high-fidelity prototype delivered 100% task success, an average of 98% faster completion, and a 29% increase in satisfaction across 15 task-based testing sessions.

Rita's Journey. Rita is a college student juggling classes, friends, and part-time work. She opens Nest at the start of her week, hoping to finally feel in control of her money. Chapter 1 — Setting a Budget: Rita starts her week by creating a simple budget in Nest. Instead of juggling spreadsheets, she automatically sees her income and bills populated in the app, giving her an instant picture of her month. Chapter 2 — Splitting a Bill: At lunch with friends, Rita uses Nest to split a shared bill. She selects contacts, assigns amounts, and sees in real time who has paid - no awkward reminders needed. Chapter 3 — Catching a Recurring Bill: Later, Nest surfaces a reminder for an upcoming loan payment. Instead of scrolling through her bank app, Rita sees all recurring charges neatly flagged in one place.

Outcomes.

“This is such a thoughtful and well-executed project. You should be proud.” — Amy King, Course Instructor, Indiana University

100% — task success rate across all 15 usability sessions · 98% — faster task completion vs. baseline methods · 29% — increase in user satisfaction score

Timeline: 2 Months – Spring 2025 · Role: UX Designer - kiosk & postcard interactions (team of 5) · Tools: Figma, Blender, Sora

Overview. I designed the interactive kiosk and physical keepsake experience for IndyQuest, a civic tech platform that transforms how newcomers intentionally discover and navigate Indianapolis.

The Problem. Exploring Indianapolis often feels accidental. Most newcomers stick to familiar spots like Mass Ave or the Canal, bouncing between apps to plan a simple outing. Desk research, competitive analysis, and user interviews surfaced four recurring patterns: Exploration is accidental (people stumble into events or restaurants rather than plan ahead), Tools are fragmented (users juggle 4-5 apps just to plan a simple outing), Navigation isn't delightful (apps get you from point A to B, but miss everything in between), Physical keepsakes matter (a receipt fades, but postcards, photos, and stamps become memorable tokens).

The Users. Through interviews and cultural probes, we identified three distinct types of city explorers: the Planned Adventurer who researches extensively in advance, the Spontaneous Wanderer who decides in the moment, and the Social Explorer who organizes outings for groups. Each had distinct frustrations with existing discovery tools - and distinct motivations that a gamified, physical-digital hybrid system could engage in entirely new ways.

Our Vision. What if exploring Indianapolis felt less like searching and more like playing a game? IndyQuest reimagines the city as a set of themed quests that combine physical kiosks, collectible postcards, and a mobile app into one cohesive hybrid experience - designed specifically for a car-centric city where walkability assumptions don't apply. The concept revolves around three key ideas: Quest-Based Exploration (user-generated and curated themed trails like "Parks of Indy" or "Street Art," turning city discovery into purposeful adventures), Hybrid Touchpoints (postcards, kiosks, and the mobile app work together, bridging physical and digital exploration), Rewarding Progress (players collect physical stamps on their postcards and signatures from local businesses, making exploration fun and memorable). To ground the vision, we drew inspiration from existing systems that successfully blend physical and digital exploration. Exemplars like Pokémon GO and the Indy Cultural Trail helped shape IndyQuest's quest and kiosk system.

The Process. Iterative through four stages: discovery (interviews, probes, competitive analysis), design (three parallel lo-fi directions converged to one mid-fi), testing (paper prototype → Figma mid-fi → Blender high-fi), and refinement. Leveraging our research, we sketched flows for kiosks, postcards, and the mobile app, exploring how physical and digital touchpoints could work together so that progressing through each phase felt like progressing through a game. Key pivot driven by usability testing: the original custom navigation system was replaced with Google Maps integration. Users trusted a familiar interface over a designed one. The right call was to stop competing with muscle memory. Prototyping and testing were treated as a continuous loop. From early sketches to paper mockups, Figma flows, and high-fidelity screens, we tested three key tasks with users, gathered insights, and refined the experience at every step.

Low-Fidelity Prototype. A paper prototype simulating interactions, tested with 3 participants using think-aloud protocol - 3.7/5 average satisfaction, ~6.3 clicks and scans/swipes per task.

Mid-Fidelity Prototype. Moved into Figma, designing mid-fidelity screens to define the quest flow: choosing a theme, scanning at kiosks, collecting stamps, and tracking progress - 4.2/5 average satisfaction, ~6.5 clicks and scans/swipes per task.

High-Fidelity Prototype. Refined the app into polished high-fidelity screens and modeled kiosks in Blender to visualize how physical and digital touchpoints connect. Led kiosk and postcard interaction design specifically - the physical-digital handoff moments where a user touches the system in the real world and the app responds. Used Blender for high-fidelity 3D kiosk renders and Sora for motion concept exploration. Iterative testing shaped IndyQuest into a hybrid system that seamlessly connects kiosks, postcards, and an app, creating a purposeful, playful exploration experience for Indianapolis.

The Experience. Planning: Open the app, browse quests or let the AI suggest one based on mood and time. Pick "Parks of Indy." The app shows the route, the kiosks, and what you'll collect. Exploration: Arrive at the first kiosk. Receive your postcard. At each checkpoint, check in, collect a stamp, see nearby recommendations. The postcard fills in as you go - a tactile record of progress in your hand. Completion: Final kiosk, final stamp. The app celebrates. Local vouchers appear. The completed postcard is yours to keep - a physical artifact of a day in the city.

Outcomes.

“You've developed a very thorough process. Your concept is unique and especially influential as it explores beyond walkability into the more familiar car-centric experience of this city.” — Alex Hoffman, Evaluator

4.2/5 — user satisfaction at high-fidelity stage (up from 3.7/5) · 97.5% — academic evaluation score

Users especially enjoyed the postcard stamping mechanic and hybrid kiosk-app progress. Feedback confirmed that IndyQuest made exploration feel more purposeful and rewarding compared to existing tools. The academic evaluation recognized the project for iterative rigor, storytelling depth, and comprehensive prototyping - and praised its adaptation of wayfinding to car-centric urban contexts, an often-overlooked dimension in city UX design.

This project taught me how to bridge physical interaction modeling with mobile UX and spatial storytelling. It deepened my ability to design across environments while maintaining a cohesive journey - a perspective I now bring to all experiential design work.