NABU publishes storybooks in children’s native languages and reaches more than 12 million learners worldwide. I designed part of the internal platform their team uses to manage partners and turn data from MySQL, spreadsheets, and Google Analytics into visualizations.
Admins needed one place to manage partners, organize that data, and turn it into visualizations.
Her work moved between partner requests, role permissions, and visualization setup, often across hundreds of records.
A single workflow for approving partners, controlling access, and building visualizations without rebuilding each partner’s setup by hand.
Where she came fromLeila stands in for the NABU admins the platform was built for. I don’t have interview notes from this project, so she represents the workflows we were given rather than a specific person I spoke to.
My work focused on how admins approve partners, decide what each role can reach, and build the visualizations NABU shares, using the colors, typography, and branding NABU already had.
Before designing the visualization flow, I spent time understanding how NABU’s data was organized and how an admin would need to move through it.
A lot of this product is tables rather than typical consumer UI, so I had to know which fields mattered to an admin before deciding how a row should be laid out.
We had one semester to design and ship, so we focused on the workflows NABU needed most instead of trying to solve everything.
NABU gave us colors, typography, and branding guidelines, so I didn’t build the system from scratch. What we added were the table, form, and button patterns the platform needed, which kept more of our time on the data and workflow problems.
A role determines which visualizations a partner can access, so I kept the role name, description, and assigned visualizations in one form.
Admins narrow the data they need, preview the result, then publish.
This is where the admin picks the country, date range, and data they want the chart to cover.
Before publishing, the admin sees the actual data behind the chart, so they can check the numbers instead of taking the chart’s word for it.
With around 200 roles and long descriptions, the row had to reveal detail without widening the table.
An open dropdown covers the rows beneath it, so only one role can be expanded at a time. Comparing two roles side by side came up less often than checking one, so we kept it.
Centralizing partner requests only helped if admins could act on them without leaving the table.
Partner requests, roles, assigned visualizations, and final outputs form one access chain.
The part of the platform we designed put four jobs in one place: approving partners, managing roles and what each one can reach, organizing the data behind them, and building the visualizations NABU shares.
I don’t have usage data from after handoff, so I can’t say how their week looks now.
I couldn’t organize the interface until I understood how the data itself was organized: what the fields meant and how an admin moved through them.
Working on an internal tool changed what I pay attention to. A search field and bulk actions aren’t much to look at, but they take repetitive work out of something admins do every day.
05Designer
Brilliant Cities
Helping parents keep habit goals going at home, between programs.
01Product Design Intern · Summer 2026
Terraform
Making read-only access clearer without removing the context people still needed.
02Product Manager · Spring 2026
Anda
Deciding which driver-support work to build first, before the real data was ready.
03Designer · Fall 2025
Operation Safe Escape
Making a case easier to pick up, so the history doesn’t have to be rebuilt from email and spreadsheets.
