Prepared for the team at Gemist
Kabana.com — product data and item page package
Everything needed to model Kabana products correctly on the new site: how our style numbers work, which collections we are launching with, which pieces and stone variants belong on the site, and how a product page should behave.
Style number system
How every Kabana item number is built, with the full metal, item, setting and stone code tables. This is the rule set the product data model must follow.
02Collections for launch
The twelve collections going on kabana.com, including the Eden and Sea Life subcollections that need their own navigation.
03Item page layout
Annotated wireframe and the behaviour rules for the product page — gallery, stone picker, chain option, spec table.
04 — Product spreadsheet
One row per item number, grouped under its base style, with the stone variants for each style and the exact image filename expected for every option. The "Image status" column marks which photos exist today and which Gemist needs to generate.
05 — Work inside our catalog builder
The spreadsheet is a snapshot. Kabana's catalog system holds every style, price and photo live, and it is where the variant images your team produces are attached, checked and approved. We'll give you a workspace in it for this build. Gathering images from our many systems is the problem this catalog was built to solve, and we are open to changing our catalog or systems wherever that makes the work with Gemist easier.
Access is through named accounts scoped to the website workspace. Kabana's designs are protected by copyright, and the catalog system, the style data and the photography — including the variant images made for this project — remain Kabana's. The engagement agreement will set out ownership, copyright, confidentiality and a non-compete term before work begins.
06 — Moving thousands of files
Your team connects its own Dropbox, OneDrive or Google Drive folder and the catalog pulls the renders straight across — no browser uploads. Every batch then stops at a review screen that reports missing item numbers, invalid stone variants, duplicates and failed transfers before anything is saved.
See the review screen07 — Changes on our side
If our catalog or our systems need to change for this build, say so and we'll change them. Every request is written down with one named owner, the decision that was taken and the date it was taken, so nothing is agreed in a thread and then lost.
Open the change request list08 — Which variants each piece needs
Not every stone is cut for every collection. We set the metals and stones a collection is made in while editing it in the catalog builder, with exceptions on individual styles, and the variants each piece needs — along with the photographs still missing — come straight out of that. It is the photo brief, by the numbers.
See variants by collection09 — Slack requests, organised
Requests arrive in Slack, half-finished and mid-thread. Paste one in and it comes back as a list: the ask, the pieces and codes it touches, who should own it, and the questions that need answering before anyone starts. Nothing is saved or sent — read it, fix it, then raise the ones worth tracking as change requests.
Organise a Slack request