A knowledge atlas for a gemstone expert

The problem

A gemstone specialist who offers appraisals, consultations and bespoke jewelry had years of articles, research, talks and gem records spread across an older WordPress site. The knowledge was there, but a visitor had to dig for it, and nothing on the page showed the craft of looking closely at a stone. The goal was a site that keeps the expert at the center, makes the whole archive easy to explore, and guides a visitor toward a private enquiry, without losing a single page of the original.

Constraints

• Nothing from the old site could be lost: every post, page, product record, image and linked document had to come across.
• Heavy 3D and video had to load fast on phones.
• Background footage was cleared for mockup use only, so the design couldn't depend on it.
• The enquiry form could not send anything until the owner approves where messages go.

What I did

Strategy and brand

I structured the site as five chapters: the stone opens, a portal gallery, the expert's story, a knowledge atlas, and services, ending on one call to action, a private enquiry. Enquiry topics match the real services: gemstone and jewelry appraisal, consultation, bespoke jewelry, and research or media.

Design

The visual language comes from gem work itself. A cursor loupe with a magnification readout reveals artwork, service cards come into focus like instruments, and an orbital gallery and a 3D helix carry honors and moments. On phones the hero gem moves into the page flow so it never covers the portrait or text.

Engineering

• Migration. Python scripts read the old site's WordPress REST API and captured 16 posts, 20 pages, five product records, seven documents and 407 links into one JSON archive, plus a 553-file media manifest. The original media is backed up with Git LFS.
• Library. A searchable knowledge atlas lists every record, and each one gets its own page.
• 3D. The hero gems are built in code with three.js: a brilliant-cut emerald from 160 faces and a cushion sapphire that shatters into solid shards. Node tests check that the meshes are closed and facets face outward (11 tests, all passing). A rough diamond on kimberlite is modeled and path-traced entirely from a Blender Python script into a 120-angle turntable you can drag, flick or turn with the arrow keys.
• Speed. WebGL scenes wait until they are near the screen, images are resized to WebP, and the hero starts after first paint. On a production build this cut first-load weight on phones from 18.1 MB to 2.5 MB and full load from 6.6 to 1.8 seconds, and on desktop from 18.4 MB to 5.2 MB.
• If WebGL fails, a static SVG drawn from the same geometry takes its place.

Outcome

• A working prototype of the full site, with the complete archive migrated and searchable.
• The speed figures above come from my own production-build test recorded in the project history. Real-visitor performance has not been measured.
• It is not live. The enquiry flow is a demonstration that sends nothing, and final footage still needs clearing.

What I'd change next time

I'd set the performance budget on day one. The first versions loaded 18 MB on phones, and fixing that afterwards meant reworking images and scene loading. I'd also agree on media rights before designing around a piece of footage, so the hero never depends on a clip that has to be replaced.