Senior at UT Austin double-majoring in Psychology and Informatics, with a UX Design concentration.
Off the clock: chasing my dog Rocky, picking up a new instrument or language, and losing gracefully at pickleball.
How can teams collaborate on AI-generated artifacts when concurrent editing is not possible? Through user interviews, competitive analysis, and multiple design iterations, I developed a collaboration workflow that balanced usability with technical constraints.
How can UT students eat healthier when convenience always wins over nutrition? Through 9 user interviews, a 72-person survey, and affinity diagramming, our team uncovered a clear gap: students want to eat better but lack accessible, personalized tools to do it.
How can Nebula Social's UI help users more easily understand and engage with key features? Through a full UI audit, a typography audit, and a feature-usage tracking proposal, I identified where the product was quietly losing users, and shipped tangible design fixes for each.
A little about me
I'm a senior at UT Austin, pursuing a BA in Psychology and a BS in Informatics with a UX Design concentration. That combination shapes how I design: understanding why people behave the way they do, then building systems that work with that behavior instead of against it.
My empathetic side comes from being a mental health advocate and from growing up watching my dad work in healthcare, seeing firsthand what it means to actually take care of people. My creative side comes from my mom, an art teacher and jewelry designer, and a lifelong love of the arts she passed down to me.
Outside of design, I'm usually learning something new, whether that's picking up a guitar, attempting another language, climbing a wall, or convincing myself I'll finally win at pickleball. I love spending time with my family, Rocky (my dog) included.
Interviews, surveys, affinity diagramming.
Understanding what actually drives behavior.
Figma, design systems, visual polish.
Low fidelity wireframes to high fidelity interactive builds.
Structured feedback, iteration, follow-through.
Balancing desirability with what's feasible.
Comfortable prototyping in real code.
Cross-functional teams, tight feedback loops.
Seeing my dad work in healthcare and advocating for mental health myself taught me to design with real care for what people are going through, not just what they click.
My mom's an art teacher and jewelry designer. Growing up around that creativity shows up in how I approach open-ended design problems today.
I'd rather ask why than guess. Psychology trained me to look for the real reason behind a behavior before designing around it.
Every decision gets checked against one question: does this actually make things better for the person using it.
Accrete's Knowledge Engine turns complex information into AI-generated reports, dashboards, and presentations, but teams had no way to collaborate on those artifacts once they existed. Three constraints shaped everything that followed:
Concurrent cursors, like Google Docs, weren't technically feasible yet.
Every user in a shared workspace held identical access to every artifact.
No defined line for where the agent's authority should end and a person's should begin.
Two things needed answering: what users currently do, and what they actually want. Pendo data could only tell me the first.
Pendo showed reports as by far the most-generated artifact, but collaboration itself was barely tagged, with only 5–6 features showed usage even with a shared workspace present. That thin signal meant analytics alone couldn't carry the research: I needed to hear from users directly.
Usability tasks covered workspace & navigation, single-agent workflow, and generating artifacts from the repository, watching for whether the product felt intuitive without help. Interviews then went deeper on four topics: skills implementation, collaboration, mobile platform features, and overall impressions. Sessions were recorded (Gemini) alongside manual observer notes.
For collaboration specifically, I asked about the platforms people already collaborate on, how they felt about IKE's current shared workspace and version history, and how they'd want to collaborate on artifacts given that live, simultaneous edits aren't feasible yet.
How interviews were tracked and organized (recordings, Gemini notes, and observer notes per participant).
Affinity-diagramming the raw responses, from quotes to clustered categories to themes, surfaced three recurring needs:
Users wanted to work together even knowing real-time editing wasn't possible.
Timestamped, attributable changes people could trust and revert.
Permissions that reflected actual roles, not blanket workspace access.
Because Accrete's product already existed, I couldn't start from a blank page the way I normally would with low fidelity wireframes. I had to visually build on top of the existing UI. Since I was integrating collaboration into a live product, brainstorming meant working directly within that UI: screenshots, markups, ideas, and mockups layered over what was already there. That was a shift for me: I was used to starting completely from scratch, not working around existing constraints. I also referenced the existing design system throughout, thinking through how a collaboration mode could work with what we already had.
Early brainstorming sketch with FigJam, before low/mid-fidelity wireframes.
Some of that early brainstorming took the shape of quick low/mid-fidelity wireframes, testing the owner vs. commenter states before any visual design was applied:
Before ideating solutions, I mapped the user flow: what the current, chat-only experience looked like versus what a real collaboration mode could look like for both an artifact owner and a commenter.
Early ideation produced several directions I ultimately dropped: each solved one problem while quietly creating another (a second-order effect). Getting unstuck meant more research: looking at how collaboration works on other platforms.
Where did this come from? No clear origin for the user to trust.
Where did this come from? Blurred who actually owned the decision.
What if a user wants to comment on a chart? Panel gets cluttered fast.
What if multiple users suggest on the same original text? Too cluttered and complicated.
If checked mid-collaboration, it may not go through and causes more questions than it answers.
Clutter on the UI: private new chat, private same chat, or group chat?
I ran a competitive analysis across seven platforms (Google Docs, Figma, Notion, and Canva among them) to see how mature products handled comment threads and AI's role as collaborator versus gatekeeper. They relied heavily on standardized patterns: comment pins and inline threads, AI acting as a gatekeeper rather than a direct co-commenter, and few offered true suggestions since live editing usually made them unnecessary.
A quick look at interacting with comment and suggestion features across all seven platforms:
Four principles guided every design decision:
Collaboration lives where the work already happens.
Don't break existing agent workflows to add people into the loop.
A comment is not the same action as a change.
Solve for what's technically feasible now, not a future state.
That led to a single-owner model (one owner accepts or rejects changes, everyone else can comment and suggest), paired with a "suggestion as pin, not edit" pattern, so multiple people can propose changes to the same sentence without overwriting each other. Every AI-proposed edit still routes through the same owner approval, so an agent's suggestion is never more powerful than the person who prompted it.
As the report's owner, this walks through opening my own chat, responding to a comment, and accepting an AI-proposed edit directly, then commenting, suggesting, and asking Accrete on selected text myself.
As a commenter on someone else's shared artifact, this covers replying to a comment, suggesting an edit I can't accept myself, and deleting my own suggestion, with the same model shown on a shared presentation and dashboard too.
A quick look at switching a generated report into Collaborating mode.
A closer look at each side of that model, plus how the same comment/suggestion mechanics carry over to a different artifact type:
Owner view: reviewing and accepting a suggestion
Commenter view: highlighting text and drafting a suggestion with AI assistance
Beyond reports: the same model on a presentation and a dashboard
The report was the focus, but the same comment/suggestion mechanics carry over to other artifact types without changes.
Every idea was mapped against what was right for collaboration versus what was actually buildable today. The image below traces which of those decisions shipped in v7, and which were considered but set aside.
This project work is now in the engineering pipeline. The next steps include:
Timestamped, reversible changes past a single Undo.
Review open suggestions in one pass, not thread by thread.
Group chats, section locking, and live presence indicators.
"Nearly every solution I got close to raised a new question that sent me back a step, and I learned to hold my own design judgment steady through a lot of well-meaning, conflicting feedback."
College students at UT Austin want to eat well, but convenience keeps winning. Existing research pointed to a clear gap before we ever ran our own study:
Among college students nationally (Keller, 2026).
Because it's the most convenient option available.
Only a small fraction hit daily recommendations.
Two research tracks ran in parallel: qualitative interviews to understand the "why," and a quantitative survey to check whether what we heard held up at scale.
9 interviews: 8 UT students spanning freshman through senior, plus 2 transfers, and 1 staff member, each 30 to 60 minutes.
Participant ID naming convention
Staff/Faculty at UT Austin.
Transfer students at UT Austin. TS1: male, 1 semester on a UT meal plan, vegetarian, medium nutritional knowledge. TS2: male, meal plan and lives in the dorms, vegetarian, medium nutritional knowledge.
First-year students. FS1: female, meal plan and lives in the dorms, no dietary restrictions, little nutritional knowledge. FS2: female, meal plan and lives in West Campus, vegetarian, medium nutritional knowledge.
Second-year student: female, no meal plan, semi-vegetarian, medium nutritional knowledge.
Third- and fourth-year students. FoS1: male, 1 year on a UT meal plan, semi-vegetarian, high nutritional knowledge.
6 general questions (asked of everyone)
Follow-up questions (all participants)
Segment-specific questions
We affinity-diagrammed the raw interview data by hand, sorting notes into categories, then themes, then insights:
Three recurring insights emerged:
Limited, repetitive, and unhealthy options, yet students rely on them anyway because they're accessible.
The community wants to eat healthier but lacks the resources and knowledge to do it.
Students prioritize nearby, quick options, which are almost always the less healthy ones.
A 72-person campus-wide survey (29 of them freshmen), 14 questions mixing multiple choice and ranking, to check whether the interview findings were widespread or isolated.
Rising to 93% among freshmen specifically.
Just 4% among freshmen.
Jumping to 70% among freshmen.
A clear, largely untapped demand.
Takeaway: there's a strong, specific need for a UT-tailored nutrition tool that's personalized and genuinely convenient, not just another generic calorie tracker.
From the research, three personas grounded every design decision that followed:
Vegetarian. Struggles to find protein sources nearby and has started skipping food experiences with friends because so few nearby places fit his diet.
Halal diet. New to making her own food choices; often unsure which dining hall options are halal and ends up eating the same few "safe" meals.
Vegan, nut allergy. Busy schedule between meetings leaves little time to check allergen info, so she often settles for unbalanced, quick options.
We storyboarded each persona's current frustration against how BevoBites resolves it. This one follows Bella, a freshman on a halal diet, trying to grab a quick meal between classes:
After affinity diagramming the interview data and analyzing the survey results, we mapped a user flow and moved into low-fidelity wireframes, covering three pillars:
Onboarding, a goal-setting quiz, and an account tab for dietary restrictions.
Progress rings for macros, meal history, and favorited meals for fast re-logging.
Search with filters, dining hall & nearby restaurant menus, and macros shown right on the menu.
We tested a low/mid-fidelity prototype covering onboarding, home, daily goals, meal-logging methods, search, filters, and dining hall/restaurant menus, then gathered structured peer feedback before moving to high fidelity.
Before building high fidelity, we tested the wireframes with peers and gathered structured feedback across four areas:
Very intuitive; buttons follow standard app conventions. Section titles could be smaller for more breathing room.
The restaurant option for logging meals was praised. Next: clearer transitions and a save-for-later option.
Clearly aligns with helping students track meals, but doesn't yet show what the nutrition data means for personal health goals.
Search recommendations and dining hall hours landed well. Requested: deeper profile customization and a returning-user login screen.
The raw feedback board, sticky notes and all:
These insights directly shaped the high-fidelity build, including a login screen for returning users and a restaurant option for logging meals.
The high-fidelity prototype turns those three pillars into a real app. A few screens from the build:
Work through what's technically buildable now versus what needs more runway, especially the "Ask AI" meal logging.
Run structured usability tests on the high-fidelity build the same way we tested low fidelity.
Design the remaining logging paths: from Recommended meals, Ask AI/camera, manual search, and Logged History.
A walkthrough of the high fidelity build in action:
Some data in this case study has been anonymized at my employer's request.
How can Nebula Social's UI help users more easily understand and engage with key features? Certain parts of the product were creating disinterest, confusion, and frustration, and that mattered because the goal wasn't just gaining users, but keeping them active.
I ran a full research pass across three areas of the product, each surfacing a different kind of risk:
Aesthetics matter, and I found a lot of dead clicks and rage clicks on key UI elements.
Found signs of possible WCAG (Web Content Accessibility Guidelines) violations.
The team lacked visibility into which features were actually being used, by whom, and how.
Unexciting, redundant, and malfunctioning elements were quietly costing engagement. A few of the biggest issues:
Users were already clicking them, but the UI felt outdated. Proposal: hover interactions modeled on Netflix, Spotify, and Google, to make the elements feel more alive.
Tooltips repeating text already visible added clutter with no value, and small screens crammed further. Proposal: only show tooltips when needed, cap their size, and truncate long names with an ellipsis.
Clicking the icon or a date didn't behave as expected, an odd text cursor appeared, and a redundant dropdown repeated the same options. Proposal: tie the calendar directly to the icon/date click, matching patterns like American Airlines' date picker (Jakob's Law: people expect your product to work like the ones they already know).
Zoom had no cap (inverse/infinite controls felt broken), node-following paused unpredictably, and small screens left little room to interact. Proposal: a zoom cap, pausing on interaction, and a fullscreen toggle, patterns borrowed from NASA's Eyes visualization tool.
The knowledge graph's zoom-out control was one of the most rage-clicked interactions in the product, 50 rage clicks in 30 days, because it had no lower bound and would collapse to almost nothing:
Reference points from Netflix, Spotify, Google, and American Airlines for the general UI, tooltip, screen size, and calendar issues, and NASA's Eyes tool for the knowledge graph:
Nebula Social averaged 15 distinct text styles per page, ranging from 4 to 27, with no documentation of size, weight, font, or color anywhere. That's a real risk: more inconsistent styles mean more cognitive and choice overload for users, and it makes hierarchy (what to look at first) hard to establish.
I built a full typography audit in Figma, visually annotating text styles page by page across the entire product, as a reference system for the design team going forward. General guidance: keep each page to 6–9 unique styles.
A single page like this could carry anywhere from 4 to 27 distinct text styles with no documentation behind any of it.
I used Figma annotations to document every style in place, size, weight, font, and color, then organized everything into a proper type scale (H1 through overline) that caps each page at 6–9 unique styles:
That became a living typography audit in Figma, a visual reference of every text style, page by page, across the entire product:
A close-up of one page from the audit, with the exact number of distinct fonts used, called out at each section (determined by writing out each text on each screen's font size, weight, type, and color):
Without knowing how users actually interact with a feature, the team was left guessing, and biased guesses lead to misallocated design effort. I proposed and helped stand up a Pendo dashboard tracking if, by whom, and how each feature gets used, so future prioritization could be grounded in real usage data instead of assumptions.
Just 23% of features were driving 80% of all feature clicks, exactly the kind of signal the team didn't have visibility into before.
Alongside the audit, I contributed to an official custom icon library for Accrete (white, gray, and purple variants), extending it for future accessibility across the team's projects.
Putting the whole research-to-solution path side by side, across all three areas:
Discuss feasibility and implementation timeline for the proposed designs.
Roll out the new style hierarchy consistently across current and future designs.
Use the new dashboard data to brainstorm concrete feature improvements.
Guess the word that describes Ria
Inspired by Wordle by Josh Wardle / The New York Times
