Hi, I’m Kyara - a UX designer who also tinkers with hardware. Prev. @Google Cloud

p.s. all doodles are hand-drawn

Illustrated portrait of Kyara Lora

Projects

About

I've always been a builder.

I started in middle school and haven't really stopped. I've built PCs, keyboards, and iPods, fixed up a dryer, and I still play around with microcontroller boards (hi Arduino!). Along the way, I learned how frustrating it is when something doesn't work the way you want it to, and how good it feels when it finally does. I bring that same mindset to my designs because I want things to ‘just work’ for the people using them.

I recently finished my time as a UX Designer at Google, where I worked on Google Cloud (Cloud SQL + Database Center) and Google Classroom. I did research with users, including database administrators (DBAs), teachers, and students, and designed some pretty cool things in the process. My philosophy is that even complex systems should feel effortless to use, and I like turning technical constraints into experiences that feel intentional and work well.

TL;DR

RecentlyUX Designer, Google Cloud + Classroom
FocusComplex technical tools, for DBAs, teachers, and students
Also builds/fixesPCs, keyboards, iPods, and now, dryers!
Sticker: three cats, one black, one gray and one tabby, lounging on a cat tree Sticker: Kyara posing beside a giant Blastoise statue Sticker: a modded iPod Classic in a clear yellow shell, playing “Cupid” by 112 Sticker: “Kyara was here” handwritten in pink marker, with a heart

Kind notes from the field

A note from

Chris Norman

Senior Staff UX Manager for GenAI Creatives at YouTube Ads, my mentor

It’s a pleasure to recommend Kyara, a designer who effortlessly bridges deep technical rigor and human-centered intuition.

Across everything from complex enterprise cloud infrastructure to thoughtful, accessible micro-interactions, she brings an instinct for turning dense technical constraints into intuitive workflows. Watching her thoughtfully integrate generative AI workflows and techniques into every stage of product development has been a genuine highlight; as a mentor, there is nothing better than learning right alongside your mentee.

What truly sets Kyara apart is her collaborative spirit. She dives headfirst into ambiguity, eagerly partnering with cross-functional teams to untangle gnarly problems and shape them into seamless, high-impact experiences. Her builder’s mindset and infectious enthusiasm make her an invaluable asset to any team ready to elevate how users interact with complex digital ecosystems without losing the unique personality that sets those experiences apart.

A note from

Rey Benoit

Product Design Lead at Google Cloud, my manager

Kyara is an exceptionally talented UX designer whose craft, technical curiosity, and leadership far exceed expectations.

What sets Kyara apart is her fearlessness in tackling highly complex problem spaces. From taking full ownership of generative research and usability synthesis in unfamiliar domains to architecting ML-driven UX features and responsible AI workflows, she consistently delivers senior-level results. She pairs a proactive, hacker-like problem-solving approach with genuine cross-functional leadership, frequently conquering new challenges well ahead of timeline milestones.

Kyara is a rare talent who bridges the gap between deep technical systems and human-centered design. She will make an immediate, outsized impact on any product design team lucky enough to have her.

A note from

Jamal Momon

Senior UX Researcher at Google for Education, my mentor

From helping out with Teacher camp and Teen Tech Time on multiple occasions,

Kyara has always sought the opportunity to help out and has always been such a natural with our users! Stay positive, stay proactive, and stay eager. The world is ready for you!

A note from

Vaishali Jain

Staff UX Designer at Waymo, my interim manager

A true master of blending AI capability with sharp intuition.

Through her work, Kyara showed us all how to turn raw AI outputs into reliable, high-impact products. We’ll miss your sharp eye and technical brilliance!

A note from

Cinthya Mohr

Director of UX at Google for Education

Kyara integrated seamlessly and made a tremendous impact from start to finish.

Her contributions, from thorough notetaking to confidently leading user conversations, were invaluable. She demonstrated incredible poise and professionalism, truly feeling like an essential part of the team. She set such a high standard of excellence and made a lasting impression! Thank you, Kyara, for keeping our educators engaged, supported, and heard!!

Kyara Lora

UX / Product Designer

Summary

UX/Product Designer with 2+ years of experience designing enterprise, AI, and education products across Google Cloud Platform and Google Classroom. Translates ambiguous technical problems into intuitive, scalable experiences through user research, rapid prototyping, accessibility-first design, and close partnership with product and engineering teams.

Experience

BeReal Product Management & Design Extern, Remote

Sep 2026 to Present

Facilitated via the Extern platform

  • Designed and prototyped high-fidelity BeReal concepts in Figma, translating growth-strategy ideas into testable product directions for stakeholder and user review.
  • Shaped roadmap decisions from 9 participants by facilitating focus groups and structured surveys, then translating usability findings into prioritized UX recommendations.
  • Built a leadership-ready rollout proposal by combining user research, competitive benchmarking, and go-to-market planning into one clear product recommendation.

Google UX Design Apprentice, New York, NY

Feb 2025 to Aug 2026

Google Cloud Databases

  • Established reasoning and transparency UX patterns for Gemini Cloud Assist, driving partner-team adoption and contributing to a featured Google Cloud Next ’26 Developer Keynote demo.
  • Supported an estimated $8.32M Oracle-to-GCE migration launch by evaluating setup flows with RITE research, delivering UX recommendations that unblocked product readiness.Case study: Charting the Migration
  • Enabled fleet-wide triage for Database Center by designing an end-to-end issue-dismissal flow that bridged workflow gaps between legacy and modern APIs.Case study: Silence the Noise
  • Influenced 20% of Cloud SQL’s next-quarter engineering roadmap by auditing key workflows and surfacing high-impact usability and pricing friction.
  • Addressed a <1% resolution rate across 364K+ critical alerts by redesigning Cloud SQL recommendations to surface contextual, actionable fixes inside users’ active workflows.Case study: From Ambiguity to Action
  • Delivered a fully scoped, engineering-ready design within 4 weeks by partnering with PM and engineering to align on user-centered trade-offs and unblock development.

