The Problem

A luxury brand trapped in Instagram DMs

A luxury artisan chocolatier was operating entirely through Instagram DMs and phone calls. No website. No checkout. No trust signals. Manual order processing was creating bottlenecks, losing customers, and making international expansion impossible.

Cultural skepticism compounded the challenge: 30% of potential Kazakh and Russian customers wouldn't purchase without a professional, dedicated e-commerce presence. Cart abandonment on existing informal channels was 78%. The brand had a premium product and zero digital infrastructure to support it.

Design Screens

Real Figma Designs — Full Platform

Every screen below is from the final high-fidelity Figma prototype, tested with 15 users across Kazakhstan, Russia, and English-speaking markets before a single line of production code was written.

almaty-cocoa.kz

Homepage hero · Shopping cart flyout — "Almaty's Finest Artisan Chocolate" with persistent order summary

almaty-cocoa.kz/shop

All Chocolates · Advanced filtering sidebar — category, origin, price range, cocoa %, certifications (Organic, Fair Trade, Bean to Bar)

almaty-cocoa.kz/collections

Chocolate Collections · 9 curated collections, 200+ products, 25+ countries — "Can't Decide" taste quiz CTA

almaty-cocoa.kz · Search

Search feature · Instant modal results with product image, maker, category, and price — "View All Results" CTA

almaty-cocoa.kz/cart

Shopping cart · 2 items, persistent order summary, secure checkout + fast shipping trust badges — quantity controls

almaty-cocoa.kz/checkout/payment

Checkout · Step 3 Payment — 9 payment methods including Kaspi Pay & QIWI for Kazakh/Russian markets, persistent order summary

almaty-cocoa.kz/account

Buyer account · Order history with delivery status, tracking numbers, reorder and track_order actions — 24 orders, $1,247.89 total spent

almaty-cocoa.kz/seller-dashboard

Seller (Artisan) dashboard · Total revenue $15,847.23, 12 active products, 4.9★ store rating — top performing products with revenue breakdown

Process Breakdown

Five phases. Eight weeks. One launch.

Every phase was tightly scoped and evidence-gated — no phase began until the previous one produced a clear decision or artefact. Here's how the project actually ran, step by step.

01 · Research 02 · Design System 03 · Validation 04 · Implementation 05 · Optimization

Phase 01 · 2 Weeks

Understanding three cultures simultaneously

I conducted 24 in-depth user interviews across English, Russian, and Kazakh — not through a research agency but directly, with a live interpreter for the Kazakh sessions. The goal wasn't satisfaction scores — it was surfacing the unspoken mental models that decide whether someone trusts a checkout form enough to enter their card number.

Parallel to the interviews, I ran a competitive audit of 5 e-commerce platforms operating in the CIS region — Wildberries, Kaspi.kz, Ozon, a Kazakh artisan platform, and a European Almaty Cocoa — documenting how each handled trust signals, payment UX, and multilingual copy.

24

Interviews conducted

Across 3 languages, 3 markets. Sessions ranged from 35–55 min, covering trust, payment habits, and luxury purchase psychology.

5

Competitors audited

Wildberries, Kaspi.kz, Ozon, a local Kazakh platform, and a European Almaty Cocoa — documenting trust signals and payment flows.

3

Journey maps created

One per market, documenting cultural drop-off triggers at each checkout step — from product discovery to payment confirmation.

Critical finding: Trust signals are culturally loaded. Kazakh users required visible Kaspi bank logos before feeling confident enough to proceed. Russian users needed Russian-language security messaging — "SSL Secured" in English was read as suspicious, not reassuring. This single insight reshaped the entire checkout architecture.

Phase 02 · 4 Weeks

45+ components. 3 languages. One system.

Before drawing a single screen, I built the design system. This wasn't decoration — it was the infrastructure decision that made a 10-week timeline possible for a 3-language, 3-market product. Every component was designed with multilingual constraints baked in: 30% text expansion buffers for Cyrillic, RTL-ready spacing tokens, and locale-aware number/currency formatting.

The component library shipped to Storybook in sync with Figma design tokens, meaning every style update in Figma propagated automatically to the engineering codebase. This eliminated the most common cause of design drift in fast-moving projects.

1

Token architecture — color, type, spacing, motion

Defined semantic tokens rather than raw values: color.action.primary not #0F6E56. This meant swapping the entire palette for a market variant required changing one token file, not hunting through 200 components.

Figma Variables + CSS Custom Properties

