An institution’s worth of surfaces, and the standards behind them.

All 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. Every surface I designed exists to carry that certainty outward: to the client, the retailer, the student.

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 and PM oversight across three public gia.edu properties. Where marketing engaged third-party vendors for visual design, I directed the UX, turned vendor designs into build-ready handoffs, and ran the developers. Across that 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 most useful thing I can say about how I work: I optimize for the standard the domain actually holds.

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 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 is most of the work.

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, until a permanent PM was hired. That meant owning sprint ceremonies, the Jira board, backlog grooming, and coordination across design, engineering, and QA.

Taking on the second role was neither a promotion nor 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. That lesson now sits upstream, in how I document and annotate, rather than downstream in implementation review.

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 is not “is this pleasant” but “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. 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 what 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.