Google Classroom

  • Expanded discovery of revenue-generating P0 AI tools across 11+ Classroom teams by designing responsive onboarding components aligned with WCAG and Google Material 3.Case study: Just Enough Help
  • Guided iteration of a generative AI assistant using feedback from 30+ educators, producing a risk-mitigation report focused on student AI over-reliance.
  • Supported a +2.76% lift in monthly active users and a 91.2% ease-of-use score by testing homepage hierarchy, feature prioritization, and discoverability through structured usability testing.

Education & certifications

  • Bachelor of Arts in English Literature, Education, & Korean LanguageUniversity at Albany, SUNY
  • Certificate of Completion of Registered Apprenticeship, UX DesignU.S. Department of Labor & Google
  • Google UX Design Professional CertificationCoursera
  • Google AI Essentials CertificationCoursera
  • CompTIA A+ CertificationCompTIA

Skills

Technical & Tools
Figma, Framer, Webflow, Adobe Creative Suite, Blender, GitHub, VS Code
Languages & Libraries
Python, JavaScript, SQL, HTML/CSS, React, Next.js, Angular, Node.js
UX Design & Research
High- & Low-fidelity Prototyping, Design Systems, Design-Dev Handoff, A/B Testing, User Interviews, Usability Testing, Data Synthesis, Cross-functional Collaboration
Accessibility
WCAG Guidelines, APCA Contrast Guidelines
AI
Gemini, AI Studio, Antigravity, Figma Make, ChatGPT, Codex, Claude Code, NotebookLM, Lovable
All work

Silence the Noise.

TimelineDec ’25 to Jan ’26

Restoring control to users by paying down experience debt and designing a dismissal workflow for Google Cloud’s Database Center.

Projected outcome: bridge the dismissal gap between two live systems.

At a glance

Role
UX Designer
Platform
Google Cloud Platform (Web)
Team
1 PM, 1 UXR, 3 Engineers
Focus
B2B SaaS, Enterprise Design

The brief

Problem

A fractured backend architecture left database administrators (DBAs) unable to dismiss modern alerts, creating alert fatigue and causing critical health signals to get buried.

Solution

A unified dismissal framework featuring organization-level scoping, bulk actions, and flexible snoozing directly within the user’s natural workflow.

Outcome

Unblocked the retirement of a legacy system

Handed off to engineering

Context

When you can’t silence the noise, staying focused becomes a second job.

Imagine waking up to hundreds of notifications. You try to clear them, but half won’t swipe away, so the ones that matter get buried in the clutter.

For a database administrator (DBA) managing a massive enterprise fleet, missing one critical health signal can cause a total production outage. In Google Cloud’s Database Center, DBAs were dealing with a constant fog of non-critical alerts.

“When a recommendation comes in, I want the ability to simply dismiss it. I may know the issue exists, but I don’t want to fix it right now. I need it to go away until I’m ready to come back to it.”

GCP Enterprise User

The root of the problem was in the backend. Database Center pulled data from two separate systems:

  • The legacy Active Assist API let users dismiss issues.
  • The modern Database Center (DBC) API did not.

To users, this technical difference was invisible. They just saw a dashboard where dismissing worked on some issues and failed on others. With no way to clear the clutter, critical issues slowly got drowned out.

I was asked to design a dismissal experience that would put users back in control of their noisy workspaces.

Database Center’s fleet issues view with 687 availability issues and 117 data protection issues, annotated: 804 alerts, none can be dismissed

Alignment

We tied dismissal to the broader engineering roadmap, which got everyone aligned.

Success Criteria
Implement dismissal logic in Database Center to help centralize triage for all GCP workloads.

This project was part of a larger, ongoing initiative called “Issues for All” (I4A). I4A aims to bring fragmented alerts across all 9 of Google Cloud’s core database engines, plus the Oracle and Google Cloud partnership, into one experience under Database Center.

The plan was to retire Active Assist and move all issue triage into Database Center. The problem was that the Database Center API had no way to dismiss an issue, so when Active Assist went away, users would lose dismissal altogether.

Framing the problem this way got UX, PM, and Engineering aligned right away: without dismissal, I4A couldn’t move forward.

Legacy system (Active Assist)Supported dismissal.
An Active Assist recommendation panel with Manage password policy, Dismiss and Cancel buttons, annotated: has dismissal
Modern system (Database Center)Did not support dismissal.
A Database Center issue panel with Go to instance, Edit user settings and Close buttons but no Dismiss, annotated: lacking dismissal

Constraints & Scale

Designing a “Dismiss” button is easy. Designing for massive enterprise fleets is more involved.

The legacy system made dismissal tedious and rigid. DBAs had to clear alerts one by one, and anything they dismissed stayed hidden until they restored them manually. Our research showed they wanted more control, so I built the flow around four needs:

First, bulk action

Making a DBA dismiss hundreds of notifications one at a time is a non-starter. I designed a flow that lets users select multiple alerts and clear them together.

The All issues and recommendations table with three issues checked and a Dismiss issues button, annotated: bulk select and dismiss

Second, organizational scope

At enterprise scale, an alert that’s noise to one person can be urgent for someone else. Letting users choose who a dismissal applies to keeps teams from hiding a critical issue by accident. I added a confirmation step where users pick between “Dismiss for myself” and “Dismiss for organization.”

  • Dismiss for organization is permissions-based, so a DBA manager can clear noise for the whole team and save everyone time.
  • Dismiss for myself lets an individual contributor silence an out-of-scope alert without hiding it from a teammate.
The Dismiss 3 recommendations dialog, choosing Dismiss for myself or for organization, with a duration from 7 days to until restored

Third, in-product touchpoints

Past research showed users are 5x more likely to dismiss issues directly from product pages like Cloud SQL, or from Database Center’s Resource page. I added dismissal to both, so users don’t have to leave what they’re doing to clean up their workspace.