2

Primitive components — buttons, inputs, badges, icons

Built 28 atomic components with Figma Auto Layout and component properties — enabling designers to configure state, size, and locale from the properties panel without creating new frames.

Figma Components · Auto Layout

3

Composed patterns — product cards, checkout, trust badges

17 composed patterns assembled from primitives. The checkout flow existed as a single nested component with 3-step / 1-page variants, locale toggle, and Kaspi/QIWI/Visa payment configurations built in.

Pattern Library · Locale-aware

4

Storybook token sync — design → code, zero drift

Worked with the lead engineer to export Figma token JSON directly into the CSS custom property layer. After this setup, updating a button radius in Figma updated it in production within one CI cycle — no manual specification required.

Storybook · Design Tokens · CI/CD

45+

Components Built

40%

Dev Time Saved

30%

Text Expansion Buffer

3

Locale Configurations

Phase 03 · 2 Weeks

Testing across markets before writing a line of production code

I ran 15 moderated usability tests on a high-fidelity Figma prototype simulating the complete purchase journey across all three locales. Participants were recruited through local Facebook groups and an existing customer list — not a panel service, which would have introduced unrepresentative tech-savvy users.

A/B testing covered two high-stakes decisions: CTA copy ("Pay Now" vs "Complete Order" vs "Confirm Purchase" — each tested per locale) and security messaging placement (above the fold vs. inline with payment fields vs. below the CTA).

Validation Phase Outcomes

"Confirm & Pay" outperformed "Pay Now" by 27 percentage points — became the global default CTA across all three locales

Security messaging placed inline with payment fields drove +23% trust perception vs. above-the-fold placement

Localized payment flows (Kaspi for KZ, QIWI for RU) increased conversion by 23% and 18% vs. generic flow

Session replay on prototypes identified 3 hesitation points before the final payment click — all resolved before production

Prototype Testing Report · 15 Participants · 5 Tasks

Phase 04 · Weeks 7–8

Rolling out across three time zones

Implementation ran across 3 time zones — Kazakhstan (UTC+6), Russia (UTC+3), and my own. I structured developer collaboration around daily async Slack updates and biweekly live handoff calls to review complex components. Rather than a big-bang launch, we used a staged rollout: internal → 10% → 50% → 100%, with PagerDuty monitoring at each gate.

Deliverable	Format	Outcome	Impact
Component specs	Figma Dev Mode + annotations	Zero redline clarification requests	−40% back-and-forth
Locale handoff	JSON string tables per locale	Cyrillic text overflow resolved pre-build	30% buffer applied
Staged rollout	Internal → 10% → 50% → 100%	Zero critical bugs at full launch	0 rollbacks
Analytics setup	GA4 + conversion events	Data available from day 1	Immediate optimization
Payment integration	Kaspi API + QIWI + Stripe	−42% payment errors post-launch	Trust score 2.1 → 4.8

Key learning: The component library cut engineering estimates by ~35% and freed the team to focus on polishing complex interactions — particularly the smooth integration of the Kaspi payment redirect and return flow, which required 6 edge-case states to handle gracefully.

Phase 05 · Ongoing post-launch

Post-launch monitoring → compounding improvements

The first 30 days post-launch were treated as an extension of the design process, not a handoff point. I monitored GA4 dashboards daily, reviewed Hotjar session recordings every 48 hours, and ran weekly feedback synthesis sessions with the PM. Three significant optimizations shipped in the first month alone.

+15%

Additional conversion lift

Post-launch A/B tests on the product page CTA placement and product photography aspect ratio drove an additional 15% conversion lift on top of the launch baseline.

−30%

Support tickets reduced

Order status emails redesigned based on support ticket analysis — "Where is my order?" was the #1 query. Redesigned the confirmation and tracking flow, eliminating the root cause.

$200K

Monthly revenue at month 2

B2B bulk ordering portal — identified from session recordings showing business buyers struggling with single-unit checkout — launched at week 6 post-launch and immediately attracted corporate accounts.

Design System

45+ components. 3 languages. One system.

I built a complete component library from scratch — 45+ reusable components with built-in multilingual support, 30% text expansion buffers for Cyrillic text, and culturally-adapted color frameworks. The system reduced front-end development time by 40%.

What I Learned

Lessons that shape every project since

User Feedback

What users said

The Problem

"Feels like hacking a system from 1995"

