Reach me at:
andrewshpachuk@gmail.com
↗
@lingvo838
↗
↗
Contact
About
ZVELTA – Global Car Marketplace
A car-marketplace aggregator covering Europe and beyond — redesigning core search behaviour, the homepage, the mobile app onboarding, and the visual system around them.
Role
Product Designer
Client
Zvelta — global car marketplace aggregator
Year
2026
Platform
Web + iOS
Scope
Make/model selector, homepage redesign, mobile app onboarding, 404 concepts
Live
Tools
Figma
Overview
Zvelta is a car-marketplace aggregator that pulls listings from private sellers, dealerships, and auctions across Europe and globally. The product covers multiple regional domains — zvelta.md, zvelta.ro, zvelta.eu, plus the global zvelta.com — and runs across web and a mobile app. At the time of this engagement, the platform was indexing 239 million active listings with 47,000+ cars added daily. Real scale, real users, real product complexity.
I came onto the project through my development partner — the WordPress developer I've worked with for years — who was building Zvelta with a friend leading the product. The brief was broad: solve specific UX problems on the live product, redesign the homepage, build a new mobile app onboarding from scratch, and propose concepts for the 404 page. Everything went into production.
This case focuses on the most demanding piece — the make and model filter — and covers the rest of the engagement around it.
The core problem — selecting cars by make and model
On a marketplace with 50,000+ cars across hundreds of brands and thousands of models, the filter is the product. Get it wrong and users either give up or never narrow down enough to find what they actually want.
The original flow let users select makes and models, but did it through a stacked popup pattern that was awkward to use in practice.
The problems showed up in analytics and user feedback:
— Selecting multiple brands at once was painful. The popup forced users back to a state where adding a second make required re-finding it in a long alphabetical list every time.
— Selecting many models across many brands was worse. Users searching "Mercedes-Benz S-Class or BMW 5-Series or Audi A6" — a normal cross-shopping behaviour — were funnelled through a flow that punished them for it.
— The interaction model wasn't clear. Checkboxes inside checkboxes inside a modal. Hard to tell what was selected, hard to deselect, hard to know how many results would come back.
The product team had data showing users dropping the filter mid-selection. The brief was to redesign it.
Eight hypotheses
Rather than committing to one direction, I prototyped eight distinct hypotheses for how the selector could work. Different interaction models — different layouts, different mental models, different mechanics for how a user adds a brand and then drills into models inside it.
Some of the directions explored:
— A single full-page selector with Marks on the left and Models on the right, both scrollable lists with search.
— A two-step modal where users first picked all the brands they cared about, then drilled into each one to pick models.
— A chip-based composer where each selected brand became a chip that opened its own model picker on tap.
— A table-style overview showing brands as rows and a count of selected models per row.
— A mobile-first bottom-sheet approach pushed up to desktop with adapted mechanics.
— Variations on how popular brands surface vs. the long alphabetical tail.
— Variations on how the result count updates — instant, on-confirm, real-time preview.
Each hypothesis was prototyped to a level where you could click through it and feel the rhythm of the interaction. The point wasn't to ship eight versions — it was to have the conversation with the team based on real, working flows rather than hand-wavy descriptions.
The chosen direction
The version that worked combined three ideas that no single earlier hypothesis had together:
A persistent sidebar list — not a popup. Brands and models live inside the filters column itself, alongside Price, Year, Location and the rest. No modal, no popup, no context switch. Users see their current selection and the rest of the filters at the same time.
Hover or tap a brand to preview its models inline. Instead of opening a separate dialog, the brand expands a contextual popover with its model list — searchable, scrollable, with the model count visible. Closing the popover takes one click; opening another brand replaces it cleanly.
Selected brands turn into chips. Each chip can carry "all models" or a specific subset. Tapping a chip reopens its model picker so the user can refine. Removing a chip is an X, not a hidden state. The structure makes it obvious at a glance what's currently filtering the results, even when several brands are selected.
The "Add 6 Mercedes-Benz models" CTA is intentional — it tells the user exactly what's about to happen and how many things are about to be added. Tiny detail; big impact on confidence.
This wasn't necessarily the most clever pattern of the eight. It was the clearest one. That was the deciding factor — clarity beat cleverness.
Mobile — adapting the same logic
Mobile got a full adaptive treatment of the same pattern. The challenge: a sidebar doesn't exist on mobile. The pattern had to work in a single column without losing the structural clarity that made it work on desktop.
The mobile flow keeps the same logic but trades the sidebar layout for a stacked one:
— Brands list expands inline, instead of opening a popover next to it.
— Model search is full-height when active — no cramped 200px popover trying to fit a long list.
— Chips compose at the top of the filter sheet, mirrored from desktop — so users moving between devices see the same shape of selection.
— The "Show 1,478,844 results" CTA is sticky at the bottom, so the result count updates in real time without forcing the user to scroll back.
Same model, two devices, no compromise either way.
Homepage — redesigning around two audiences
In parallel with the filter work, I redesigned the homepage. The original was a single layout for everyone — a generic hero with a search form and a car illustration. It didn't speak to who was actually arriving.
The insight came from how Zvelta's traffic actually splits. People arriving on the site are doing one of two things: buying or selling. Showing both groups the same hero forces both into a generic message that doesn't fully serve either.
I designed the homepage as two role-based variants, switchable via a "Find a Car / Sell a Car" toggle in the navigation:
— The buyer variant opens with "Buy any Cars Worldwide", a multi-field search panel (Make, Model, Years, Price, Mileage), and a live "Just Added" feed of newly listed cars to reinforce that the marketplace is alive.
— The seller variant opens with "Sell any Cars Worldwide" plus a live count of cars sold today, a streamlined listing form (Make, Model, Year, Month, Body Type), and the same "Just Added" feed in the periphery to demonstrate active demand.
Reactive video backgrounds. Each variant carries a different background video. On the buyer side, a car drives toward the viewer — coming closer, more attainable. On the seller side, a car drives away — being delivered, departing. Subtle, but it ties the visual atmosphere to what the user is there to do.
Both variants share the same brand strip (BMW, Toyota, Mercedes, Honda, VW, Jeep, Nissan, Ford, Dodge, Opel, Porsche) at the bottom — common ground that says "we cover what you're looking for" regardless of which side you came in from.
Mobile app onboarding
The mobile app needed onboarding from scratch. Previously there wasn't one — users opened the app and dropped into the search screen without context, without explanation of what Zvelta actually was, and without an obvious path to either start searching or list a car.
The flow walks the user through five screens, each with one job:
01 — Position the product. "Buy and Sell Cars with more clarity." A visual breakdown of the four sources Zvelta aggregates (private sellers, dealerships, auctions, imported) so the value prop lands immediately.
02 — Show the search story. "Search smarter, find faster." Dozens of filters, one search, results from private sellers, dealers and auctions all at once.
03 — Geo-detection and local routing. "Choose your local version." The app detects the user's likely country (Moldova in this case) and offers it as default, with Romania, Global, and European versions also visible. This is where Zvelta's regional structure (zvelta.md / zvelta.ro / zvelta.eu / zvelta.com) becomes a feature, not a backend detail.
04 — Account creation. "Create your free account." Apple, Google, X auth as primary options, with "Continue without account" preserved so users who don't want to commit aren't locked out.
05 — Activate the seller. "Sell your car fast and free." Live counter of cars added today, sold cars last 24 hours, visits last month — proof that the marketplace is alive — paired with an "I want to sell now" CTA and a softer "Maybe later" exit.
Every screen has a consistent shape — Skip in the top right, brand mark up top, hero text mid-screen, supporting content below, primary CTA bottom — so users learn the rhythm of the flow within two screens.
404 — five concepts
The product team also asked for fresh 404 page directions. Not a critical surface, but one users hit unexpectedly and remember.
I designed five concepts ranging from playful (a lost car illustration) to functional (search bar with popular categories surfaced) to brand-driven (typographic only). The chosen variants ship in production and rotate based on context — different sections of the site can pull a different 404 personality without breaking the visual system.
Outcome
Everything from this engagement is live on Zvelta. The make/model filter, the redesigned homepage with its two role-based variants and reactive video backgrounds, the mobile app onboarding, and the 404 set — all in production.
You can see the live product at zvelta.com.
I don't have direct access to post-launch analytics, but the work was scoped from analytics in the first place — the filter redesign was driven by drop-off data, the homepage split was driven by traffic-pattern observations, and the onboarding was added because the team saw users dropping out of the app on first open. Each piece was tied to a real signal, then designed and shipped against it.
Reflections
The most useful thing I did on this project was building eight prototypes for the filter instead of arguing for one. It felt slow up front. It saved weeks of debate later, and it surfaced a pattern that wouldn't have come out of a single direction.
If I were doing this engagement again, I'd push earlier for built-in measurement on the filter — events on every interaction, not just outcomes. The team has the data on whether users now find what they're looking for. They don't yet have the data on which exact moment in the new pattern carries the most weight. That's the next question for whoever picks up the next iteration.
© 2026. Made by Andrew Sh