Product page (Cloud SQL)Dismissal added in-product.
A Cloud SQL issue panel with a new Dismiss button beside Go to instance, annotated: plus one touchpoint in-product
Database Center (Resource page)Dismissal added on the Resource page.
A Database Center resource panel with a new Dismiss button under Edit user settings, annotated: plus one touchpoint on the Resources page

Fourth, flexibility

Some users only needed to quiet their dashboard until a scheduled maintenance window, so I introduced a “Snooze” option. In the dismissal modal, users can pick 7, 14, or 30 days, enter a custom date, or choose “Until I restore the recommendation.” This lets DBAs match their workspace to their actual schedules. For peace of mind, I also added a “Dismissed” archive where they can audit past decisions or restore alerts.

The Dismissed tab listing each dismissed issue with who dismissed it, when and for how long, and a Restore issues button

Solution

Examining the full end-to-end flow.

Below is the full solution handed off to engineering. It follows this user journey:

  1. Dismiss issue in Cloud SQL
  2. Dismiss issue in DBC Resources
  3. View dismissed issues in
    DBC Health Issues page
  4. Bulk dismiss
  5. Recover issue
  6. Granular filtering

Exploration & AI

I prototyped an AI agent that could make Gemini Cloud Assist a partner that takes action.

Even with bulk actions and smart scoping, managing thousands of alerts by hand is still a chore. I wanted to see what this workflow could look like if AI did the heavy lifting.

Outside the project’s scope, I:

  • Mapped out the logic in Antigravity
  • Tested prompts through the Gemini CLI
  • Built a speculative agent prototype in AI Studio

In the prototype, the agent scans a database fleet, looks for patterns, and recommends safe dismissals based on tags and upcoming maintenance windows. It was speculative, but it got people talking about Gemini Cloud Assist actually taking action instead of just surfacing information.

Outcome & Reflection

I turned the dashboard from a daily frustration into a high-signal workspace.

  • Handed offto engineering
  • Unblockedthe retirement of a legacy system
  • 2 into 1backend APIs unified behind one dismissal model

This project was ultimately an exercise in paying down experience debt. The final framework gives enterprise users a consistent way to manage their alerts, something Google Cloud’s database products had been missing for a long time. It also removes one of the main blockers to retiring Active Assist and moving Database Center forward.

What I learned: The biggest thing I learned was how even a small action like dismissal depends on the system behind it. Understanding the backend roadmap is what turned a missing button into a problem the whole team agreed to solve.

What my PM said

“Kyara has been amazing to work with. She picked-up a complex and important feature - “Issue Dismissibility” and really ensured a simple/intuitive user experience while also complying with Eng feasibility. She acted as a true team player.”

Apoorv S., Product Manager, Google Cloud Platform
All work
Illustration of two contextual tooltips: one with a pencil-and-sparkles image above its text, one with text only and a close button

Just Enough Help.

TimelineMay to July 2026

Google Classroom was launching new paid AI features, but its old onboarding component wasn’t helping discovery. I designed its replacement: a Contextual Tooltip to succeed where the deprecated version failed.

11+ team adoption commitments. 100% A11Y sign-off.

At a glance

Role
UX Designer
Platform
Google Classroom (Web & Mobile)
Team
1 PM, 1 UX Mentor, 1 UX Manager, 3 Engineers
Focus
Design Systems & Accessibility

The brief

Problem

Classroom’s old onboarding tool, Guided Help, was a full-screen pop-up that had failed an accessibility audit. Once it was retired, teams had no real way to introduce new features, including Classroom’s new paid AI tools.

Solution

A Contextual Tooltip built on Google Material 3 (GM3), with rules for how teams use it and accessibility annotations for engineering.

What I Owned

Component design, web and mobile accessibility annotations, system governance guidelines, and engineering handoff.

Outcome

11+ feature teams committed to adopting the component.

100% GAR 4 accessibility compliance.

Backdrop

Users weren’t finding Google Classroom’s new paid AI features, even though they’d been highly requested.

Guided Help, the old onboarding tool, was supposed to fix this by introducing features as they launched, but it was part of the problem. It was a full-screen modal that interrupted teachers and students while they were working, so most closed it right away:

  • 50%of users closed it within 4.5 seconds
  • 75%of users closed it within 7.5 seconds
  • 90%of users closed it within 15 seconds

It had also failed a Google Accessibility Requirements (GAR 4) audit because of critical screen reader and keyboard navigation issues, meaning that, for anyone relying on assistive technology, it didn’t work.

When Guided Help was deprecated, we had no scalable way to introduce new features. So, I needed to design a component that informed users clearly without disrupting them.

Guided Help, the old full-screen onboarding modal, covering a student’s work in Google Classroom with a tip about the comment bank

Strategy & Alignment

Getting buy-in meant showing the tooltip as the missing middle between two extremes.

A component only works if product teams actually use it. When we pitched to PMs and engineers, we described the problem as a gap in our user education toolkit. Our existing patterns forced teams to pick between two extremes:

  • Badges stay out of the way, but they’re too small to explain a multi-step feature or hold a button.
  • Banners and dialogs have room to explain, but they interrupt people mid-task.

Laying out this spectrum showed where the Contextual Tooltip fit. It sits in the middle and puts information right at the point of action, so users get just enough help without being interrupted.

Chart mapping disruption level against information density, from a simple notification dot to a full-screen modal

Exploration

I audited tooltips from other Google teams to see what was already working.

Before designing anything, I wanted to see how other Google teams introduced new features to their users. I audited tooltips across several Google products and compared them side by side, looking for what worked and which patterns repeated.

What other teams were already doing

A few patterns came up again and again:

  • A short title and description, usually one or two sentences.
  • An arrow pointing to the feature, so it’s clear what the tooltip explains.
  • One clear next step, like “Got it” or “Learn more,” plus a way to close it.
  • Optional extras, like an image or a step indicator for multi-part tours.
Six feature tooltips from other Google products side by side, each with a title, a short description and one or two actions

What that influenced