Craigslist, while iconic, was hemorrhaging users to modern marketplace apps. Anonymous listings, no credibility signals, buried filters, and desktop-centric layouts created a friction-filled experience that rewarded patience over trust.

18 user interviews surfaced a consistent theme. Buyers were doing 20+ minutes of external research before messaging a seller — cross-referencing phone numbers, searching reverse lookups, checking Reddit. The product had forced users to build trust infrastructure outside the product.

Design Screens

Trust, filtering, and listing at a glance

craigslist.org / furniture

Browse view · Image-forward grid with persistent filter sidebar

craigslist.org / post / new

Posting flow · Step 3 of 5 with draft auto-save

craigslist.org / fuo / 7429821

Listing detail · Structured data fields + seller trust hierarchy — evidence before description

Mobile offer flow · Safe message relay — negotiation without exposing contact details

craigslist.org / furniture

Browse view · Image-forward grid with persistent filter sidebar

craigslist.org / post / new

Posting flow · Step 3 of 5 with draft auto-save

craigslist.org / fuo / 7429821

Listing detail · Structured data fields + seller trust hierarchy — evidence before description

Mobile offer flow · Safe message relay — negotiation without exposing contact details

Process Breakdown

Discovery → System → Validate → Ship → Listen

Eight weeks, five phases, one mandate: make Craigslist feel trustworthy without making it feel corporate. Every design decision had to pass the "would a power user still recognize this?" test.

01 · Discovery 02 · Design System 03 · Validation 04 · Implementation 05 · Launch

Phase 01 · 2 Weeks

Mapping frustration to specific interaction failures

I ran 18 user interviews with a mix of casual buyers, power sellers, and first-time users in the San Francisco Bay Area — Craigslist's most active market. Sessions included a contextual task: participants shared their screens and walked me through a real Craigslist session while thinking aloud. This produced specific failure moments, not generalized dissatisfaction.

I also ran a competitive audit across 5 marketplaces: Facebook Marketplace, OfferUp, eBay Local, Mercari, and Depop — analyzing exactly which trust mechanisms each used and how they handled the buyer-seller verification problem differently.

Key discovery: Users weren't afraid of Craigslist per se — they were afraid of the specific information gap. When a seller profile included a name, photo, review count, and response time, user willingness to initiate contact jumped 3x in session simulations. Trust is about information density, not badge design.

18

Interviews + diary studies

Mix of buyers, sellers, and first-time users. Diary studies ran over 5 days — participants logged every Craigslist interaction with friction ratings.

5

Marketplaces audited

FB Marketplace, OfferUp, eBay Local, Mercari, Depop — mapped trust mechanisms, filter UX, mobile posting, and verification flows.

94%

Cited trust as primary barrier

The overwhelming majority of users named seller credibility — not price, not distance — as the primary reason they hesitated or abandoned a potential transaction.

Phase 02 · Design System

"Calm and competent" — not flashy

The design philosophy for Craigslist Evolved was deliberately restrained: neutral fonts, controlled palette, trust-first layout hierarchy. The system needed to feel like a public utility — something the community already owned — not a startup rebrand.

