ScrapeHero

Context

ScrapeHero is a data and web-scraping company with three business lines: an enterprise data-as-a-service practice (ScrapeHero Services), a self-serve product (ScrapeHero Cloud, with a Marketplace as its marketing site), and a data store selling 3,200+ POI datasets (ScrapeHero Data Store).

I redesigned all three surfaces and the design system that holds them together. The product was already live with 14,000+ customers across the company, so my work was improvement and consolidation, not greenfield.

I worked with PMs, sales teams, and other stakeholders to understand pain points, used PostHog and Microsoft Clarity to read user behaviour, and made the design calls.

This case study walks through the work on each surface, then the design system that ties them.

1. ScrapeHero Data Store

The Data Store sells point-of-interest datasets: addresses, store locations, hours, attributes, scraped from public sources. 3,200+ datasets across categories. Buyers are mixed: data analysts, researchers, business teams. They buy one-time downloads, subscribe for refreshed data, or request historical snapshots for time-series analysis.

When I started, the store had every UX problem at once. Filtering didn't behave like a normal e-commerce filter. All datasets sat on one uncategorised page.

Listing cards

The original cards showed a name, a thumbnail, and a price. Buyers couldn't tell whether a dataset was fresh, how big it was, or what it covered without opening the PDP. Click-through rate was high, but qualified-purchase rate was low. People were clicking to evaluate, not to buy.

I redesigned the cards to surface the metadata that drives the buying decision: coverage, last updated date, record count, and sample availability. The card stopped being an invitation to click and started being a small, scannable specification.

PDP and the historical data problem

Historical data is one of the highest-margin offerings on the store. The old PDP buried this option three scrolls down. I moved it next to the primary add-to-cart, framed as a clear option rather than a hidden upsell. Users evaluating a dataset now see the historical option at the moment they're deciding to buy.

Filters and category pages

I rebuilt the filter to follow standard e-commerce filter conventions (multi-select, applied state visible, clear reset). I categorised the datasets, then built individually optimised listing pages and PDP variants for each category. A dataset of restaurant locations now lives on a page tuned for its specific buyers, with relevant filters and metadata.

2. ScrapeHero Cloud and Marketplace

ScrapeHero Cloud is a self-serve product offering pre-built scrapers and APIs. I worked on two surgical fixes inside Cloud, both identified through PostHog session recordings and funnel analytics.

The hidden Plan Upgrade

When users hit their plan limit, the upgrade button sent them to Settings, where plans were buried in a sub-tab. I worked with the team to change the flow. The upgrade button now goes straight to a dedicated Plans page. Small in design terms, significant in funnel terms.

The scraper detail page CTA

Each scraper had a primary CTA reading "Create a Project". For new users, this was confusing. I changed the CTA language and flow to "Use this scraper" with a first-run experience that didn't require users to understand project structure before getting value.

Impact: Together, the Plan Upgrade fix and the CTA fix improved subscription conversion by approximately 15% and reduced drop-off by approximately 10%, validated against PostHog before-and-after data.

The Marketplace revamp

Once Cloud's flows were stable, I redesigned the Marketplace. Better filters, clearer category labels, scannable scraper and API listings. I also built it around a scalable system, so when Cloud ships a new scraper or API, a new Marketplace page can be created without redesigning anything.

3. ScrapeHero Services and the system

ScrapeHero Services is the enterprise side: custom data delivery for large clients. The site had 40+ pages suffering from inconsistent navigation, broken IA, and visual inconsistency between pages.

I revamped all 40+ pages on a consistent design system, fixed the navigation and IA, and built page templates that the team could extend without re-designing each page from scratch.

The design system across all three surfaces

The connective tissue across the Data Store, Cloud, Marketplace, and Services site is one shared design system. Tokens, type scale, components, page templates, all of it lives in one place and is used across every surface. A user moving across these products experiences one brand, not three.

Build and handover

I designed and built all three surfaces in WordPress with Elementor (Services site, Marketplace), and WooCommerce (Data Store).