All work

Case study 01 · Fintech · WordPress · Jul–Oct 2025

Kurv: a payments site rebuilt around how people convert

EMS was rebranding to Kurv. The brief was to make the website look modern. I led UX across design, development, content, SEO and product, reframed the work around the journeys that lead to a sign-up, and kept going after launch until the site was fast.

Role
UX lead & cross-functional coordinator
Team
Designer, 2 developers, PM, content, SEO
Timeline
July – October 2025
Platform
WordPress (Gutenberg)
Three phones showing the redesigned Kurv site on mobile: a POS device comparison table, the 'Featured on' press section under a terminal product shot, and the retail pricing cards with an Apply button.
The rebuilt site on mobile: device comparison, trust signals and pricing, each built as an editable Gutenberg pattern.

01 Context

A rebrand became the moment to fix everything the old site couldn't do.

EMS, a payments company, was rebranding to Kurv. The website had grown for years without a clear information architecture, and the rebrand was the catalyst to rebuild it on WordPress with Gutenberg.

Five groups had a stake in the result, the timeline was fixed, and everyone was also working on other priorities. My job was to keep the work moving: bridge design, development, content and SEO, flag problems early, and drive decisions when teams were blocked.

02 Problem

The brief said "make it look good." The real problem was that nobody could change the site.

Three problems sat under the visual brief:

  • No structurePages had accumulated without an IA, so users had no clear path from interest to sign-up.
  • Heavy on mobileVisually dense layouts performed poorly on small screens and slow connections.
  • Locked for editorsContent and SEO teams couldn't update copy without engineering, so every change waited in a queue.
Visually appealing doesn't automatically mean the conversion numbers will follow.

03 Discovery

I mapped what a merchant needs to see and do before they convert.

Partway into the project it was clear we needed to hold two goals at once: a site that looked credible and modern, and one structured to move people toward action. I raised this with the designer and PM, and we mapped the primary user journeys before refining visuals.

We then ran a workflow review with the full team: designer, developers, content and SEO. It confirmed the structure made sense to users and surfaced patterns that would have caused problems later.

Merchant journey map from the discovery workshop, in five steps: Recognize, Understand, Trust, Decide and Act. Each step shows the merchant goal, what got in the way, what was designed, and how it would be measured. Recognize: goal
Merchant journey, from the discovery workshop. Each merchant goal traced to the problem in the way, the design response and the metric that would show it worked.

I also reviewed how other payment and fintech companies present themselves: full-page teardowns of Stripe, Global Payments, Heartland, Ramp and Mercury, plus seven fintech hero sections. Five patterns kept repeating, and each one shaped a section of the new homepage.

Competitive research board with full-page screenshots of Stripe, Global Payments, Heartland, Ramp and Mercury, plus seven fintech hero sections. Five numbered patterns: 1, recognizable customer logos under the hero, which became Kurv's 'Featured on' press logos; 2, the whole product suite at a glance, which became the ecosystem card grid; 3, big numbers in a stats band, which became the stats and 24/7 support band; 4, routing by industry, which became industry tiles and the audience router; 5, human support as a selling point, which became 'people who pick up the phone'.
Competitive research. Patterns that repeated across leading payment sites, and where each one shows up on Kurv.

04 Insights

The bottleneck wasn't the design. It was everything around it.

  1. Journeys before visuals.Visual refinement works best as a layer on top of a structure that already answers "what do I need to see to sign up?"
  2. Editors are users too.If the content and SEO teams can't update a page, the site goes stale the week after launch.
  3. Desktop-clean isn't mobile-safe.Several layouts that looked tidy at 1440px broke at tablet and phone widths.

05 Opportunity

Rebuild around journeys and editor autonomy, not just a new skin.

How might we launch a site that looks like Kurv, guides merchants to a sign-up, and that the content and SEO teams can keep updating without filing tickets?

06 Solution

Three decisions shaped the build.

Decision
Hard-code heroes and one-off promos. Build anything editors touch often as a Gutenberg pattern.
Why
Not everything could be flexible in the time we had. This rule protected the launch date without creating a content bottleneck.
Trade-off
Hard-coded sections need a developer to change. We chose them on purpose, and the whole team knew which ones.
Decision
Fix three SEO-hostile CMS patterns in design, not after launch.
Why
The workflow review showed these patterns would have hurt how pages were indexed. Fixing them in Figma cost hours; fixing them live would have cost weeks.
Trade-off
A few layouts lost some visual flourish to keep headings and content crawlable.
Before and after of Kurv's pricing pattern. As proposed: two rate cards under tabs, with the Zero Fee plan, marked Most Popular, hidden behind a second tab, and rates shown with no description. As built: one table with Option and Your rate headers, all three plans visible as rows, each with a plain-language description such as 'Card present at your terminal', and rates shown per transaction.
Caught in design review. One of the three SEO-hostile patterns: the pricing section as proposed, and the same pattern as built.
Hard-coded versus pattern map for five Kurv page types: homepage, product pages (11), industry pages (10+), pricing, and blog posts (97). Each page type is a stack of its sections, tagged hard-coded, editable pattern, or automatic template. The rule: heroes and one-off promos are hard-coded; anything content or SEO updates often is a Gutenberg pattern. Most heroes, the homepage research promo, audience router, partner block and careers CTA, and the pricing fee tables are hard-coded; the pricing hero with its rate cards is an exception and is a pattern because rates change. Most other sections are patterns. FAQ and the closing CTA band are reused on four page types; testimonials on three. The blog post's featured image is crossed out, removed after launch because it was the LCP element.
Hard-coded vs. pattern. Five page types, tagged section by section. The patterns that appear across templates are what let editors work without engineering.
Decision
Solve responsive problems in short three-way sessions: designer, developer and me.
Why
Faster than handoff ping-pong, and developers understood the intent when they hit edge cases on their own.
Trade-off
More meetings early, far fewer surprises in staging.
Before and after of Kurv's hardware comparison table on mobile. As first designed: a fixed label column takes half the screen and only one device shows at a time, with an arrow to see the next. After the three-way session: spec labels sit in full-width bands, the Kurv Smart Handheld and Axium DX8000 show side by side with the PAX A920 peeking in from the edge, feature rows use check and cross icons, and an Apply button sits under the Kurv column.
Responsive decisions. The device comparison table on mobile, as first designed and after the three-way session with design and development.

