ROLE:
UX/UI Design | Visual Design & Branding | Interaction Design & Prototyping
CLIENT:
KushLog
FORMAT:
Mobile Application
about.
I work at Sweet Flower, a cannabis retailer, and I kept watching the same thing happen at the counter: someone walks in wanting to buy again — a strain they loved, an edible that actually worked for their sleep, whatever — and they just... can't remember what it was. Maybe they remember the color of the package. Maybe they remember it was "the purple one." Almost never the actual product name.
That's not a discovery problem. Budtenders are good at discovery — walk in and ask, and you'll get a recommendation in 30 seconds. It's a memory problem. Cannabis products don't have the packaging permanence or brand loyalty structures other categories rely on (a bottle of your go-to shampoo just sits in your shower). Strains rotate, brands rebrand, batches vary, and there's no single source of truth a customer carries with them between visits.
So the real gap isn't "help people find weed" — it's "help people remember what already worked."
problem statement.
That reframe — memory, not discovery — became the lens for everything that followed. Here's how I distilled it into a problem I could design around:
How might we make it effortless for customers to recall products they loved, without turning tracking into a chore?
research.
This project didn't start with a research plan. It started with me showing up to work, day after day, and watching the same struggle play out at the counter. No surveys, no formal study, just months of real conversations with real customers trying to find something they already loved. That repetition is what pushed me to actually build something: I wasn't guessing at a problem, I was living next to it.
To ground the case study, I paid closer attention to a pattern I'd already noticed and started informally tracking it — quick conversations with customers at checkout, noting what they said when trying to find something they'd bought before.
The pattern: Customers were fluent in sensation and context — how it made them feel, when they got it, what it looked like — but almost never fluent in the actual product identifier: name, brand, batch. That gap was consistent enough across dozens of interactions that it stopped looking like a one-off complaint and started looking like a real, addressable design problem.
What this ruled out: This wasn't a discovery problem (budtenders solve that in seconds) and it wasn't a loyalty problem (many of these were repeat, satisfied customers). It was specifically a recall problem, which is what pointed the design thesis toward "recall over logging" rather than, say, a recommendation engine or a loyalty rewards feature.
process.
From observation to concept
Once I'd named the real problem (memory, not discovery), I started with Figma Make, using it to rapidly brainstorm layout directions and narrow down what the core loop should even look like: what screens does someone actually need to log a purchase and find it again later?
I wasn't trying to get anything right the first time. I was trying to see a handful of directions fast enough to know which one to commit to.
Building a design system
Before I went too far into individual screens, I worked with Claude to define an actual design system: type scale, color tokens, spacing, component specs, so every screen was pulling from the same source instead of me eyeballing consistency screen by screen.
Things like the star rating spec or the color tokens for Forest Green, Gold, and Smoke Gray got defined once, up front, rather than reinvented per screen. That gave me a shared vocabulary to hand to Figma Make in every prompt, which made the output far more predictable.
Narrowing and refining
Once a direction felt right, I shifted towards refinement. This is where prompting discipline mattered most. Early on I learned the hard way that vague prompts get you vague, sweeping changes: ask for one small tweak and the whole layout shifts.
So instead of writing prompts straight into Figma Make, I worked with Claude first to sharpen them, making sure each one named exactly what should change and explicitly stated what shouldn't. That scoping discipline is what let me iterate one component at a time without constantly re-fixing collateral damage from the last prompt.
I worked through the app screen by screen this way, reviewing every prompt before running it, checking the output against the thesis and only moving to the next screen once the current one held up.
Illustration system
The last layer was adding visual identity and delight to the onboarding illustrations. Rather than use existing illustrations, I generated a cohesive icon set using Flux 2 Pro through Figma Weave, batching assets with the Prompt Concatenator tool rather than generating them one at a time. That's what actually kept the lighting, material, and color treatment consistent across the whole set.
screen by screen walkthrough.