Starting from those patterns, I defined the tooltip’s colorways, type scale, and spacing for web and mobile. Every choice had to meet accessibility standards, and if an option failed, I threw it out, no matter how good it looked.

Visual design

Tooltip system studies

Typography, spacing, and color across web and mobile.

Selected colorways

Selected – Light Mode

#D3E3FD#1F1F1F#0B57D0

Selected – Dark Mode

#0B57D0#E3E3E3#D3E3FD
View six other colorways

Neutral

#E8F0FE#1F2937#1A73E8

High Contrast

#FAFAFA#111827#1D4ED8

Dark Mode

#1F2937#F3F4F6#60A5FA

Sky Tint

#E0F2FE#0369A1#0284C7

Deep Teal

#0E4A6E#E0F2FE#38BDF8

Midnight

#0B132B#FFFFFF#4A90E2
Typography
AaGoogle Sans

Web

Header
22px Regular
Body
16px Regular
Label
10px Medium

Mobile

Header
22px Regular
Body
14px Regular
Label
10px Medium
Spacing

Web

16px padding / 8px gap

Mobile

12px padding / 4px gap

Container paddingElement gap

Constraints & Governance

I wrote the tooltip’s documentation so every team would use it the same way.

I set rules to keep the component consistent and added limits to protect the user experience:

  • Descriptions are limited to three lines or fewer, in line with other Material 3 tooltips across Google.
  • Multi-step sequences are capped at four steps.

I also wanted to fix a problem from Guided Help, where people could accidentally dismiss information for good. I set up dismissal so that clicking the Close “X” or the primary call-to-action counts as an intentional dismissal. Scrolling away or tapping outside only snoozes the tooltip.

Because we presented these as system-level standards, stakeholders signed off quickly and the tooltip moved on to engineering for development.

The Contextual Tooltips page of the Google Classroom design system, open to its dismissal guidelines, with the rest blurred for NDA

Execution & Adaptability

When engineering hit a technical snag, I designed a fallback.

During implementation, engineering flagged the edge-to-edge media variant, where an image or video fills the top half of the tooltip. In that variant, the arrow has to change color to match the surface behind it, and engineering hadn’t scoped that logic yet.

I met one-on-one with one of the lead engineers to understand what made it difficult. Then I designed a fallback variant where the media doesn’t run edge to edge, which avoids the color change entirely. That gave engineering a safe option if the arrow work took too long.

With the fallback in place, the timeline was no longer at risk, and the team went on to solve the arrow problem. I still handed off the edge-to-edge design as planned, but having the fallback kept the project moving.

Two tooltip cards, one with its arrow on top and one below, annotated: the arrow color needs to match the parent background
Two tooltip variants: the initial design with its image running edge to edge, and the fallback with the image inset, which sidesteps the arrow’s color-switching logic

Accessibility

I built GAR 4 accessibility requirements into the developer handoff.

The tool we were replacing had failed an accessibility audit, so accessibility had to be part of the design from the beginning. I worked closely with my UX mentor, an accessibility expert on the team, to build the Google Accessibility Requirements (GAR 4) into how the component behaves.

I created complete Dev Mode annotations for web and mobile. They documented focus order, screen reader labels, and keyboard interactions directly in the handoff files, so engineering had a clear reference to build from.

The tooltip annotated for engineering, labeling each part’s role, accessibility label, keyboard behavior and reading order

Outcome

This tooltip gives Classroom an accessible way to introduce new features.

  • 11+feature teams committed to adoption
  • 100%GAR 4 accessibility compliance

With this design, I positioned the tooltip to put guidance right at the point of action where users can discover new features. This clears the way for Classroom’s paid AI features to be found, which was the main goal of the project.

What I learned: The biggest thing I learned was how much smoother a project goes when you plan for problems early. Bringing accessibility in from the start meant we weren’t fixing issues at the end, and giving engineering a fallback meant one technical bump didn’t slow the whole team down.

What our manager said

“Thank you, Kyara, for your critical contributions to the team! You ramped up so quickly and met all of our requests like a seasoned pro… Your work kept us ahead of schedule and delivered a long-awaited key addition to our User Education library.”

Vanida V., UX Manager, Google for Education
Google Classroom’s Classwork page with the new tooltip pointing to the Create button
All work

Serene Grace.

I gave my favorite Pokémon a home on my desk, then made my screen time the thing that could hurt it.

Projected impact: a 14-day streak, with Jirachi at level 14.

At a glance

Role
Designer and builder (solo)
Platform
A custom ESP32-S3 handheld and an Android companion app on a Samsung Galaxy Z Fold8
Focus
Behavior design, interaction design, hardware prototyping
Tools
Claude Code, Arduino IDE, Android SDK (Kotlin and Jetpack Compose)

The brief

Problem

Screen time limits on my phone were easy to set and just as easy to skip. Adding more time took a couple of taps, so the limit never really held.

Solution

A device that gives each limit a consequence I care about. Jirachi’s level is my streak of days without bypassing a limit, and bypassing one makes Jirachi faint and resets that streak.

What I Owned

Concept, interaction design, visual direction, hardware build and wiring, and AI-assisted development

Impact (Projected)

Reach a 14-day streak, with Jirachi at level 14, as the first measure of whether the friction holds.

Context

Skipping my screen time limits cost me nothing, so my screen time kept rising.

While I was working, my weeks had a shape. My friends and I worked five days a week, we met up on weekends, and there was always something to do. When I became unemployed and started looking for work, that shape went away. My friends were still free two days a week, and I was free all seven.

Job searching only filled part of that time. There are only so many edits you can make to a resume and portfolio before you’re editing for the sake of editing. Those gaps are where I picked up my phone.

Samsung’s Digital Wellbeing sends a weekly report, and mine kept climbing. Each week it told me I had used my phone more than the week before; seeing those numbers made it clear how addictive these apps are once you have free time.

The first thing I tried was Digital Wellbeing’s app limits. When I reached one, getting back in took two or three taps, and there were no consequences.

