Two and a half years at the Gemological Institute of America — the standard-setter behind the 4Cs — as its sole UX/UI Specialist, and concurrently interim project manager for most of that tenure. My surfaces were the ones the world touches: the GIA App, the Inscription Matching service, the printed reports and certification materials, and the client-, manufacturer-, and student-facing web.
Under NDA Facetware, the deepest engagement, stays off this page by agreement. The Inscription Matching work is told with the specifics the NDA permits; numbers live on a call.
Numbers Available on a callAll of this is publicly sourced — none of it is proprietary. It is the institutional gravity that makes designing for GIA a different problem than designing for a consumer app, and it is the lens I want a hiring manager to apply to everything below.
Scale. GIA grades millions of diamonds every year and issues millions of reports to match, across nine global laboratories in thirteen countries. My work sat on the surfaces wrapped around that scale — the app in a client’s hand, the report in their file, the verification a retailer runs before money moves. At that volume, a small improvement to any of those surfaces compounds daily.
Standard-setting. GIA created the 4Cs and the International Diamond Grading System in 1953. Those standards are now the universal language of the diamond trade — used by retailers, auction houses, insurers, and appraisers in over 100 countries. The institution has been setting the standard since 1931. Designing its tools means designing inside a vocabulary the whole industry already shares and will not let you redefine.
Consequence. A GIA report is the difference between “a diamond” and “a documented asset.” The grades those internal tools help produce go on to appear in insurance claims, estate documents, and auction records. The grade on that report is a credentialed gemologist’s professional reputation, staked — and every surface I designed exists to carry that certainty outward: to the client, the retailer, the student.
Designing for professional reputation is a different problem than designing for delight — and the difference shows up in what counts as “good.”
The Lab’s internal systems were not mine — and that boundary is the map. My territory was everything wrapped around the lab: before it, the client- and manufacturer-facing dashboards and submissions; after it, the printed report and certification materials and the verification a retailer runs; beside it, the GIA App, the student-facing experiences, and UX consulting across three public .gia.edu properties — where I didn’t push pixels; I directed the UX and ran the developers as PM. One designer, an institution’s surface area: the job was knowing which surfaces needed ownership and which needed advocacy.
That reframes what “good design” means here. In a consumer product, a moment of friction costs a little engagement. On these surfaces, a moment of ambiguity is a mis-read certificate, a failed verification at a retail counter, a client who mistrusts the document in their hand. The job is not to make the tool feel pleasant. The job is to make the tool feel certain — so the person using it, at speed, never has to stop and ask the interface what it means.
Designing toward certainty rather than delight is the through line of the entire engagement. It changes what gets prototyped, what gets tested, and what counts as a finished component. It is also the single most useful thing I can tell a hiring manager about how I work: I optimize for the standard the domain actually holds, not the standard a design portfolio rewards.
The engagement’s real difficulty is that the surfaces are not one problem at different scales — the App, the Inscription Matching service, Facetware, the printed reports, and the client-, manufacturer-, and student-facing web are genuinely different problems that happen to share an institution. On some I held end-to-end ownership, research through to shipped UI. On others I was the UX advocate between GIA stakeholders and third-party teams — the person whose job was to keep the user present in decisions that would otherwise have been settled without them. Knowing which mode a surface needs, and not defaulting to the one that flatters a portfolio, is most of the work.
01One vocabulary. Every surface speaks the institution’s own terms — the 4Cs — and a word that drifts becomes a defect downstream.
02The dashed line is the whole job: every surface I designed points at, verifies, or explains the certificate a client holds.
Reconstructed from memory at wireframe fidelity. Layout, labels, and values altered; the decisions plotted here are the real ones.
The mobile experiences — full design ownership. The App serves two journeys at once: a first-time jewelry buyer, and a trade professional in the field. The Inscription Matching service is the deepest public-tellable work: with my team I redesigned its UI and UX, added features and functionality, and the result was a massive reduction in both errors and processing times for Match iD owners — usually retailers verifying a stone before money moves on it.
Reports, certifications, and the print family — where typography and hierarchy carry legal weight. Updates to the printed lab report and certification materials, and the supporting print around them: the documents the institution’s whole promise is delivered on.
The web and education layer — client-, manufacturer-, and student-facing experiences, plus UX consulting and PM oversight across three public .gia.edu properties, and UX assists on GIA.edu pages inside a style guide I didn’t control. Here the mode was advocacy: holding the user’s case inside multi-party decisions. Facetware, the most thorough end-to-end engagement of the tenure, sits under full restriction — methods discussable, the work itself a conversation.
My primary role at GIA was UX/UI design: research, information architecture, interaction design, high-fidelity UI, and QA through to production. For most of the tenure I carried that concurrently with the responsibilities of interim Project Manager — owning sprint ceremonies, the Jira board, backlog grooming, and coordination across design, engineering, and QA, until a permanent PM was hired.
Taking on the second role wasn’t a promotion and it wasn’t ancillary to the design work. It was the team recognizing that cross-functional coordination was on the critical path — and that I already understood how design decisions moved through the full product-development cycle. The trust it reflected was earned before it was formalized.
What changed for me as a designer: I stopped thinking of the handoff as the end of my work and started treating it as a design surface in its own right. Running the board taught me exactly what an under-specified ticket becomes by the time it reaches production — and that lesson now sits upstream, in how I document and annotate, rather than downstream in implementation review.
In a domain where error has consequences, an ambiguous state is not a creative choice — it is a defect.
Selected design calls from the engagement — the Inscription Matching redesign chief among them. Each had a credible alternative; each is recorded with the alternative it beat and the reason. The project-specific decision maps are a conversation: nothing gets reconstructed here without the real artifacts behind it.
WCAG 2.1 AA was treated as a design requirement from the first artifact — contrast, semantic hierarchy, and focus management built into every component as it was drawn. The rejected alternative, a compliance pass at the end, reliably produces a retrofit that satisfies an audit and still fails a real user. Built in from the start, it costs nothing extra and changes the result.
In a domain where error has consequences, an ambiguous state is not a creative choice — it is a bug. Every label, every state, every interaction is designed to confirm that the system understands exactly what the person using it is doing and requires no interpretation from them. “Is this visually interesting” gave way to “does this remove any possible ambiguity.” When the two answers diverge, the second one wins.
Running sprints while designing made the cost of a vague handoff impossible to ignore: vague annotations become engineering judgment calls, missing edge cases become bugs, a component without a loading state gets one invented by someone who didn’t design it. So annotation layers and edge-case documentation are now part of the design process — not a cleanup step. The handoff should leave no decision the designer would have made differently than the engineer.
Every interactive component, eight states drawn: default · hover · focus · active · disabled · loading · error · empty.
Precision over delight. I came into this role with the intuition that good design should feel effortless. That is still true — but I had to recalibrate what “effortless” means for a user whose attention is professionally deployed. For someone verifying a stone at a retail counter, or reading the certificate that documents an asset, effortless means frictionless precision: every label, every state confirming the system understands exactly what they are doing. The standard isn’t “is this pleasant.” It is “does this require nothing of the user’s interpretation.”
Specificity in the handoff. The quality of a handoff determines how much of the design actually reaches production intact. That is not a process nicety — in a domain where the shipped tool carries consequence, an invented loading state or a misread annotation is a defect in the final product. Specificity upstream is the cheapest quality control available.
Shared vocabulary with engineering. Domain-specific terminology means different things to different teams; a misaligned definition inside a ticket creates ambiguity that surfaces in production. If I were starting the engagement again, I would invest earlier in a shared glossary, built into sprint planning — it would have saved real time I instead spent in implementation review.
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 “this should change” from “this should change now” — and to invest in the second without losing sight of the first.
The designs I am most proud of from this role are not the most visually interesting ones. They are the ones where I understood a user’s workflow well enough to make a structural decision that simplified it — and where the 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.
That is the discipline I would hand to anyone starting a long engagement inside an institution: read the workflow before you redraw the screen, earn the structural changes, and let the best work go unnoticed. The full story — the surfaces, the specific decisions, the things an NDA keeps off this page — lives in the room. I am glad to walk through it there.
Two and a half years designing for an institution whose entire product is certainty taught me to treat ambiguity as a defect, not a style choice — at the counter, on the certificate, in the app — a standard I now hold whether or not the stakes are visible.
