Gemological Institute of America
Designing for people
who stake their
professional reputation
on getting it right.
Nearly 2.5 years embedded as in-house UX/UI & Product Designer at the global authority in gem grading — designing tools that professionals, institutions, and the global trade depend on.
Why this work matters
GIA is the institution that decides what a diamond is worth. The tools I design are how that happens.
GIA (the Gemological Institute of America) created the 4Cs of diamond grading — the global standard that underpins trillions of dollars of commerce annually. When a jeweler shows a customer a GIA certificate, they’re presenting GIA’s assessment as objective truth. The systems I design are how GIA’s graders, researchers, and specialists do their work.
That context shapes how I approach every design decision here. The users of these tools aren’t casual consumers making reversible choices. They’re professionals making assessments that appear on certificates that follow a gem for its entire existence. Ambiguity in a UI isn’t just a usability problem — it’s a precision problem. And in this domain, precision is institutional identity.
One clarification for context: my work is entirely within GIA’s product ecosystem — internal systems, client-facing tools, mobile, B2B SaaS, and subsidiary experiences. I did not contribute to the GIA.edu public website.
This work is under NDA. That constraint is the reason this page exists without images — not a reason to tell you less. What I can share is the design thinking, the specific problems I encountered, and what I learned navigating them. That’s what I’d walk you through in a conversation. Reach out and let’s have it.
A GIA gemologist uses these systems for hours every day, under cognitive load, making assessments that require precise language and unambiguous classification. Their interface can’t be clever. It can’t be ambiguous. It can’t have affordances that require interpretation. Every design decision starts with: does this make their judgment clearer, or does it add noise to it?
Scope of Work
Six product surfaces. Each with a genuinely different user, context, and design challenge.
Some of these were end-to-end design engagements where I had full creative ownership from research to shipped product. Others were collaborative — where I served as a UX advocate between GIA stakeholders and third-party teams, ensuring the user’s perspective was present in decisions that would otherwise be made without it.
Internal Enterprise Platforms
Systems used by GIA staff across global campuses and grading laboratories. Full creative ownership. The precision requirement was highest here — graders and researchers don’t have tolerance for ambiguous UI.
GIA Mobile App
Design contributions to GIA’s mobile application serving both consumer and professional user journeys. Unique challenge: the same app used by someone buying their first piece of jewelry and someone grading their thousandth stone.
B2B SaaS & Client-Facing
Account management tools and client-facing experiences for trade professionals and institutional clients. Designing for expert users who know exactly what they’re doing and have zero patience for UI that gets in the way of it.
Subdomains & Subsidiaries
Select GIA subsidiary digital experiences maintained within the GIA design ecosystem. Consistency across brand touchpoints matters especially when the brand is built on the idea of a single, authoritative standard.
Print Products
GIA certificates, reports, and collateral materials. Print is where the institution’s visual authority is most concentrated — these documents appear in appraisals, insurance claims, and estate documents for decades after they’re issued.
UX Advocacy: 4Cs, NextGem, TrainingStudio
For these experiences, I served as the UX representative in conversations between GIA stakeholders and third-party vendors or GIA’s creative and marketing teams. Not primary design ownership — but ensuring the user was present in decisions that would otherwise be made without them.
My Role — And the Second One
Designing products. Running sprints. Learning how they’re connected.
My primary role at GIA is UX/UI design: research, IA, interaction design, high-fidelity UI, and QA through to production. For a significant period, I carried that alongside the responsibilities of interim Project Manager — owning sprint ceremonies, the Jira board, backlog grooming, and coordination across design, engineering, and QA while a permanent PM hire was onboarded.
I didn’t volunteer for the PM role. I was asked because the team trusted that I understood the full product development cycle — not just the design part of it. That’s the context I want to give it. It wasn’t a promotion. It was a demonstration of where I’d already earned trust.
What changed for me as a designer: I stopped thinking of the handoff as the end of design work. When you’re running the sprint, you watch what happens to your decisions between Figma and production. You see which annotations got read and which didn’t. You understand which design choices created three engineering tickets and which were implemented in an afternoon. That visibility made me a more precise specifier and a more practical collaborator.
- Stakeholder interviews, contextual inquiry, usability testing
- Information architecture and interaction design
- High-fidelity UI across all six product surfaces
- WCAG accessibility compliance
- Developer handoff and production QA cycles
Sprint ceremonies
Planning, review, retrospective — owned and facilitated across design, eng, and QA
Jira ownership
Board maintenance, ticket authorship, definition of done per team
Backlog grooming
Prioritization in close collaboration with product and engineering leads
Design fidelity
Owned the gap between design intent and production outcome
Design Principles — Earned, Not Asserted
What 2.5 years in a high-precision domain teaches you about design.
In domains where error has consequences, ambiguity is a design defect
I came into this role with the intuition that good design should feel effortless. That’s still true. But I had to recalibrate what “effortless” means for a user whose attention is professionally deployed. For a GIA grader, effortless means frictionless precision — every label, every state, every interaction confirming that the system understands exactly what they’re doing and requires no interpretation from them.
I stopped asking “is this visually interesting?” and started asking “does this remove any possible ambiguity?” Those questions sometimes produce the same answer. When they don’t, the second one wins.
The handoff is a design deliverable, not an afterthought
Running sprints while designing taught me that the quality of a handoff determines how much of your design actually makes it to production. Vague annotations become engineering judgment calls. Missing edge cases become bugs. A component without a loading state gets a loading state invented by someone who didn’t design the component.
I now build annotation layers and edge case documentation as part of the design process — not as a cleanup step at the end. The handoff should leave no questions the designer would have answered differently than engineering.
Even expert users need to be observed, not assumed
Early in this engagement, I made assumptions about how professional gem graders would use a new tool based on domain knowledge I’d accumulated through research. Several of those assumptions were wrong. Experts have deeply ingrained workflows and well-founded skepticism of change — which means their adoption patterns are harder to predict than general consumers’, not easier.
Usability testing with expert users requires a different approach: less “can you complete this task?” and more “where does this interrupt your flow?” That shift in testing framing produced consistently more actionable findings for this context.
Reflection
What I’d tell a designer starting a long-term in-house role.
The most underrated skill in an embedded role is institutional patience. Early in this engagement, I had more ideas than the organization was ready to implement. I learned to distinguish between “this should change” and “this should change now” — and to invest in the latter without losing sight of the former.
The designs I’m most proud of from this role aren’t the most visually interesting ones. They’re the ones where I understood a user’s workflow well enough to make a structural decision that simplified it — and where that simplification was clear enough that every stakeholder could see it immediately without me having to explain it.
Good design in a high-precision context is invisible. The win is that users think the tool is smart, not that the designer was clever.
I’d invest earlier in building shared vocabulary with engineering. Domain-specific terminology means different things to different teams at GIA — and misaligned definitions in a ticket create ambiguity that surfaces in production. Establishing a shared glossary in sprint planning would have saved time I spent in implementation review.
Let’s continue this conversation
The full story lives in the room.
I’m happy to walk through the specific problems, design decisions, and outcomes in detail. Reach out and let’s talk.