I knew that for a limit to change my behavior, skipping it had to cost something.

My 14 days before Serene Grace

  1. 3 or more bypassed
  2. 2 bypassed
  3. 3 or more bypassed
  4. 3 or more bypassed
  5. 1 bypassed
  6. 3 or more bypassed
  7. 2 bypassed
  8. 2 bypassed
  9. 3 or more bypassed
  10. 3 or more bypassed
  11. 2 bypassed
  12. 3 or more bypassed
  13. 2 bypassed
  14. 3 or more bypassed
  • 0
  • 1
  • 2
  • 3 or more

Each square is one day, shaded by the number of apps where I bypassed a limit I had set.

The Idea

I added friction on purpose, and tied it to my favorite Pokémon.

Most of my work as a UX designer is about removing friction, so this project asked me to do the opposite. I asked myself what would actually stop me in that moment, and the honest answer was guilt.

Two other things shaped the idea. I had never built an Android app, only designed for one, so I wanted to make a real, working one. And outside of the newfound doomscrolling, another way I spend free time is working with hardware. A physical device seemed right, because I expected something sitting on my desk to be harder to ignore than another notification.

So I gave my favorite Pokémon a home on a small device and tied its wellbeing to my screen time. If anything could make me put my phone down, it would be the thought of Jirachi fainting because of me.

The name of this project comes from Jirachi too. Serene Grace is Jirachi’s signature ability in the games, and it felt fitting for this type of project.

TL;DRThe idea became this: take my favorite Pokémon, give it a home on a little device, and hold it hostage to my screen time.

The Device

Jirachi lives on my desk, and caring for it is meant to be easy.

The device works like a Tamagotchi. Jirachi has three needs, Food, Joy and Hygiene, and I can address its needs using physical buttons to navigate the interface. The needs drain by the hour, meaning the device isn’t a replacement object for me to be tethered to. Hourly drain lets me check in once or twice a day and otherwise leave Jirachi alone. If I ignore it for days, it does eventually faint from neglect.

Jirachi’s four states side by side: idle, playing, alarmed and fainted
Three device screens mid-care: a berry dropping toward Jirachi, bubbles during a bath, and the ball toss

Jirachi’s level is my streak.

In the Pokémon games, a Pokémon levels up after battles. Here, Jirachi gains exactly one level at midnight for every day I don’t bypass a limit. One of my favorite parts about playing Pokémon is leveling up my team, so watching Jirachi’s level climb is its own reward.

A foe arrives as my time runs low.

Each day, the device picks a foe at random, Groudon or Giratina. The phone tells the device how much time I have left in whichever tracked app I have open, and the encounter builds in stages.

  1. 10 minutes leftThe foe walks onto Jirachi’s screen
  2. 5 minutes leftIt transforms, into Primal Groudon or Giratina’s Origin Forme
  3. 1 minute leftIt charges its signature move, Fire Blast or Last Respects, and a time’s-up screen covers the app on my phone

Then I choose:

I add more time

Jirachi faints

The move lands, and the streak resets to level 1.

I close the app

The foe is defeated

Jirachi uses Doom Desire.

Here is a render of when I close an app:

Four device screens: Giratina walking on at 10 minutes, its Origin Forme at 5, charging Last Respects at 1, and Doom Desire after the app closes
  1. 10 minutes left
  2. 5 minutes left
  3. 1 minute left
  4. I close the app

And here is a live video showing how it works in real time alongside my phone:

Closing the app always wins, even at the last moment, because what I want to reward is putting my phone down.

Spreading the encounter across stages means I can see the consequence coming, and every stage is another chance to stop.

A faint can’t be undone. Pressing buttons, restarting the device or moving out of Bluetooth range won’t revive Jirachi. Only the phone confirming the app is closed brings it back.

I chose foes Jirachi would struggle against.

I wanted each foe to feel like a real threat, so I picked them with Jirachi in mind. Both are legendary-class Pokémon, and both bring types Jirachi is weak to: Fire and Ghost. Primal Groudon is a Fire type, and uses a powerful Fire move. Giratina is a Ghost type, and uses the strongest Ghost-type move possible.

Groudon beside Primal Groudon, and Giratina beside its Origin Forme, as the device draws them

Each app keeps its own encounter.

When I added additional timers, I realized one shared encounter didn’t fit how I use my phone. If I had pushed TikTok to its limit and then opened YouTube with plenty of time left, the foe would show up already charging, as if YouTube were in trouble too. Each timer is its own budget, so each app keeps its own encounter for the day, and a new day resets all of them.

Here is an example of TikTok and YouTube, where I switched between TikTok with 5 minutes left and YouTube with 10 minutes left. Notice that each app keeps a memory of where it is in the encounter with the foe:

Three device screens: Groudon charging on TikTok, back in its base form on YouTube, and charging again on TikTok
  1. On TikTok: charging
  2. Open YouTube: base form
  3. Back to TikTok: charging

The Companion App

The app sets my limits, warns me as they near, and shows the consequence of skipping one.

The Android app sets the timers, measures how long I spend in each tracked app, and tells the device what’s happening over Bluetooth.

I chose a pink palette simply because it’s my aesthetic preference, with small pink labels above rounded cards, one row per item with a short purple status underneath, and heart-shaped switches. Since I have a folding phone, I needed to consider how the app behaves in both folded and unfolded states. When I fold my phone, the three navigation items move into a floating pill at the bottom.

The homepage shows the most important information at a glance: my day streak, whether the device is connected, and each tracked app’s use against its limit.

Home, unfolded
Home unfolded: Home, Timers and Setup listed down the left, beside the Monitoring card switched on, Jirachi’s four-day streak with the device connected, and screen time today
Home, folded
Home folded, scrolled down: Jirachi’s four-day streak with the device connected, screen time today for Reddit, Instagram and TikTok, and the floating pill
Setup, folded
Serene Grace’s Setup page, with its pink labels, rounded cards, purple statuses and heart switches

