Selected work
MagicSchool AI · 2026
Teachers loved our outlines but had to rebuild them as slides. I led the redesign that turns one prompt into a classroom-ready, editable deck, shipped in about a month.
Read case study ›Key results since launch
Data as of Oct 14, 2026
MagicSchool AI · 2026
MagicSchool had grown one feature at a time. I led the information architecture redesign that made it one coherent product, aligned every squad it touched, and shipped for back to school.
Read case study ›Key results
How I work
I turn dense, technical domains into products people can actually use. Across digital analytics, process intelligence, and AI, I ramp up fast, frame the ambiguity, and find the simple path through it.
I've led design system work at Quantum Metric and MagicSchool, and contributed to the systems at every company I've been part of. I think in systems beyond components: shared patterns, information architecture, and decision frameworks that keep teams aligned and help them ship faster without losing quality.
I shape what gets built, not just how it looks. I partner with product, engineering, and research to frame problems and guide roadmap tradeoffs, and I've grown teams, including building the design and research functions at Quantum Metric.
I've kept learning through every shift in how products get made. Today AI is built into how I explore, prototype, and test, so I can validate ideas faster and bring sharper evidence to every decision.
I’m a Staff Product Designer in Denver with 12+ years of experience, now focused on designing AI-native products. I shape how people work alongside AI, from conversational experiences to the workflows and patterns that scale across teams.
I prototype in code and ship PRs, using AI to move from idea to production faster. Still, I’d rather solve hard problems with good people than easy ones alone, and building faster has only made that truer for me. When everyone can bring a prototype to the table, I love being the one who steps back to see how the ideas fit together into one experience for the user. I thrive on teams that move quickly but make time to align, where I can learn from the people around me and help others grow.
Experience
MagicSchool had grown one feature at a time, and its structure couldn't hold where the product was going. Before deciding what to build, I led discovery across product data, research, and a full audit of the platform. That work defined four new surfaces and an updated sidebar navigation, which we designed and shipped for back to school, halving the time it takes a teacher to create their first output.
Problem
We planned to keep adding features, but there was never an obvious place to put them. Each one landed in an increasingly busy sidebar as one more option for teachers who already felt overwhelmed, instead of fitting into their natural workflow as educators.
Meanwhile, Amplitude showed that teachers who used Raina, our AI chat assistant, were 2x more likely to come back than those who used Teacher Tools. Our hypothesis: Raina gave educators faster, more useful results for their roles, while teachers described the rest of the product as overwhelming and impersonal.
That made Raina more than a chat feature. As both a professional copilot and an instructional tool, it could become the entry point into deeper adoption of the rest of the product.
Before: every teacher landed on 80+ tools, with features nested in sidebar folders.
After: Raina at the top of a personalized homepage, with a flat, simplified sidebar.
The sidebar on its own, before and after the redesign.
Alignment
This work wasn't on the roadmap. With no dedicated PM, I drove alignment myself to build momentum, earn buy-in, and secure dedicated resources, starting with leadership. I brought them into working sessions to define the product vision around four inputs: teachers' biggest pain points, what the business needed, what would help sales, and our shift toward enterprise, which shaped what we needed to offer schools and districts beyond our Free and Plus tiers.
That vision shaped decisions across the whole product, touching every squad's surfaces and metrics, including how the admin experience fit into the new structure. I worked with each of the three squads to understand where the new structure might help or hurt them, and used the shared vision to guide tradeoffs.
AI made that alignment move much faster. I used Claude as a thought partner while mapping flows, built rapid prototypes as part of ideation (first in Lovable, then in Claude Code), and iterated on them quickly with each team so everyone could see and react to the same vision.
Process
Before choosing what to change, we needed to understand where the structure was failing and where the product was headed.
Combined feedback from the many channels where we hear from users (teachers in the product, our sales and training teams) with Amplitude data on where teachers actually engaged.
Feedback + AmplitudeTurned what we heard into an audit of chat history, output actions, output quality, and navigation, mapping every nav item and capability.
FigJamSee the audit ↓Reviewed competitors and other products teachers already use to find familiar patterns. Then generated and compared many navigation structures and pressure-tested the best against real scenarios.
Competitive review + ClaudeSee an option ↓Built clickable versions to compare a first-time teacher's path with a returning teacher's day.
Lovable + Claude CodeReviewed the structure with squads and leadership to catch edge cases before testing with teachers.
Reviews
This wasn't a linear process. We moved back and forth between exploring, prototyping, and pressure-testing many times before landing on a direction.
What we found
Each of these areas came straight out of what teachers and our customer-facing teams kept telling us, and the usage data backed it up.
Opportunities
Each became its own project. We validated the new navigation inside these surfaces as we built them, since the real test of a structure is whether it gets people where they're going.
Outcome
Teachers reached their first output in half the time, and Raina became both the front door to the product and the reason teachers kept coming back.
Teachers who moved to the new product say the flat sidebar makes things noticeably easier to find.
"Everything feels like it is where it should be."Educator, after launch
"I like this so much better. It's a cleaner interface. It's more personalized to me, and I don't have to click into a bunch of different places to get things. If I want something, it's right there."Middle school teacher, after launch
What's next
With a short timeline, this launch was the first iteration of a more streamlined workflow, not a finished experience. We made deliberate cuts to ship well for back to school, and they shape what comes next:
MagicStudent, including student rooms where educators build custom chatbot experiences for their students, stayed out of this launch. Next, we're connecting Teacher Tools, student experiences, and Raina so moving between them doesn't feel like switching products.
Organizing the product around classes would be a massive change to the experience and a large technical lift. We're giving it more research and validation before committing.
Celonis customers were improving their processes, but had no single place to prove what those improvements were worth. I designed how opportunities go live with tracked value, and the Value Report that shows the business impact, launched at Celosphere 2023.
Problem
Teams used Celonis to find and fix process inefficiencies, like paying vendors too early and tying up working capital. But the value of those improvements lived in scattered places. Analysts couldn't easily track it over time, and leaders couldn't see how their programs were paying off.
It was built for two audiences: Value Engineers, who tracked value with customers in the short to mid term, and Celonis leads inside customer companies over the long term. For Celonis, it was also a growth lever. Turning process performance into money made the case for expanding Celonis across a customer's business.
My role
When I joined, another designer had designed the first step: creating an opportunity. But a created opportunity didn't track anything yet. To go live, it needed its framed and realized value.
That's where my work started. I designed the flow for taking an opportunity live, then the Value Report that becomes available once its data is being tracked. I worked most closely with my PM and lead engineer.
Setup
Before prototyping, we used flow charts to align on every piece of data needed to get an opportunity live and tracking, so the Value Report would have what it needed. They also showed where we could recommend a formula instead of asking for one.
We then ran many moderated usability tests on our prototypes to find out what made setup hard to complete. Two principles came out of that work:
Wherever possible, we used data Celonis already had, like existing KPIs and recommended formulas, so users didn't have to enter it themselves. Value tracking could be set up with no code.
We tested and refined the wording and directions throughout the flow, avoiding terms that weren't meaningful or were too complicated for users.
Data latency
Research showed that data took time to arrive. Value tracking might be set up today, but charts wouldn't fill in for days. I mapped exactly what each page would show, and when, for every stage of an opportunity:
| Status | Opportunity list | Value Report | Opportunity detail |
|---|---|---|---|
| No drafts | Empty | Empty | Doesn't exist |
| 1+ draft | Available | Empty | Available |
| 1+ live, no data yet | Available | Available, with empty states | Available |
| 1+ live, with data | Available | Available | Available |
That map defined the empty states. Instead of blank or broken charts, users saw clear messages, like confirming tracking was enabled and how long to wait for data, or explaining that no opportunities existed yet for a value driver.
Value Report
Interviews kept telling us the same thing: people didn't want a complex dashboard. The person using this report was usually presenting value to an executive team, and needed something concise that fit into a slide. We iterated on the design to keep it focused, and added a quick way to export each chart.
Celonis had a design system, but no data visualization. I worked closely with the design system team to create the charts the Value Report needed, and contributed them back to the system so other teams could use them.
Outcome
Transformation Hub was announced at Celosphere 2023, Celonis's annual user conference, and became generally available that November. It gave analysts one place to manage and track value opportunities, and gave executives a Value Report to see how their teams' work was driving results.
Quantum Metric could show what happened in a single session, but not the paths across thousands of them. I designed Sankey and Sunburst diagrams that show how users move through a product, and connected every path back to the session replays behind it.
Problem
Product, UX, and analytics teams needed to know how users reached the outcomes that mattered, like checkout or registration, and where they dropped off or hit dead ends along the way. Answering that meant piecing together reports, with no way to see the paths themselves.
Approach
The work was highly technical by nature. A journey diagram has to turn thousands of sessions into a small set of shapes people can read at a glance. We built it in about one to two months with a PM and lead engineer, guided by three questions: how do we show it, will people trust it, and how does it connect to the rest of the product?
Two views
Every journey looks different. Being limited to one chart type, when it isn't the right fit, makes the data harder to read. So I designed two, and teams could choose the one that matched their question.
Paths flow from one common entry point, like the home page, out to outcomes such as checkout, help pages, or early exits. Hovering a destination reveals the journeys that led there. Best for linear, start-to-finish paths.
The starting point sits in the center, each step forms a ring, and the outer ring shows the outcomes. A compact, multi-layered overview that handles dozens of outcomes without scrolling or zooming, and teams can switch the metric, like conversion rate, session count, or business value.
Making a Sankey readable came down to designing three building blocks:
The blocks that represent each stage of a journey, like a page or event, where users start, pass through, or end.
The curved bands between nodes. Their width shows how many sessions moved between steps, so the biggest paths stand out first.
The shaded base of each node shows the sessions that left at that step, so the places users abandon a path stand out at a glance.
Teams weren't limited to clicking around the chart. They could set their own parameters for the journey, and only sessions that matched were included:
The entry point tracking begins from, like a landing page or app open.
A step a session has to pass through to count, like adding to cart.
The conversion or exit where the journey stops, like checkout.
The chart maps the start in the first column, the steps users took in between, and the end or drop-off in the last. Hovering any node shows its sessions, drop-offs, conversion rate, and conversion value, with shortcuts to make it the new start, required step, or end. Clicking a node or path updates a small dashboard below the chart, so teams see the metrics that matter for exactly that journey: platforms, top clicks, events, and errors.
Hover a node for its key metrics and shortcuts to refocus the journey.
Clicking updates the breakdown dashboard below the chart.
Hovering a ring highlights that path from the center out, and a side panel lists every step with its share of sessions and the drop-off between steps. From there, teams can turn the path into a funnel or a segment in one click.
Every path from the starting point, with the total sessions at the center.
Hovering highlights one path and fills the side panel, ready to create a funnel or apply a segment.
Connected
A chart can show where users drop off, but not why. So we connected journeys to the rest of Quantum Metric. Teams could click a specific drop-off or path and watch the real sessions behind it, so they could diagnose the exact UX or technical roadblock instead of guessing.
Every interaction could also become a segment. When teams moved to other parts of Quantum Metric, the segment carried through with them, so an investigation that started in a chart could continue across the whole product without rebuilding the filter.
Outcome
Sankey and Sunburst diagrams became a core part of Quantum Metric's customer journey analytics, giving teams a new way to see how users engage with their products, and a direct path to the sessions that explain it.
Our presentation tool only produced an outline. I led the redesign that turns a single prompt into classroom-ready slides with images, themes, and layouts, shipped in about a month.
Problem
The old tool gave teachers a text outline for a slide deck. To turn it into real slides, they copied the content into Canva or Google Slides and built the deck themselves. It was cumbersome, and it worked against our mission of saving educators time.
Teachers loved the content of the outline, but they consistently asked for an actual slide format. A few even emailed asking for refunds because the capability was missing.
Discovery
Time to value is top of mind in every project, because our mission is saving educators time. Teachers should get to a real slide deck as quickly as possible.
Decks had to keep the quality of the outline teachers already loved, and step up to being age-appropriate in both the content and the images.
We did a deep dive into how others approach presentations, including Curipod, Nearpod, Brisk, Canva EDU, and Gamma. Teachers' recurring complaints about AI slide tools became our bar to beat: too much text, generic repeated images, repetitive layouts, no teaching structure, over-decorated elementary decks, and the wrong reading level.
We also studied 720 real requests sent to the old tool, which showed what teachers actually ask for:
The solution
Teachers can now prompt from Raina or the updated teacher tool and get back a complete, visual slide deck in one step, with nothing to copy into another tool.
The "made for you" deck is built from two things: the prompt, and what we already know about the teacher from their profile. The content adjusts to the grade or student level they choose, and the deck arrives with a full-bleed title image, layouts matched to the content, and a theme generated to fit the topic.
I've been training Raina on the rules behind that theme. Using Cursor, I wrote a recipe that tells the AI which decor, ground, and motif to pull for each prompt, so a space lesson and a poetry unit each get a look that fits.
Twenty-three design rules, drawn from Mayer's research on how people learn from words and pictures, ship inside every deck. A few of them:
Teachers also build classroom expectations, dismissal routines, staff agendas, and icebreakers. Before writing a slide, the generator decides what kind of deck it is building, so a dismissal routine never gets forced into a lesson structure.
The grade band sets the reading level and how much text each slide carries. Decoration is quieted for K-2, and decks for staff or adults switch to an adult voice.
Within a second or two, themed slide cards appear, take their titles, and fill with content as the slides generate in parallel. There is no outline to read through, only a deck coming together.
Editing
The made-for-you deck is the starting point, not the only option. Teachers can refine it two ways: by asking Raina, or by working directly on the slides. Selecting a slide or a line of text scopes the chat to it, so a teacher can ask for a rewrite or a new image for just that piece. Raina says what it is about to do, and if a request can't be carried out, it says nothing changed instead of claiming it's done.
For hands-on edits, the editing panel works in layers. A contextual toolbar switches based on what the teacher has selected, so the options they need are always one click away.
With nothing selected, the toolbar shows themes. For teachers who want a different look, I designed a set of presets: Light, Dark, Magic, Playful, Chalk, Notebook, and Scholar. Light removes every background element so teachers can print quickly and cheaply.
Bright shapes and warm color, made for younger grades. The most used theme after Made for you, chosen in 38% of theme switches.
Selecting a slide switches the toolbar to eight layouts, so teachers can restructure a slide without rebuilding it. The content reflows into the new layout.
A full-bleed image with the title on top, used to open the deck.
Clicking into text switches the toolbar to formatting and alignment.
Outcome
We kicked off in August and launched about a month later. It passed 1 million generations in the first month, and teachers kept coming back.
Data as of Oct 14, 2026
Teachers also shared how they were already using it with their students.
"I just did one for Ethos, Pathos, and Logos and was able to get visuals that would really capture my students' understanding! This is amazing!!"Teacher, after launch
"This is a game changer! I can see using this for quick interactive lessons with my reading groups, to generate quick creative writing ideas."Bilingual academic interventionist, after launch
What's next
We're already iterating on what comes next:
MagicSchool was shipping fast on hardcoded styles and one-off components. With two front-end engineers, I made the case for a design system, got it funded, and built Spellbook, which now runs 100% of the app, with accessibility built into every component.
Before Spellbook: hardcoded styles and one-off components.
First Spellbook release, 2025, which also introduced a dark theme.
Latest: the redesigned platform, built on Spellbook.
The pitch
In March 2025, MagicSchool had product-market fit, new funding, and big plans. Two front-end engineers and I wrote "Spellbook UI 101" to get a design system funded and resourced. It became the company's first large, company-wide initiative.
Engineering had grown far larger than our new design and product teams, and features were shipping fast.
Hardcoded colors, ad-hoc styles, and no reusable components meant design drift, duplicated work, and growing tech debt.
How do we scale speed and quality with as little dedicated headcount as possible?
Invest in a design system now, built to need minimal headcount.
The ask was simple: dedicated engineering time, a design partnership, and leadership treating the system as critical infrastructure. We pointed to Shopify's Polaris, IBM's Carbon, and Adobe's Spectrum. Those companies didn't build systems after they got big. Investing early helped them get there.
Approach
We chose shadcn as our technical approach and adapted the Wedges Figma kit's variables to our brand instead of starting from scratch. That got design specs and behaviors to engineering on the shortest possible timeline. The CTO and the entire engineering team bought in and approved the plan.
Color, type, spacing, and layout came before any component.
We mapped what the old app needed and built those components first.
The three of us split the work and met daily to stay in sync.
Engineering converted the entire old app onto the system.
Throughout, we kept leadership as close to our progress as possible, with weekly updates in our syncs and a shared Linear board where anyone could see our tickets.
Spellbook
Contributions
Ongoing contributions run through our design system guild. Most start when a new feature design exposes a gap.
Recent examples from 2026:
Select and act on many rows at once, first built for chat history.
See chat history →Smaller buttons for new capabilities like text editing in a toolbar.
Accessibility
Accessibility is built into how we make components, not added at the end. When a component is accessible in Spellbook, every page that uses it inherits that work.
Before a page is released, we review it for accessibility as part of shipping. That system-level approach is a big part of how we passed our VPAT, the accessibility report schools and districts rely on when choosing tools.
Shared ownership
Design and engineering now share ownership of the documentation. With Cursor and Claude Code, designers ship PRs too.
Having the system has become a massive advantage. Because our components, rules, and usage guidance live in one place, anyone can prototype quickly with Claude and Cursor and still stay within our guidelines.
MagicSchool's tools were spread across different parts of the sidebar. I designed one page where teachers can find every tool the product offers, built to keep working as the feature set grows.
Problem
Tools lived in different sidebar sections, so teachers had to jump between them to find what they needed. Every new feature made the problem a little worse.
The solution
All Tools brings every tool into a single page. It works hand in hand with the homepage: the Recommended for you module shows a personalized subset, and links to All Tools when teachers want to see everything.
A personalized subset of tools, based on each teacher's role and how they use the product.
Every tool in one place, built to absorb new features without another reorganization.
Saving work was buried in a folder most teachers never found, and it only worked for some outputs. I led the redesign that gave saved work its own place in the product, from any source, with a finished view of every material.
Problem
Resources lived inside the Magic Tools folder in the sidebar, and many teachers didn't know it existed. Saving was also only available for teacher tool outputs, so anything made with Raina couldn't be kept there.
That gap grew as Raina usage climbed and Studio, our dedicated split-screen editor for refining documents right next to the chat, made it easier to turn a response into a finished material. Teachers were putting real effort into their work, with no clear place to keep it.
We also saw a bigger opportunity. Saved work had never had a finished state, and our hypothesis was that a final view would encourage teachers to share what they made.
The solution
We moved saved work into its own place in the sidebar, renamed it My Resources, and built it around three actions:
Save a material or response from a teacher tool or from Raina.
Open any saved material to see it as a final, polished document.
Share, export, or download it, or jump back into Raina with the material already open in the thread.
What's next
We launched with a data table, but saved resources are visual, and thumbnails will make them easier to recognize at a glance. We're adding a toggle to switch between table and card views, with each card previewing its material.
That matters more as the range of things teachers can save grows, including generated images and presentation decks, which launched in early October 2026. We also explored translation from the final view, which the finished view now gives a natural home.
Teachers' past work lived in two different places, depending on whether they made it with a tool or with Raina. I led the redesign that brought every output into one history with search that looks inside the work itself.
Problem
MagicSchool logged outputs in two places. Work made with a teacher tool went to Output History, inside a Magic Tools folder in the sidebar. Work made with Raina, our AI chat assistant, showed up in a panel on the right of the chat.
Over time, the outputs from tools and Raina became nearly identical, and teachers stopped remembering which one they had used. Finding past work meant guessing where to look. That hurt most when they had spent time refining a lesson or worksheet to fit their class.
Search didn't help either. Teachers remembered what was in their materials, not what they had named them, but search only matched titles. And what they could do with an output depended on where it came from: Teacher Tools outputs could be renamed and shared, while Raina chats could only be deleted, one at a time.
The solution
We consolidated every output into a single data table. Each row still shows where it came from, a teacher tool or Raina, so teachers keep that context without needing it to find their work. On top of that, we improved how teachers locate and manage what's there.
Search now matches what's inside each output, not just its title, so teachers can find work by what they remember about it.
Every row can be shared, exported, and renamed, no matter where it was made.
Teachers can select and delete many outputs at once. I designed it as a design system contribution, so data tables across the app use it too.
Outcome
Early feedback has been positive. Teachers no longer need to remember where they made something or what they named it, and they finally have a way to keep their space tidy.
I led the redesign of MagicSchool's homepage, replacing an 80+ tool library with a modular page that adapts to every teacher. It anchored the platform redesign that cut time to first generation from 6 minutes to 3.
Problem
Teacher Tools did one thing well: the moment educators landed, they could tell the product was made for them. But it showed every teacher all 80+ options at once, which felt overwhelming and left educators unsure where to start. And because everyone saw the same tools in the same order, nothing reflected what mattered to their role. It felt impersonal.
Meanwhile, more teachers were using Raina, our AI chat assistant, and writing their own prompts instead of filling out forms.
The bet
Chat had become as trusted as our curated tools, and a natural way into the rest of the product, so it gets the top of the page.
Use what teachers had already told us they cared about to shape what they see.
Easy re-entry would give teachers a reason to come back.
Defining the page
The bets set the direction. The harder part was deciding exactly what belonged on the page, and for whom.
We ran a card sorting exercise with 8 educators to see which homepage elements mattered most. All 8 sorted Recent activity first, and student tools drew the fewest votes. Those results heavily shaped our explorations, from which modules earned space on the page to how much prominence each one got.
We mapped every action in the product that signaled what was meaningful to a teacher: favoriting a tool, creating a Collection, building a custom tool, and, for admins, sharing custom tools with their educators.
Paired with the card sort, that map let us revisit an earlier decision. Collections had only held favorites and teacher-made groups. Folding in custom tools made them visible on the homepage without adding another module. We considered adding admin-provided enterprise tools too, but kept Collections as the teacher's own space, not something pushed on them by their admin.
New and returning users across Free, Plus, and Enterprise. The page also needed room for future rostering and notifications without another redesign.
That range is what led us to a flexible grid: one page that could serve every audience, and absorb new modules without a redesign each time.
The system
I worked through the layout closely with my engineering partner, knowing the modules would keep changing by user type.
Modules flexed between 25%, 50%, and 100% of the page width and stacked by priority.
Raina sits at the top for everyone. Below it, a wide main column (80%) holds the modules that change by user type, and a narrow side column always shows Recent activity, linking teachers back to their latest work. Recommended for you stays a personalized subset, with a link to All Tools for everything else.
Outcome
New users get a recommended starting point. Returning users jump back into recent work. Admins get a direct channel to their teachers.
With Raina at the top of the homepage, she became the retention engine.
"I already had Raina bookmarked so I could go straight to that page. Landing on Raina on the actual homepage is so much better."Middle school teacher, after launch
