Designing for AI Consumption at Icertis
The Impact
I made high quality, dynamic dashboards that translated complex AI consumption data into relevant and actionable insights for end-users, admins, and internal teams.
Project Type
Summer Internship
Year
June - August, 2025
Scope
Enterprise AI, B2B SaaS Products
Chapter 1
Understanding the complexity of AI consumption
AI consumption is not like tracking seat licenses or page views. Every interaction is variable. Tokens consumed, features invoked, API calls made. And the cost is not always known until after the fact. On top of that, AI usage is new to end-users and companies alike. My challenge was to acknowledge this unfamiliarity, understand the complexity, and design for usability.
Chapter 2
Understanding the three user bases
end-users
wanted to know if they were approaching their limit.
admins
wanted to spot unusual activity across their customer base.
internal teams
wanted to understand whether pricing margins were holding.
The same data had to serve three very different audiences. Designing one dashboard to serve all three would have failed all of them. So I designed three separate information architectures that shared a design language but answered completely different questions.
Chapter 3
Bridging the gap between Research and Design
At Icertis, the path went from stakeholder interviews through synthesis artifacts, including journey maps, service blueprints, and a prioritized usability gap log, into three validated prototypes. One per user type. Each was tested and iterated before engineering touched it. The 35% drop in task friction and the jump from 40% to 80% task success were not targets set at the start. They came from letting research drive the design rather than just enhance the aesthetics.
The specifics stay under NDA. But the method is shareable:
Understand the product, synthesize findings, prototype fast, iterate often,
deliver quality.
My learnings
Data alone does not tell a story
The same number meant different things. I learned that showing data and designing for understanding are two very different things.
Constraints are part of the brief
Working with engineering timelines and enterprise system boundaries forced me to make sharper decisions. I treated constraints as inputs.
Asking for what you need
Nobody handed me access. I had to figure out what I needed and then ask for it, often from people I had never spoken to before.
Reimagining Formal Introductions
Kroger's Exchange Workflow
<——— previous
next ———>
Copyright 2026