Each app can have a set schedule.

The plus button lets me add a new timer, and the arrow on each existing timer acts as an indicator that the timer can be edited. The timers can be customized to allow for usage to change day by day, so I can choose to allow more time on weekends and less on weekdays if needed.

Timers
The Timers list: YouTube, Instagram, Reddit and TikTok, each with time left, a usage bar and an arrow
Schedules collapsed
The timer editor with its schedules closed, each showing its time and its week with a dot over each picked day
One schedule expanded
One schedule open in place, with its days and its hour and minute wheels

The app sends warnings ahead of time.

I didn’t want the end of my time to sneak up on me, so Serene Grace sends a notification at 10, 5 and 1 minute, and each warning says what’s happening on Jirachi’s screen.

The 10-minute warning: YouTube, a foe has appeared on Jirachi’s screen

When time runs out, a “Goodbye for today” screen covers the app. It mentions that Jirachi will faint and I’ll lose my streak if I keep using the app. “Close” takes me to my home screen, winning the encounter. “Add time for today” offers choices to add more time with the caveat of reminding me of the consequences before I confirm.

Goodbye for today
The Goodbye for today screen: adding time means Jirachi faints and the 2-day streak is lost
Add time for today
The Add time for today dialog, from 10 minutes to no limit for today, repeating the cost

Testing It on Myself

Daily testing found two bugs that changed how the app counts and ends time.

I tested Serene Grace with real usage and found two problems that I wouldn’t have found from concept alone.

The app counted about half my screen time.

Early on, the app showed that I used TikTok and Reddit far less than I actually did. I pulled the phone’s raw app activity for the day and replayed it step by step. Apps move between their own screens constantly, like opening comments and going back to the feed, and Android sometimes reports that the old screen stopped a moment after the new one started. The app was reading that report as the whole app closing, so it stopped the clock while I was still scrolling.

I changed it to count an app as open while any of its screens is showing, and this fixed the miscount issue.

“Closing” video players like YouTube lets them stay running in a mini view.

While testing with YouTube, I left the app with a video playing and it shrank into a small floating player instead of closing. Serene Grace read that as YouTube closing and gave me the win, so the video kept playing and I kept my streak. This was because my first version of the “Goodbye for today” screen was drawn over the timed app, leaving the video running underneath it.

The phone’s activity log showed that YouTube paused but never stopped while the small player was on screen. Serene Grace now keeps counting an app for as long as that lasts. The time’s-up screen is now a full screen of its own, so the app beneath it stops, and closing it goes home without setting off the small player. If the small player is already open, the screen asks me to close that too. I tested both cases with YouTube on my phone, and both worked.

Under the Hood (the non-UX, hardware stuff)

Read about the hardware

Serene Grace is a device prototype that talks to my phone over Bluetooth.

The device is built on a breadboard with no soldering. A Seeed XIAO ESP32-S3 sits on Seeed’s XIAO expansion board and drives a Waveshare 2-inch color screen (240 x 320 pixels). Six tactile buttons create a D-pad (Up, Down, Left and Right) plus A and B. It runs on USB-C power and sits on my desk.

The bench wiring guide: the XIAO on its expansion board, the six buttons on the breadboard, and every jumper to the display, color coded for ground, 3.3 V, buttons and the display

How it talks to the phone.

My phone and the device stay connected over Bluetooth Low Energy. Every few seconds, my phone sends a small status update with the tracked app I have open and how much time is left. Identifying each app lets Serene Grace keep a separate encounter for each one, and then it uses that information to decide what to show. The device also sends events, like a faint or a win, along with Jirachi’s level, back to the companion app to show my streak. It saves Jirachi’s state to its own memory, so a faint and a streak both survive unplugging it.

The screen’s interface.

The device draws Jirachi, the foes and their animations over a grassland background. If I start a new care action while another is still playing, the newest one takes over. The Jirachi and foe sprites are based on the Pokémon game sprites. The device images in this case study are rendered on my computer by running the device’s own drawing code, so they show exactly what the firmware draws.

Care animations
An encounter with Giratina

Getting the screen to start reliably took the most troubleshooting.

I didn’t want to put too many resources into the build, so I used a lot of what I already had. This meant Frankenstein-ing parts together because I didn’t have the ideal option on hand. At first, the Waveshare screen powered on but showed nothing. When it did finally turn on, many of the colors came out wrong, so I used Claude as my troubleshooting partner to make up for the less-than-ideal hardware.

Another problem was general startup. The screen’s reset was tied to power, so it didn’t reset when the board restarted. This meant that during testing, the screen would stay stuck on one animation when another was supposed to be playing; I would have to unplug and replug the board to get it to show the correct screen. Now the board sends a software reset command to the screen, so I no longer have to unplug it.

My Serene Grace prototype on my desk: the screen showing Jirachi on the grassland, wired to the board and buttons on a yellow breadboard through a tangle of jumper wires

Reflection

Deciding how much friction was enough.

As I mentioned previously, UX designers often remove friction, so on this project I had to decide where friction belonged. I wanted the time’s-up screen to be impossible to ignore without making it so annoying that I would abandon the project altogether.

Learning a platform by building on it.

This was my first time building a real Android app, and I learned the platform by running into its limits. It gave me a greater understanding of app permissions and all the things an app needs to be able to run smoothly on a phone (especially a folding one). Building with Claude Code lowered the barrier to entry and let me try ideas quickly and adjust them just as fast.

Using it myself found the real problems.

It’s easy to let issues with a design slip away when an app or idea stays conceptual rather than real. Because I decided to work with real hardware and implementation, I caught problems that would have slipped by otherwise.

What comes next.

My Frankenstein device still lives on a breadboard held together with jumper wires. Next, I plan to move Jirachi to a much better enclosure, a home upgrade, if you will.

All work

From Ambiguity to Action.

TimelineJuly to October 2025

Fixing the Broken Troubleshooting Journey in Cloud SQL