Type stack: Open Sans for UI labels (high readability at small sizes), Inter for body content, SF Pro on Apple devices. Palette: charcoal (#2A2A27), warm off-white (#F7F5F0), teal accent (#0D7A5F). Every color decision was tested against WCAG AA contrast ratios.

1

Listing card component — the most-used element in the system

Designed 4 card variants: grid (browse), list (search results), featured (pinned ads), and compact (saved items). Each variant shared the same data model but adapted density for context. Trust score and verification badges surfaced at the card level — not buried in the profile.

4 variants · 2 breakpoints · Figma

2

Filter system — desktop persistent sidebar + mobile modal

Desktop: persistent left sidebar, always visible, state persists across search. Mobile: full-screen modal with apply/clear actions — no incremental hiding. The mobile modal was the A/B test winner vs. a bottom drawer, improving task completion by 25%.

A/B tested · +25% completion

3

Seller profile hierarchy — evidence stacked, not declared

Profile design deliberately led with social proof (reviews, repeat buyers, response rate) before showing any self-declared information. The Trust Score (98/100) was positioned above the seller's self-written bio — making verifiable signals the first thing buyers saw.

Trust architecture · Social proof first

4

6-step posting flow with draft auto-save at each stage

Category → Details → Photos → Location → Preview → Publish. Draft saved after each step. A stacked progress indicator (not a linear bar) showed all 6 steps at once — reducing anxiety about total effort. Confirmation screen animated the listing going "live" to reinforce completion.

6 steps · Auto-save · Completion psychology

Phase 03 · 2 Weeks

Three methods, one truth: evidence beats opinion

Validation ran concurrently across three methods — each answering a different type of question. Usability tests answered "can users accomplish the task?". A/B tests answered "which design decision performs better?". Trust signal research answered "what actually changes buyer behavior?"

Method	Sample	Key Question	Result
Moderated usability tests	22 participants	Can users find a trusted seller and initiate contact?	89% completion (target: 85%) · SUS 84 "Excellent"
A/B: Filter interaction	Split test prototype	Drawer vs. modal — which completes faster?	Modal: +25% over drawer — shipped as default
Trust signal research	22 participants	Which signals most increase contact intent?	Name + rating + reviews > generic badges
Session replay on prototype	Heat map analysis	Where do users hesitate before messaging?	3 hesitation zones identified, all resolved pre-dev

89%

Task completion rate

84

SUS score (Excellent)

4.4/5

Trust rating in tests

+25%

Modal vs. drawer lift

Prototype Testing Report · 15 Participants · 5 Tasks

Phase 04 · Weeks 5–7

Component handoff · Dev syncs · Structured content

Implementation was structured around a single principle: zero ambiguity in the handoff. Every component in Storybook matched its Figma counterpart at the token level. Bi-weekly live calls reviewed complex components — filter logic, trust score calculations, offer flow edge cases. Slack async covered daily QA notes.

1

Component-centric handoff — Figma Dev Mode + Storybook

Every component exported from Figma Dev Mode with pixel-perfect specs, spacing annotations, and interaction notes. Storybook served as the live source of truth — engineers pulled tokens directly, no redlines needed.

−40% frontend build time

2

Bi-weekly design-dev syncs — complex components first

Focused on the 5 most complex components: filter modal with state persistence, trust score calculation display, offer negotiation flow, message relay system, and the 6-step posting wizard. Zero inconsistencies shipped in the final build.

Zero inconsistencies in final build

3

Structured content strategy — listing data model

Moved listings from free-text descriptions to structured fields: condition (enum), dimensions (number+unit), material (taxonomy), and description (free text). This enabled filtering, comparison, and search — and drove the 88% filter adoption rate.

88% filter usage post-launch

Phase 05 · 4-Week Rollout

Bay Area first → listening on Reddit → full launch

The rollout was phased by design — not as a risk mitigation checkbox, but as a genuine data-gathering opportunity. The Bay Area was chosen as the canary market because it had the highest Craigslist activity density, meaning engagement signals would surface quickly.

Week	Scope	Key Signal	Action
Week 1	Bay Area · internal users	All KPIs exceeded targets from day 1	Stable — proceed to 10%
Week 2	10% traffic · Reddit monitoring	"Make Offer" flow praised, clarity gap noted in copy	Iterated copy — "Make Offer" → "Propose Price"
Week 3	50% · vs legacy A/B	+78% engagement vs legacy baseline	+34% offer rate from single copy change
Week 4	100% · full launch	−52% suspicious reports · 88% filter usage	Optimization backlog opened for month 2

Final Launch Outcomes

+78% engagement (time on page) across all user sessions — desktop and mobile

−52% suspicious listing reports — trust infrastructure working as designed

88% of all sessions used filters — structured data model enabling new behavior

+34% offer rate from a single post-launch copy iteration — community feedback → shipped fix in 4 days

Lessons

What this project proved

User Feedback

From post-launch community monitoring

The Problem

This is not a user problem. It's a product problem.

LinkedIn's Save feature is used by millions daily. Yet fewer than 30% of saved items are ever revisited. The conventional interpretation was that users forget. But that's the wrong diagnosis.

The real problem was that the product gave users no reason to return. A flat chronological list with no organization, no recall cues, no privacy clarity, and no mobile-equivalent experience. Saving was easy. Finding what you saved — weeks later, when it mattered — was nearly impossible.

Design Screens

From archive to action system

linkedin.com/my-items/saved

Desktop view · Smart Collections sidebar + privacy controls

Mobile view · 100% feature parity — save, organize, and act from any device

Process Breakdown

Diagnosing three root causes. Designing one system.

As the sole designer, I owned the entire arc — research, IA, interaction design, visual design, and testing. No handoff between phases, no lost rationale. Every decision traced directly back to a user insight.

Impact

Outcomes that map to business metrics