07 System

Patterns for editors and an asset spec for everyone.

The Gutenberg pattern library became the site's design system for the people who'd maintain it: consistent output, with room for content and SEO teams to edit copy. Every image and icon also passed one checklist before reaching developers.

Asset spec, applied to every image
CheckRuleWhy it matters
DimensionsSized for its slot, not the original uploadNo downloading 3000px for a 600px card
FormatWebP where supportedSmaller files at the same quality
Alt textDescribes purpose, empty for decorationScreen readers and image search
File sizeWithin the budget for that page typeProtects LCP as content grows
Annotated screenshot of Kurv's WordPress pattern library. 1: Patterns are grouped into categories such as Call to action, Case Study and Comparison, with 273 patterns available from all sources. 2: Patterns are named by section and page type, for example 'Hardware Section of Industries Page'. 3: Theme patterns are locked so the design cannot drift, and marked 'Not synced' so each page gets its own editable copy.
Pattern library. Grouped by job, named by section and page type, and locked in the theme so editors can't break the layout.
Annotated WordPress editor screenshot of Kurv's pricing page. 1: In List View, the whole Pricing Hero Section, headline plus three rate cards, is one named pattern. 2: The sidebar labels it as a pattern with a description of what it is for. 3: The Content panel lists only the text and images editors change. 4: The Swiped rate card shows 2.50% + $0.10 as plain text, so updating a rate is a text edit.
Editor view. The pricing hero in the WordPress editor: one pattern, with rates the pricing team can update themselves.

08 Build

Launch revealed what staging didn't, so I kept going.

I ran daily check-ins with developers: which pages and patterns were due that day, what would be hard-coded, and what could wait for a post-launch pass. Before sign-off I checked each layout with the designer for image dimensions, icon formats and component behaviour at every breakpoint.

After launch, real traffic showed pages loading slower than acceptable. On blog posts, LCP was dragged down by large featured images that added little to reading an article.

Decision
Remove the featured image from single blog post templates.
Why
It was the LCP element and it wasn't earning its weight. This was a design decision as much as a performance one.
Trade-off
Less visual on post pages. Readers get to the content faster.
Before and after of Kurv's blog post template on mobile. Before: a large featured image of a credit card on a fishhook sits between the post title and the table of contents, marked as the LCP element. After: the featured image is gone, and the table of contents starts right below the title and bylines. One template edit changed all 97 blog posts.
Performance fix. The blog post template on mobile, before and after removing the featured image. Shown on two different posts that share the template.

We also re-compressed every image, wrote the asset spec above so the problem wouldn't come back, and reworked several patterns to give editors more freedom.

09 Results

A site that launched on time, is fast for real users, and stayed editable.

  • Jul–Oct 2025Delivered on schedule across five teams.
  • PassedCore Web Vitals for real users, on mobile and desktop.
  • Editor autonomyContent and SEO teams update copy through patterns, without engineering.
Google PageSpeed Insights, October 2026
MeasureMobileDesktop
LCP, real users (last 28 days)1.7s · Passed1.0s · Passed
LCP, lab (simulated Lighthouse run)8.6s0.8s
Lighthouse performance score63 / 10097 / 100

Real users load the largest element in 1.7 seconds on mobile, well inside Google's 2.5-second threshold. The lab number is much worse because Lighthouse simulates a slow phone on a throttled connection. I read that gap as headroom, not a failure: it shows what still costs time on slower phones, and it's where I'd look next.

10 Reflection

What I'd take into the next project.

  1. 01

    Looking good and converting are different goals.

    Keeping that tension explicit, instead of assuming one implies the other, produced a better site than either direction alone.

  2. 02

    Make constraint-driven trade-offs on purpose.

    The hard-coded vs. pattern rule was a response to the timeline. Deciding it deliberately meant the whole team owned the trade-off instead of discovering it after launch.

  3. 03

    Post-launch is part of the design process.

    The performance issues weren't failures. They were data, and acting on them is what made the site perform.

Next case study04 Kurv landing page