Rootly

Driving adoption & understandability for an AI‑native incident platform used by NVIDIA, LinkedIn, Figma.

Driving adoption & understandability for an AI‑native incident platform used by NVIDIA, LinkedIn, Figma.

Driving adoption & understandability for an AI‑native incident platform used by NVIDIA, LinkedIn, Figma.

Timeline

August 2025 - present (Ongoing)

Team

1 Product Manager, Head of Engineering, 2 Senior Designers, 5 Engineers

Result:

Scoped and shipped UX improvements under minor mentorship; led research synthesis, interaction design, microcopy, specs, and QA.

Result:

Scoped and shipped UX improvements under minor mentorship; led research synthesis, interaction design, microcopy, specs, and QA.

Result:

Scoped and shipped UX improvements under minor mentorship; led research synthesis, interaction design, microcopy, specs, and QA.

TL; DR

What is Rootly?

I joined Rootly on their Product team as their Design intern, and moreover, as the company’s first-ever intern. Rootly is an AI-native, enterprise-grade incident management platform loved by 100's of leading companies such as Cisco, NVIDIA, Figma, Squarespace, Canva, and more

The Problem

Rootly’s product velocity helped us win marquee customers, but it also introduced UX inconsistencies that slowed adoption and created friction during evals against mature incumbents.  I led a cross‑functional “Goodness Items” initiative—high‑impact, low‑effort refinements—to raise the baseline product quality without slowing delivery.

The Solution

In my first month here, I’ve worked with 5 engineers to ship 100+ UX “Goodness tickets” that improved demo clarity, reduced support questions, and gave on-call teams safer defaults.

In my first month here, I’ve worked with 5 engineers to ship 100+ UX “Goodness tickets” that improved demo clarity, reduced support questions, and gave on-call teams safer defaults.

In my first month here, I’ve worked with 5 engineers to ship 100+ UX “Goodness tickets” that improved demo clarity, reduced support questions, and gave on-call teams safer defaults.

The Strategy

From papercuts to product confidence

I framed the work in an impact‑effort matrix and intentionally operated in the Quick Wins quadrant: small surface changes with outsized effect on comprehension and flow.

Success Metrics

Business: Must enhance product quality, usability, and customer satisfaction.

Design: Minimal engineering risk; that other product engineer interns could jump on and clear out

Product: Small, well‑placed refinements compound into a cleaner, more joyful product. 

Goals set collaboratively by me, a senior designer and a PM

Design Challenge #1

Design Challenge #1

Expanding options for Escalation Policies
Expanding options for Escalation Policies

Currently in our web app, users could repeat an EP a set number of times (max 9), but not indefinitely or by duration. Norstella and Prolific (our 2 customers) standard is to continue to page the on-call user until they acknowledge the alert.

  • For the teams that escalate to only 1 level, they need each user to be able to set their personal escalation logic to repeat indefinitely until the alert is acknowledged

  • For the teams that escalate to multiple levels, they need the escalation policy to be able to repeat indefinitely until the alert is acknowledged


The pain point is we don't support indefinite repeats on personal notification settings nor escalation policies. 

To solve this, I created a new EP repeat flow to use a concise inline read-only summary with an edit icon that opens a side panel offering mutually exclusive options, plus an optional fallback to escalate to a person, team, service, or another EP if still unacknowledged.

Looking into the conventions
Looking into the conventions

I studied into the escalation policy of PagerDuty, Incident.io. - our main competitors to see what they have to offer. This made me came to the realization that the ask of indefinite loops is risky since all of them has some sort of endpoints or definite limit.


After discussing with the PM, we've decided to narrow the scope: instead of repeating indefinitely, the EP now repeats within a defined time window starting at alert creation and stops when that window ends.

I studied into the escalation policy of PagerDuty, Incident.io. - our main competitors to see what they have to offer. This made me came to the realization that the ask of indefinite loops is risky since all of them has some sort of endpoints or definite limit.


After discussing with the PM, we've decided to narrow the scope: instead of repeating indefinitely, the EP now repeats within a defined time window starting at alert creation and stops when that window ends.

I studied into the escalation policy of PagerDuty, Incident.io. - our main competitors to see what they have to offer. This made me came to the realization that the ask of indefinite loops is risky since all of them has some sort of endpoints or definite limit.