When a critical database issue hits, users need a clear path to a fix, not a dead end. I led the redesign of the final stretch of the resolution flow in Cloud SQL, turning a disjointed journey into a guided one to build user confidence at scale.

Baseline: <1% resolution rate across 364k+ recommendations.

At a glance

Role
UX Designer
Platform
Google Cloud Platform (Web)
Team
1 PM, 1 UX Manager, 1 UX Mentor, 1 Engineering Manager, 2 Engineers
Focus
Product Design & Enterprise UX

The brief

Problem

Clicking to fix a Cloud SQL issue dropped users onto a generic configuration page with no guidance. They lost context and trust, and fewer than 1% of hundreds of thousands of alerts were resolved.

Solution

The Context Panel, a repurposed sidecar overlay that guides users to the exact setting they need while keeping the key impact details in view.

Outcome

Cross-functional stakeholders approved it as a low-cost, high-value solution. A broader organizational re-org paused the rollout, but the framework set a standard for closing the troubleshooting loop.

01 Problem

When a fix creates more confusion than the original alert, users stop trying.

  • 364,000+database recommendations generated in Q3 2024
  • 21,800database recommendations viewed
  • <1%resulted in user action or clicks

Imagine your computer warns you that your disk is almost full. You click the notification for help, expecting to see which large files to clear. Instead, it opens your entire system settings, and you have to hunt through dozens of menus from memory to find the problem you came to fix.

Cloud SQL users faced something similar. When a database was flagged with a critical issue, trying to fix it dropped them onto a broad, generic configuration page. Their original context didn’t follow them, so they had to search for a fix with no direct help. Faced with that, database administrators (DBAs) consistently chose to do nothing over risking an unverified change to a live environment.

In Q3 2024, Cloud SQL generated over 364,000 database recommendations, and fewer than 1% led to user action. The legacy troubleshooting flow was a dead end, so I was tasked with redesigning the final stretch of the resolution flow to rebuild user trust and make resolving issues practical.

The before — What do I even do here?

02 Discovery & Trust

I wanted to understand why users were ignoring critical alerts.

To understand the problem quickly without running new external studies, I interviewed 8 internal subject matter experts (SMEs). They included the UX researchers (UXRs) who first investigated this space, as well as stakeholders outside UX.

Pulling their insights together showed a serious lack of trust. DBAs ignored the recommendations because the UI didn’t show what a fix would affect. As one user put it:

“My application has 100 active users, but if I enable this [fix], then it will shut down. What about these 100 users?”

Lead Cloud Architect, Anonymous

It became clear that to get users to act, the design had to show the consequences, like downtime and cost, before they committed to a fix.

03 Strategy

Weighing technical trade-offs helped us find the most user value for the least engineering cost.

I explored four concepts to solve the context loss, ranging from a lightweight “Context Card” to a highly complex “Integrated Subtask.”

Concept 1: The Context Card

A persistent card that kept issue details visible while auto-scrolling to the relevant setting. It was a strong start for maintaining context, but too lightweight for high-stakes database tasks.

Concept 1, the Context Card: the Auditing not enabled issue kept in a card beside the Flags setting it points to

Concept 2: The Integrated Subtask

This involved resolution components embedded directly in the subtask view for an all-in-one workflow. It was intuitive, but the UI was complex and would have taken significant engineering effort.

Concept 2, the Integrated Subtask: an issue panel with its insight, recommendation and a Take action field to add the database flag

Concept 3: The Issues Tab

A forward-looking vision for managing alerts at scale through bulk resolution. It was highly efficient for large fleets, but it didn’t solve the immediate, single-instance troubleshooting path.

Concept 3, the Issues Tab: instances grouped under No password policy, with Apply fix to selected

Concept 4: The Recommendations Hub

A central surface for comparing multiple resolution options and their trade-offs side by side, so users could pick the fix that suited them best.

Concept 4, the Recommendations Hub: two fixes for high CPU compared side by side, each with projected usage, cost change and Apply

The wall

In a cross-functional review with UX and Engineering, we hit a technical wall. Our preferred concept, the Integrated Subtask, required building a new component, and we didn’t have the resources to do that at the time.

Final pick

To bridge the gap, I designed a hybrid “Goldilocks” solution. I took the context-preserving mechanics of the Context Card and combined them with an existing panel component already built for Database Center. The result was the Context Panel. It gave users the context they needed and removed the cost of building a new component from scratch.

Concept 1, the Context Card: the Auditing not enabled issue kept in a card beside the Flags setting it points to

Context Card mechanics

plus
The existing Database Center side panel, listing a resource’s issues as expandable cards with next steps

Existing Database Center panel

equals
The Context Panel: an instance’s issues as expandable cards, each with next steps, a downtime note and a button to its setting

The Context Panel

04 Final Flow

I guided users to the right setting but left the change in their hands.

The Context Panel brings the issue and its resolution into one view. It auto-scrolls the user straight to the relevant setting on the configuration page.

In high-stakes enterprise database environments, filling in configuration changes automatically created too much risk of users applying a fix without fully understanding it. So the panel scrolls to the exact spot but still requires users to make the change themselves. That closes the navigation gap and keeps the action intentional and verified.

Below is the final design and the user journey it supports:

  1. Investigate issue
  2. Click CTA
  3. Solve primary issue
  4. Fix additional issues
  5. Save changes

05 Outcome & Reflection

I closed the troubleshooting loop and found the next opportunity at fleet scale.

  • Approvedby cross-functional stakeholders
  • Fleet scaleidentified as the next opportunity

The Context Panel turns a dead-end journey into a guided workflow. It’s designed to keep critical issue details visible throughout the fix, so DBAs don’t have to rely on memory, and it positions Cloud SQL to improve on its resolution rate of under 1%.

Shortly after the team aligned, a Google Databases-wide re-org shifted priorities and paused engineering work. The project still left a lasting impact. It gave the team a low-cost blueprint for single-instance troubleshooting, and it reinforced a UXR insight that DBAs need bulk resolution tools at the fleet level. The Context Panel solved the immediate navigation problem, and it set up the next step in managing database issues at scale.

