Geek & Gorgeous makes effective actives — acids, Vitamin C, retinoids — sold at accessible prices. Their shoppers ask real questions at the point of decision that a product page can't answer. The brief was to design a conversational advisor for their site. The first design problem wasn't how to recommend. It was how to stay within the brand's evidence and avoid giving advice the brand couldn't stand behind.
Geek & Gorgeous products work. Their core range — acids, Vitamin C, retinoids — is well-formulated and well-priced. But active skincare is a category where layering the wrong things, introducing something too strong too early, or ignoring a sensitivity signal can damage someone's skin barrier. The PDP explains what a product does. It doesn't know what the shopper is already using or whether their skin can handle it.
The brief was to design a chat-based advisor for the brand's site. The product question that followed immediately: what does the system do when it doesn't have enough context to give a safe recommendation? A generic RAG chatbot answers anyway. That was the wrong starting point.
I designed a three-layer architecture. Memory informs: the system tracks what the user has shared. Rules decide: an eligibility engine determines what can be recommended, what should be excluded, and whether the system has enough information to recommend at all. The LLM explains: it receives a structured response plan and writes the answer in G&G's voice. It doesn't choose products.
Skin type, concerns, current routine, sensitivity flags, prior conversation. Shapes what the rules engine considers. Never selects products.
Eligibility, exclusions, safety fallbacks, ranking, routine sequencing. Whether the system recommends, defers, or asks a clarifying question first.
Receives the response plan. Writes the answer in brand voice. Constrained to what the rules layer has already decided.
Free-text input. No structure imposed on how the shopper expresses their question.
Categorised: product recommendation / compatibility / routine building / education / unsafe-fallback. Routes the pipeline from here.
Structured output: skin type, concerns, sensitivity, current routine, budget. Also: what is still unknown and needed before a recommendation is safe to make.
Retrieves relevant product claims, ingredient guidance, and usage rules from the brand-approved knowledge base. No general-knowledge generation.
Rules engine runs against every candidate product. Products that conflict with known signals, carry disallowed claims, or require missing context are removed before ranking.
Eligible products ranked by signal match. Routine order applied — what to introduce now, what to hold back, what can't be layered together.
A structured JSON object: what to recommend, what to caution against, usage order, clarifying question to ask. The complete decision. Step 8 only explains it.
Receives the response plan. Writes the answer in G&G's voice. Product cards rendered alongside with rationale and usage guidance.
A prompt instruction saying ''avoid medical language'' is soft guidance. An LLM can reason around it under an unusual input. A structural block in the product metadata and eligibility engine is enforced regardless of what the LLM receives. That distinction matters — especially in a health-adjacent category.
If a claim creates medical, regulatory, or brand-trust risk, it lives in the rules layer. If it's about tone or wording, it lives in the prompt. The categories were defined with the G&G brand team and encoded in the product metadata schema as disallowed_claims and caution_flags fields.
The handoff included the full architecture spec, product metadata schema, rules engine logic, and an eval framework covering recommendation quality and safety behavior. The brand team can extend it without needing to reverse-engineer the design intent.
The system's value isn't that it can always answer. It's that it knows the difference between a recommendation it can stand behind and one it can't.