After discussing with the PM, we've decided to narrow the scope: instead of repeating indefinitely, the EP now repeats within a defined time window starting at alert creation and stops when that window ends.

Explore and deliver

At its core, EP allows the user to choose how an alert should repeat, which can be done in several ways.
1) Repeat a number of times (i.e. up to 9 loops)
2) Repeat for a set duration (i.e. every X minutes for up to Y minutes from alert creation)
3) No repeat (i.e. send once without retries)


I had many different ideas, but it boiled down to 3 best different versions of how we can communicate 3 distinct choices

At its core, EP allows the user to choose how an alert should repeat, which can be done in several ways.
1) Repeat a number of times (i.e. up to 9 loops)
2) Repeat for a set duration (i.e. every X minutes for up to Y minutes from alert creation)
3) No repeat (i.e. send once without retries)


I had many different ideas, but it boiled down to 3 best different versions of how we can communicate 3 distinct choices

At its core, EP allows the user to choose how an alert should repeat, which can be done in several ways.
1) Repeat a number of times (i.e. up to 9 loops)
2) Repeat for a set duration (i.e. every X minutes for up to Y minutes from alert creation)
3) No repeat (i.e. send once without retries)


I had many different ideas, but it boiled down to 3 best different versions of how we can communicate 3 distinct choices

Result: We adopted Choice 3 - a read-only summary. Although the alternatives followed familiar patterns and aligned with the previous design, they introduced excessive vertical bloat to an already decision-heavy flow, The read-only surface a clear, single‑sentence summary at a glance, and defer complexity to a focused drawer.

Result: We adopted Choice 3 - a read-only summary. Although the alternatives followed familiar patterns and aligned with the previous design, they introduced excessive vertical bloat to an already decision-heavy flow, The read-only surface a clear, single‑sentence summary at a glance, and defer complexity to a focused drawer.

Result: We adopted Choice 3 - a read-only summary. Although the alternatives followed familiar patterns and aligned with the previous design, they introduced excessive vertical bloat to an already decision-heavy flow, The read-only surface a clear, single‑sentence summary at a glance, and defer complexity to a focused drawer.

Design Challenge #2

Remove ambiguity in workflow logic

When configuring their workflows, the users can set different conditions for their workflows. However, in this series of conditions the users can choose, Inactivity Duration revealed a dropdown with a single option (“for”) and a free‑text field with no guidance. Users didn’t know units or formatting. 

Before

Make the control read like natural language using…

  • Read-only token: Replace the single-option dropdown with a static token “for” to anchor the sentence.

  • Number field: Add a value entry field with inline validation (range, required, numeric)

  • Unit selector: Provide a compact selector with three explicit units—seconds, minutes, hours—optimized for keyboard and screen readers.

After

Providing context with tooltip

By adding a tooltip that defines "Inactivity Duration", I clarify with intent & timing and its relation to conditional workflows

Leading the front-facing visuals

I originally joined to elevate our marketing materials and led the rebrand from audit to launch. I refreshed pitch and keynote decks, redesigned our event and social assets, and produced speaker/partner kits that supported external presenters—including OpenAI, Replit, and Anthropic.

✦ A lens into the future

With only 1 month into my internship and 3 months remaining, these compounding “Goodness Items” has quickly turned confusing knobs into features that has already been implemented, we raised the baseline without slowing delivery, making demos clearer and on-call safer. Here’s what I learned and would scale next.

──── ୨୧ ────

Key Takeaways

🔎 Atomic changes can create colossal difference

The real win travels beyond EP setup into workflows and forms—it was a repeatable quality playbook. I’m highlighting 3 representative tickets here, but I’ve led the first cohort of intern to ship 20+ “Goodness Items” using the same approach: impact–effort triage to target quick wins. Because this playbook now lives in our Notion.. The compounding effect is clearer demos, fewer configuration questions, and faster time-to-first-value.

🛠️ Working within constraints & systems

Early on, I assumed “custom” meant “better.” Watching senior designers in standups shifted my view: using the system is what makes cross-functional work click. Staying within constraints reduces churn for devs and proves I can design at organizational scale: aligning with product goals, respecting technical realities, and contributing improvements back to the system when a gap appears.

You might find these projects interesting ٩(ˊᗜˋ*)و