Client

Personal project

Role

Product Designer

Industry

BeautyTech

Mobile Web

Product Design

UX Research

Barcode Scanner

User Testing

Cruelty-Free Beauty Scanner

A mobile-first web app that lets anyone scan a cosmetic barcode and instantly see if the brand is cruelty-free without opening Google, cross-referencing multiple sites, or knowing where to look. Built from scratch: from identifying the problem through YouTube research, to shipping a live product with a working barcode scanner.

<3 sec

scan to answer

3

corridor tests conducted

150+

brands in database

Context

I love perfume. One day I found out that some fragrances are tested on animals — and that led me down a rabbit hole. I discovered the concept of cruelty-free beauty, started researching which brands test and which don't, and eventually started a YouTube channel sharing my findings. What became clear quickly: this topic is significantly more developed in the US than in Europe. The tools that exist PETA's database, Leaping Bunny, Cruelty-Free Kitty are great resources, but they're built for desktop research, not for the moment you're standing in a store with a product in hand. That gap became the idea.

Visit Vebsite

The problem

Getting a cruelty-free answer takes too long in the wrong moment. The peak moment of need is in a store, product in hand. The existing tools require navigating to a website, searching manually, and often cross-referencing multiple sources, because European brands are frequently missing from US-centric databases. I wanted to reduce that to a single scan.

Goals

What I wanted to achieve How I'd know it worked Make CF status accessible in the moment of purchase Works one-handed, result in under 10 seconds Cover European brands better than existing tools Own database built over several years of research Ship something testable, not just a prototype Live URL, real barcode scanner, shareable Validate the core mechanic before investing further Corridor testing with 3 real users

Process

Step 1 — First prototype: generated with AI

I had a clear idea but didn't have a detailed implementation plan. My first move was to describe the concept to Claude, the brand identity, the core flow, the visual palette I'd developed for a university project, and generate an initial version.
Looking at this version, I could see the structure was right. But visually it wasn't at the level I wanted. The UI needed significant work before I could show it to anyone.

Step 2 — UI refinement

I took the first version and focused purely on visual quality: typography hierarchy, spacing, component consistency, the way the brand identity translated to a mobile interface.

I used the color palette from my own diploma project an ethical beauty retail concept, which gave the app a grounded, intentional visual language rather than starting from scratch.

Step 3 — First real test: the database problem

I launched the refined version on Bolt to start testing it myself. The first major blocker: I couldn't get the database to connect reliably. The API kept failing due to CORS restrictions on the hosting environment.

Decision: Rather than blocking progress on a technical problem, I pivoted to a version with templated demo results. This was enough to demonstrate the core mechanic - scan a barcode, see a CF status without requiring live data.

This was a deliberate product decision: what's the minimum version that lets me test whether the core idea works?

Step 4 — Corridor testing with 3 users

I shared the demo version with 3 potential users and observed how they interacted with it. Key findings:

1. The home screen was adding friction, not value. Users wanted to scan immediately. The home tab with stats, recent history, a CTA card was a detour to the thing they actually came to do.

2. Saved/Favourites didn't make sense without login. Without authentication, the saved list resets on every session. Users noticed this felt broken. The feature needs proper infrastructure before it's useful.

3. The core mechanic worked. All three users understood what the app did within seconds and could complete a scan without guidance.

Step 5 — Structural redesign based on testing

I made two significant structural changes:

Removed the Home screen entirely. The scanner is now the first screen. The only second tab is About contextual information about what cruelty-free means and how to interpret results.

Removed Saved/Favourites. A broken feature is worse than no feature. This goes back when there's proper login infrastructure behind it.

The navigation went from 3 tabs to 2. Every interaction now starts at the scanner.

Step 6 — Bottom sheet instead of full-screen result

The result originally opened as a full-screen page, which meant navigating away from the scanner to read it, then navigating back to scan again.

I replaced this with a bottom sheet: the result appears over the active camera view. The scanner stays visible. One tap expands to full detail. One tap dismisses and continues scanning.

This was the single biggest improvement to the flow. What had been:

Scan → Navigate to result → Navigate back → Scan again

Became:

Scan → Sheet appears → Dismiss or read more

Step 7 — Migration to Vercel, final build

After the structural redesign, the barcode reader kept breaking on Bolt. I migrated to Vercel, rebuilt the final version there, and that's what's live now.

Key design decisions

Demo results over no results When the live database couldn't be connected, I didn't cancel the test — I used templated results to keep testing the mechanic. This let me run corridor tests and gather real feedback rather than waiting for a technical problem to be solved. Three statuses, not four I considered a "conflicting data" status for cases where sources disagree. I decided against it: a person in a store doesn't know what to do with ambiguity. "Not in database" is more honest and more actionable than "we're not sure." Preview mode label The current version shows demo data. I made this explicit with a persistent label throughout the result flow — because the brand is built on transparency, and hiding it would undermine that from the first use. Desktop shows a QR redirect Rather than a broken responsive layout, desktop opens a clean page with a QR code linking to the mobile version. Small detail, clear intent.

Current state vs. what's next

Now live: Working barcode scanner (html5-qrcode, tested on iPhone Safari) 150+ brands in local CF database, built from several years of personal research Demo results demonstrating the full flow Scan counter (localStorage, persists between sessions) Next steps I'm planning: 1. Connect the real database. I've been building a personal CF database for years this is the core asset that would differentiate Kraiva from existing tools, especially for European brands. The technical work is CORS and API architecture. 2. Real scan counter. The current counter is local. A server-side counter would make it a real social proof signal and a way to understand usage patterns. 3. Login + Favourites. Once there's authentication infrastructure, the Saved tab comes back. Users wanted it it just needs to actually work. 4. Ingredient analysis. Flag animal-derived components (carmine, lanolin, beeswax) even within CF-certified brands. This is the feature that creates real differentiation a brand can be CF-certified and still use animal ingredients.

What I learned

The database problem taught me something important about MVP thinking. My instinct was to solve the technical blocker before testing. But the question I actually needed to answer was: does the core mechanic make sense to real users? Demo data was enough to test that. Separating "what we're testing" from "what we're building" let me move faster and get better feedback. Two major rebuilds made the product significantly better. The first was visual lifting the UI quality before user testing. The second was structural removing everything that didn't serve the primary job after user testing. Both felt like setbacks at the time. Both were the right call. Shipping changes how you think. Getting this to a live URL and testing it in a real store with real products surfaced decisions that Figma prototyping never would have. The barcode scanner behavior, the bottom sheet timing, the way the preview label reads in context none of that is visible until it's in someone's hand.