All work

Charting the Migration.

TimelineJuly 2025

I helped settle a design debate over a migration flow through usability testing with six enterprise customers. Our comparison of the two approaches led the Google Compute Engine team to adopt a database-first recommendation.

6 participants. 2 approaches. 1 adopted recommendation.

Estimated revenue opportunity: $8.32M.

At a glance

Role
UX Research Collaborator
Platform
Google Compute Engine (Web)
Team
1 Senior UXR, 1 UX Designer, 3 PMs, 4 Engineers
Focus
UX Research & Enterprise UX

The brief

Problem

Moving complex Oracle workloads to Google Compute Engine (GCE) meant going through an intimidating configuration flow. The team was split between two approaches and risked shipping an experience that didn’t match how infrastructure teams actually work.

Solution

A dual-track usability study using the RITE (Rapid Iterative Testing and Evaluation) method and live AI Studio prototypes. It settled the debate and validated the key features that were missing.

Outcome

The product team adopted the recommendation as the baseline, and we got it onto the roadmap right away. That cleared the way for an estimated $8.32M migration pipeline. Read the official blog post.

01 Context

When internal teams are split, guessing at the right UX can stall millions in enterprise migrations.

Migrating an enterprise Oracle database to Google Cloud means configuring dozens of variables across compute, storage, networking, and licensing. It’s a notoriously stressful process for the database administrators (DBAs) and infrastructure architects who manage it.

I was brought in to help run a rapid usability evaluation that would settle the debate based on what users actually preferred. The result affected a PM-projected $8.32M pipeline tied to the Oracle partnership.

At the center of the debate were two provisioning flows that Google Compute Engine (GCE) had drafted to ease the transition. The team was split down the middle:

Flow A

Organized by infrastructure components first (networking, regions, VMs).

Flow B

Organized by database configuration first (edition, sizing, workload context).

Flow A and Flow B navigation side by side, Flow A opening on deployment basics and Flow B opening on the database

02 Methodology

We tested database provisioning on two tracks to break down its complexity.

  • 6Google Cloud
    customers
  • 60 minremote sessions
  • 2parallel testing tracks

We ran 60-minute remote usability sessions with six current Google Cloud customers who had decision-making power over their organizations’ database architectures.

Our senior researcher led the interviews, and I owned the operational side. I recorded the raw data, co-built the rapid prototype changes in AI Studio, and synthesized the findings into the final technical report and presentation.

We split the testing into two tracks so we could settle the layout debate and still iterate on design feedback as it came in:

Evaluative testing

Participants stress-tested static Figma concepts for both Flow A and Flow B.

  1. Figma concepts of Flow A and Flow B
  2. Participants stress-test both
  3. Settles the layout debate

Rapid Iterative Testing (RITE)

To go beyond picking A or B, we used AI Studio to build flexible, “vibe-coded” prototypes. By prompting it, we generated hi-fi changes on the fly and updated the UI both during and between sessions. That let us test feedback in near real time and ask users directly, “Is this what you meant?”

  1. Feedback in session
  2. Prompt AI Studio
  3. Updated hi-fi UI
  4. “Is this what you meant?”

03 Discovery & Alignment

We settled the structure by looking at how users think about deployment.

Testing showed that user preference came down to their mental models of physical deployment. Flow A split opinion because it made users configure networking and regions before defining the database itself, which reversed the order they naturally follow when setting something up.

Why Flow B won

Flow B matched how infrastructure teams actually think. Expert users needed to establish the database edition, sizing, and workload context before touching the underlying virtual machines. Setting the overall database scale first gave them the context to pick machine families and storage accurately later.

Solving section fatigue

Both static flows overwhelmed users once a section passed eight configuration fields. Using our live prototypes, we showed that progressive disclosure was the fix. A multi-page setup capped at 5 to 6 logical groupings per page cut out endless scrolling and kept users focused on the task in front of them.

Three setup navigations side by side: Flow A from deployment basics, Flow B from the database, and the vibe-coded RITE flow in seven numbered steps

04 Strategy

Live prototyping surfaced two features the flows were missing.

The RITE testing data helped us identify and validate improvements for the immediate roadmap. By updating the AI Studio prototype on the fly, we surfaced and validated two key features:

Real-time cost transparency

Users felt blind to cost, and it was their top complaint. We tested a live estimator panel that updated instantly with every selection, so users could see the financial impact of their setup right away.

“T-shirt sized” deployment templates

Starting from a blank canvas made users hesitate on non-production builds. We tested pre-configured Dev, Staging, and Production templates that let users launch a basic setup in a few clicks while keeping full control of the configuration.

A Start with a Template page offering Development, Staging/UAT, Production or Start from Scratch, annotated: allows users to deploy quickly

05 Outcome & Reflection

Fast research turned into a product decision.

  • Flow Bunanimously adopted as the product baseline
  • $8.32Mprojected migration pipeline unblocked
  • 2features carried onto the roadmap

Our evaluative findings gave the GCE team the user data it needed to finalize Flow B as the product baseline and break the internal tie.

This project showed me how much real-time iteration is worth. I tweaked the AI Studio prototypes between and during sessions, so we could check user input right away and didn’t have to guess what might work. That gave us confidence that our final recommendations matched what enterprise users needed. The features we validated through the vibe-coded prototypes were also added to the roadmap for future iterations.

What my research collaborator said

“Thanks for your great work with the Oracle on GCE usability study. I was really impressed with the way you were able to jump right in on a novel and complex topic and your willingness to just go for it. I expected to get some assistance with note taking and basic analysis. Instead, you were able to take over the entire synthesis and write up of findings with very little input from me. And then you went ahead and made a really beautiful, well organized deck for the read-out, even though you didn’t have to. Thanks for making me look so good in front of stakeholders! :)”

Chantrelle J., Senior UX Researcher, Google Cloud Platform