# Masterly — Full Content

> Masterly is an embedded design team for B2B SaaS, fintech, healthtech, and AI startups — UX/UI, product design, branding, and Webflow development built to drive activation, retention, and conversion. This file inlines the full text of the Masterly blog and glossary for answer engines.

Site: https://www.themasterly.com
Services: UI/UX Design, UX Audit, Web Design, Mobile App Design, Design From Scratch MVP, Product Redesign, Branding, Design System, Motion Design, Landing Page Design, Fintech Design, Pitch Deck For Investors, Ad Creative, Social Media Creative, Email Design, Team Extension, Embedded Design Team, Web Development, Webflow Development, Framer Development, Shopify Development, WordPress Development
Industries: Fintech, SaaS, Healthcare, Ecommerce, Web3, EdTech, Legal Tech, Real Estate, Automotive, Travel, AI ML, Wellness Sport, Websites

## Blog

### Website Redesign SEO: The Checklist We Run to Protect Rankings
URL: https://www.themasterly.com/blog/seo-website-redesign
Product Design · 2026-08-11

Traffic loss after a redesign does not announce itself. The site launches, everyone is pleased, and the chart looks normal for weeks because rankings decay rather than vanish.

Read enough public post-mortems and the detection lag is the most consistent number in them. In documented cases on Google's own support forum, owners noticed three months after launch, five months, six months, and in one case seven months, by which point the cause was buried under a hundred changes that all happened on the same day. One team lost roughly 1,500 of 2,000 indexed URLs to a staging file and caught it a full week later, for a mundane reason: the launch fell over a holiday break and nobody ran the weekly report. The people who caught problems in days were the ones watching Search Console daily.

We run redesigns for B2B SaaS and fintech companies, and this is the checklist we work through to prevent that. It is organized by phase rather than by topic, because the sequence matters more than the list: half of these items are cheap before design starts and expensive after launch.

What this guide covers:

1. Six technical terms in plain language, if you commission this work rather than do it
2. What causes ranking loss in a redesign, ranked by blast radius
3. The variable that predicts whether it happens to you
4. The checklist in five phases, from baseline to the first 30 days
5. The recovery advice the evidence does not support
6. What agent-coded builds break that older checklists never covered
7. What to do if you already launched and the traffic dropped

## Six terms, in plain language

This article gets technical in places. If you commission redesigns rather than implement them, these six words carry most of the weight, and the rest of the piece reads fine on top of them.

| Term | What it means |
| --- | --- |
| 301 redirect | A permanent forwarding note: "this page moved, it now lives here" |
| noindex | A tag telling search engines to leave a page out of results |
| robots.txt | A file telling search engines which parts of the site they may look at |
| Canonical | A tag saying "this address is the real version of this page" |
| Soft 404 | A page that answers "found it" but shows nothing useful, so search engines file it as missing anyway |
| Content parity | The new version of a page covers the same ground as the old one |

## What causes ranking loss, ranked by damage

Most redesign SEO checklists run to thirty flat items, which implies they all matter the same amount. Four failures account for most of the damage we see in inherited projects, and a long tail of smaller items accounts for the rest.

**A staging noindex tag or robots.txt reaching production.** The most damaging single error, because it removes the whole site rather than degrading part of it. Development environments carry `noindex` to stay out of search results, and when the launch process copies staging configuration to production, the directive rides along. The site looks perfect to every human who visits.

The fix has a trap in it. Applying `noindex` to a URL and blocking that URL in `robots.txt` at the same time cancels the noindex: the crawler is not allowed to fetch the page, so it never reads the tag telling it to drop the page. One team spent two weeks trying that combination on an accidentally indexed staging site while their production site stayed unindexed. What resolved it was a 301 from the staging URLs to the production ones. Use one mechanism at a time, and know which one you are using.

**URLs changed without one-to-one redirects.** Every URL that ranked and no longer resolves takes its rankings with it. The common shortcut, redirecting everything to the homepage, does not work: search engines treat a mass redirect to an unrelated page as a soft 404 and the signals do not transfer.

The public record here is clear, because it happened to companies large enough for it to be measured from outside. When Topshop moved to ASOS in 2021 using wildcard redirects rather than per-URL mapping, [SISTRIX measured almost 80% of visibility gone](https://www.sistrix.com/blog/topshop-to-asos-80-off-in-search-visibility-migration/), and the destination site absorbed none of it. When Wiggle consolidated domains in 2023 and pointed every page at a homepage that was showing a holding message, visibility fell 95.88%, and [a year later it was still down 93.8%](https://www.sistrix.com/blog/indexwatch-2023-seo-visibility-losers/). Clarks consolidated four country domains through four and five hop redirect chains and lost around 97% of visibility in Spain and 92% in France.

Each old URL needs a 301 to its closest equivalent, mapped individually. Doing it late costs more than doing it right, because a URL that returns 404 long enough gets dropped from the index and its replacement starts from zero.

**Content and navigation quietly cut during the redesign.** Redesigns are also content projects, and "tightening the copy" on a page that ranks is a real risk. One replatforming team removed close to a thousand URLs in a single move under launch pressure and watched their average position fall from 32.5 to 40.1; three months of new content afterwards did not recover it.

Navigation is the version of this that nobody suspects, because cutting it is a defensible design decision. In one documented recovery, a redesign removed a side menu that linked to deep product pages. The loss surfaced months later, and restoring the navigation was what moved the numbers back. In another, a mega menu carrying about a hundred links was reduced to four for the sake of a cleaner header, taking the internal linking to the revenue pages with it. The person who diagnosed the first case put the cause in one line: there was no SEO in the room when the design got signed off.

**Internal links left pointing through redirects.** The site works, so this looks harmless. But every internal link routed through a 301 wastes crawl budget and dilutes the signal it passes, and chains of two or three redirects compound it. Update links to their final destinations rather than relying on the redirect layer to clean up after the build.

Everything after these four is worth doing and none of it will save you if one of the four is wrong.

## How much you change at once predicts the damage

The four failures above are what goes wrong. How many things you change on the same day determines whether they happen to you at all.

Look at migrations where the outcome was measured from outside, and they sort cleanly. The catastrophes all changed several things simultaneously: a new domain plus a new URL structure plus reorganized content. The uneventful ones changed exactly one thing. When the BBC moved Bitesize between its own domains and when RAC moved its cars section, the architecture and filenames stayed identical and visibility carried across intact. Currys absorbing PC World lost around 11%, and that involved retiring an actual brand.

Bundling costs you a second way, beyond the raw risk. When four things change on the same day and traffic falls, you cannot tell which one did it. Several of the best-documented cases landed within days of a Google core update, and the argument about cause was never resolved by anyone involved. They spent months unable to prove whether their own work or the algorithm moved the numbers.

Sequence your changes. Move the platform, verify, then change the design. Change the design, verify, then reorganize the content. It is slower on the calendar and much cheaper when something breaks, because you can point at the one thing that changed.

## Phase 1: Before design starts

Everything here is cheap now and expensive later. The inventory in particular: rebuilding it after launch from archives and backlink tools takes days and is never complete.

| Check | In plain terms | Owner | What breaks if you skip it |
| --- | --- | --- | --- |
| Export rankings, organic sessions by page, and conversions by page | A snapshot of what the site earns today | Client | No baseline. Three months on, nobody can prove what the redesign did |
| Build the URL inventory from four sources: crawl, Search Console, analytics, backlink tool | A complete list of every page you have | Agency | Pages that still earn traffic get dropped and nobody notices |
| Mark the protected set: top pages by traffic, conversions, and referring domains | The pages you cannot afford to break | Shared | The redesign optimizes layout on the pages paying the bills |
| Write the URL policy: what changes, what stays, and why | Decide now which web addresses will change | Shared | Addresses change quietly during design and surface at launch |
| Note any algorithm update in flight | Check whether Google changed something that week | Client | A later decline gets blamed on the wrong thing |

The four-source rule for the inventory is the one people skip. A crawler follows internal links, so it finds what the site links to. It misses pages that lost their internal links years ago and still rank, still collect backlinks, and still convert. We have found live, ranking pages on client sites that appeared in no crawl and no sitemap.

## Phase 2: During design

| Check | In plain terms | Owner | What breaks if you skip it |
| --- | --- | --- | --- |
| Content parity on the protected set: layout can change, substance cannot shrink | Redesign the page, do not shorten it | Agency | Pages that ranked on depth lose the depth that earned the position |
| Heading hierarchy preserved where it earned rankings | Headings stay real headings, not text that looks big | Agency | Search engines lose the map of what the page is about |
| Every template has a slot for title, meta description, canonical, and structured data | Each page layout has room for its search-result text | Agency | Metadata becomes a per-page afterthought handled inconsistently |
| Performance budget set alongside the design direction | Agree how heavy the new site is allowed to be | Agency | A richer site is a slower site, and speed affects rankings |

The content-parity line is where design and SEO collide in practice. When a designer proposes cutting a section from a page that ranks for the term that section covers, that is a content decision wearing a design costume. It needs an explicit sign-off from whoever owns the traffic.

The cleanest evidence here comes from split testing rather than post-mortems, because a split test isolates the change. [SearchPilot has published its losing tests](https://www.searchpilot.com/resources/blog/8-losing-seo-tests), and the one relevant to redesigns is a test that removed boilerplate copy from category pages because it seemed to serve little user purpose. Organic traffic fell 4%. The transferable lesson is that a change nobody would defend as a content decision can still be one.

## Phase 3: Pre-launch

| Check | In plain terms | Owner | What breaks if you skip it |
| --- | --- | --- | --- |
| ⚠️ Redirect map: one row per old URL, one destination each, 301 | Every old address points to its own new one | Agency | Rankings do not transfer. Sending everything to the homepage reads as a dead end |
| ⚠️ Named owner for removing the staging noindex and robots.txt | One person is responsible for un-hiding the site | Agency | The biggest failure on this list, prevented by one line in a runbook |
| Redirect chains collapsed so A points at C, not at B which points at C | No forwarding an address to an address to an address | Agency | Each extra hop weakens the signal and wastes crawler time |
| Full crawl of staging, compared line by line to the Phase 1 inventory | Check the new site against the list of what exists | Agency | Missing pages and broken links ship live |
| Metadata verified on the protected set | Confirm the important pages kept their search-result text | Agency | Errors built into a layout reach every page using it |
| XML sitemap regenerated and matching what the site serves | The map you hand search engines matches the real site | Agency | Search engines keep looking for pages that no longer exist |

The redirect map is tedious, mechanical work with no craft in it, and it is the highest-value hour in the project.

## Phase 4: Launch day

Run these in order, within the first hour, before anyone celebrates.

| # | Check | In plain terms | What breaks if you skip it |
| --- | --- | --- | --- |
| 1 | ⚠️ The noindex tag is gone from production | The "hide this site" instruction is switched off | The entire site drops out of search |
| 2 | ⚠️ robots.txt allows crawling | Search engines are allowed back in | Same outcome, different route |
| 3 | Canonical tags point at production, not staging | Pages claim the live address as the real one | Search engines list the test site instead |
| 4 | Top 20 old URLs requested by hand, not by pattern | Click your twenty best old links yourself | Bulk rules fail on odd cases and nobody checks |
| 5 | Sitemap submitted in Search Console | Tell Google the new map exists | Discovery takes longer than it needs to |
| 6 | Analytics implementation left unchanged this week | Do not swap tracking the same week | Two changes at once makes the next month unreadable |

Checks 1 and 2 take ninety seconds combined and prevent the two failures that cost the most.

## Phase 5: The first 30 days

| Check | In plain terms | Cadence | What it tells you |
| --- | --- | --- | --- |
| Search Console coverage errors and 404 count | How many dead pages Google is hitting | Daily, week one | Rising dead pages mean the redirect map has gaps. This moves before the traffic chart does |
| Rankings for the protected set vs. baseline | Are your best pages still where they were | Weekly | A few pages falling points at redirects or content; everything falling points at indexing |
| Organic sessions and conversions by page vs. baseline | Traffic and leads, page by page | Weekly | Separates a normal post-launch wobble from a real problem |
| New 404s added to the redirect map as they surface | Keep fixing dead links as they turn up | Ongoing | Old links from other websites keep landing on nothing |

Recrawling takes time, so some movement in the first weeks is expected. Be careful with the specific numbers you will be told about that. The signal that matters is direction. A dip that stabilizes and climbs is the process working. A dip still deepening past week three is a problem to diagnose, and "wait" is not a diagnosis.

Do not close the monitoring window early on a good first week. The pattern shows up repeatedly in post-mortems: one store ran for nearly three months of healthy traffic after a migration with no redirect map, then went from around 3,000 daily impressions to almost none overnight. Another saw about half its rankings transfer in the first week and decline from there. A third ranked at position 1 within hours on a new domain and collapsed again on day three. Search engines re-evaluate a migrated site over weeks, so the first reading is provisional. Keep watching for the full 30 days even when week one looks fine.

One more thing about the monitoring itself: in almost none of the documented cases did traffic dashboards raise the alarm. People found out through a drop in sales, a Merchant Center warning, or an idle look at a rankings tool on a Sunday. If you want to catch this, set an alert with a threshold rather than adding another chart somebody has to remember to open.

## What you will be told that the evidence does not support

Reading public post-mortems back to back turns up a second pattern: the advice people receive is more confident than the record justifies. Five claims recur, and each one falls apart against the threads where somebody posted a follow-up.

**"A dip is normal, it settles in a few weeks."** The most repeated line in migration threads, stated by different professionals with different numbers: four to eight weeks, a few weeks, a month or two. The largest dataset anyone has published on this says otherwise. A [study of 1,052 domain migrations](https://salt.agency/blog/27-of-domain-migrations-recover-in-90-days/) found a median recovery of 304 days and a mean of 489. Roughly one in four recovered inside 90 days, a little over half within a year, and 13.9% had not recovered after three years.

Read that with its caveat: migrations entered the sample by dropping more than 60% of traffic, so it describes bad migrations rather than all of them. That is the relevant comparison if yours went badly. Treat "it will settle" as a hypothesis that needs a diagnosis behind it.

The cost of believing the comfortable version is on the record. When the company behind Logojoy rebranded to Looka, its founder went in expecting a 20 to 30% dip recovering within three to six months, and [described that as the standard expectation he had been given](https://betakit.com/looka-lays-off-80-percent-of-staff-as-failed-rebrand-from-logojoy-cut-revenue-in-half/). Organic fell about 80%, organic was half of revenue, and revenue halved. The company laid off 32 of its 40 people. They had also restructured the site while changing the name, so nobody could isolate which decision did it.

**"Expect a 10 to 15% dip for two to four weeks."** A precise-sounding number with no measurement behind it, circulating from marketing guides into forums and back. Nobody produces the dataset. Use your own baseline instead of somebody else's rule of thumb.

**"301s pass everything, so redirects cannot be your problem."** The dangerous part of this claim is not whether it is technically right; it is that believing it makes people stop investigating redirects early, which is where the fixable damage usually is. Check your redirect map before you accept that redirects are ruled out.

**"Search Console shows all pages indexed and no errors, so the migration was clean."** The most misleading reassurance in the category, and it appears in case after case where traffic had collapsed. Search Console reports on URLs it knows about. The pages you deleted, the legacy archive URLs your old CMS generated, the product URLs whose structure changed silently on a platform upgrade: none of them exist to be reported.

The reassurance has a cousin worth knowing about too. Average position in Search Console is weighted by impressions, so a page can report position 1 on a handful of impressions while sitting far down the results for every query that used to bring traffic. A clean coverage report and a broken migration are compatible.

**"Google needs 180 days to process the move."** The 180 days is how long Google's Change of Address tool keeps forwarding signals, and how long you are advised to keep redirects live. It is a retention window, not a recovery clock, and it gets repeated as though waiting six months is the plan.

**A note on the sources you will find while researching this.** A large share of what ranks for "traffic dropped after redesign" is fabricated: first-person war stories with invented metrics, publication dates in the future, and narrative arcs too clean to be real. Several statistics that circulate widely in this niche, including precise-sounding claims about average percentage losses, trace back to nothing at all. Two of the most-repeated case-study numbers in the migration genre turn out to be misattributions that spread because nobody opened the original source. When you are diagnosing a real problem, check whether the thing you are about to act on has a dataset behind it.

Check the Google update calendar before you fix a launch date. In several of the strongest documented cases, the relaunch happened within days of a Google core update, and the resulting argument about cause was never resolved by anyone. If your launch window is flexible, check the update calendar first. Not because an update will hurt you, but because launching into one makes attribution permanently unrecoverable, and you will spend months unable to prove whether your own work or the algorithm moved the numbers.

## What agent-coded builds break that older checklists miss

Most redesign SEO checklists were written for a world where a developer hand-built pages from a design file. When the build layer is handled by coding agents, the design is human and the production is generated, and the failure modes shift in ways older lists never covered. We build this way ourselves, and these are the checks we added.

**Structured data disappears silently.** JSON-LD blocks are invisible in the design file and easy to omit in a rebuild, especially when porting between platforms. Article, FAQ, breadcrumb, and product markup do not survive a migration unless someone specifies them. A page that lost its FAQ schema keeps its rankings and loses the rich result that earned the clicks.

**Heading hierarchy gets restructured while the page looks identical.** An agent implementing a design will reproduce visual weight faithfully and may deliver a heading that looks like an H2 and is coded as a styled div. The screenshot matches; the document outline is gone.

**Content moves from HTML to client-side rendering.** Porting from a static or server-rendered platform to a framework configured for client rendering can put content behind JavaScript. Search engines handle this, though less reliably and more slowly than HTML in the initial response.

**Routing conventions change under the surface.** Trailing slashes, case sensitivity, and index-path handling differ between platforms. A migration that changes `/pricing` to `/pricing/` across the site generates redirects at best and duplicates at worst.

**Framework internals leak into what crawlers read.** Two documented cases show the shape. On a Next.js App Router site, the strings "404 Error" and "Page not found" were serialized into the payload of an unused slot on every page: invisible to visitors, present in the HTML the crawler parses, and flagged for exactly one URL in Search Console while traffic fell. On another site a script that branched on production versus staging relocated the meta robots directive out of the head and into the body during rendering, where it only appeared in the rendered HTML. Neither is a design mistake or a content mistake. Both are the build layer doing something nobody inspected.

**Server responses can differ for crawlers.** One site's adapter made nonexistent paths return a server error rather than a not-found, so `/robots.txt` read as unreachable instead of absent, and the whole site was dropped from the index. Impressions went from thousands a day to zero, and it went unnoticed for roughly three months while Search Console displayed the reason the entire time.

The check that catches all of these takes an hour: for ten pages from the protected set, fetch the rendered HTML of the old page and the new one and diff them. Not the screenshots, the source. Then request the same pages the way a crawler does, from the command line, and confirm the status codes match what a browser sees. Every failure above is visible in those two checks and invisible in a visual review.

Do not substitute Search Console's live test for this. It fetches the page fresh, on demand, which is a different operation from what the crawler did on its last real visit. There are documented cases where the live test rendered a page perfectly while the stored crawled version was missing its metadata and most of its content, and cases where a broken redirect returned correct headers to the inspection tool for months while quietly failing in production.

## If you already launched and the traffic dropped

**Confirm the traffic fell at all.** Before diagnosing anything, check that the drop appears in Search Console impressions and not only in your analytics. Analytics tags get lost during rebuilds, and a tag that survived on the homepage but nowhere else produces a chart that looks like a catastrophe and is a reporting bug. This costs five minutes and occasionally saves a month.

**Confirm the redesign is the cause.** Compare the start of the decline to the launch date, and check whether a known algorithm update landed in the same window. Redesign damage usually begins within days of launch and concentrates on pages whose URLs changed. A gradual sitewide decline that started before launch is a different problem.

**Check the catastrophic causes first, in this order:** the production `noindex` tag, `robots.txt`, canonical tags pointing at staging, and whether old URLs return 404 instead of redirecting. These four take an hour to rule out and account for most severe cases.

**Rebuild the old URL list even if nobody saved it.** Search Console retains historical data, the Internet Archive holds crawls of the old site, and backlink tools list URLs that external sites still point to. Between those three you can reconstruct enough of the inventory to fix the pages that mattered. The Internet Archive earns its place here for a second reason: comparing an archived page against its replacement is the fastest way to see whether the rebuild quietly removed content. That comparison is exactly how one small business owner learned that a designer had rebuilt her site with most of the written content gone and the homepage headings styled with CSS instead of marked up as headings.

**Fix in order of former traffic value.** Redirect the top pages first rather than working through the list alphabetically. Recovery is proportional to the value of what you restore, and the first ten redirects usually matter more than the next two hundred.

**Then wait, and change one thing at a time.** Recrawling takes weeks. Fixing five things simultaneously makes it impossible to learn which one worked, and the next redesign will repeat the mistake.

**Know your rollback threshold, ideally before you launch.** Reverting is a legitimate option and an underused one. When WooCommerce moved to a shorter domain and found it hurt discoverability, they moved back after five months rather than continuing to absorb the loss. Deciding in advance what result would make you revert, and by when, turns that from an admission of failure into a planned branch. Without a threshold, teams tend to keep waiting, because each additional month of waiting is cheaper than the decision.

## The short version

Migration is scoped work, not launch-day QA. Baseline before you design, inventory from four sources rather than one, map redirects one-to-one, protect the content that earns, verify the staging tags are gone, and watch Search Console for a month. The whole discipline costs a fraction of a redesign budget and prevents the failure that makes redesigns famous.

If you are scoping a project now, our [redesign pricing breakdown](/blog/website-redesign-cost) covers where migration sits in a realistic budget, the [RFP guide](/blog/website-redesign-rfp) covers how to write the scope so agencies price it rather than skip it, and the pipeline side of continuity — forms, CRM plumbing, live campaign pages — is in our [B2B redesign strategy](/blog/b2b-website-redesign). If you want this run properly on your site, [that's a conversation](/services/web-design).

---

### 10 Best Website Redesign Agencies in 2026 (Ranked on Migration Risk)
URL: https://www.themasterly.com/blog/top-website-redesign-agencies
Product Design · 2026-08-11

A third of marketers are unhappy with their last website redesign. That number comes from HubSpot's survey of more than 6,000 of its customers, and it is the reason this list exists in the form it does: redesigns rarely disappoint on visual quality. They disappoint because a site shipped and stopped earning what the old one earned.

A redesign agency inherits something a web design agency never touches. The site already works. It has pages that rank, forms wired into a CRM, campaigns pointing at live URLs, and a pipeline depending on all three surviving launch day. Shortlists get built by scanning portfolios, which shows you how an agency draws and tells you nothing about whether it can move a site without breaking what the site already earns.

This list ranks on that. We're Masterly, a design agency working with Series A–D B2B SaaS, fintech, healthtech, and AI companies, and we've included ourselves with the same criteria applied to everyone else. No padding the list with agencies we can't speak to, no omissions that make the landscape look cleaner than it is.

What this guide covers:

1. What separates a redesign agency from a web design agency
2. The four criteria we used, including the one question that filters fastest
3. Ten website redesign agencies in 2026, who each is best for, and what to expect on price
4. How to choose based on your situation, from a stalled Series A site to an enterprise replatform

## What separates a redesign agency from a web design agency

The distinction sounds like marketing until you watch a redesign go wrong. A new build has one failure mode: the site underperforms. A redesign has three more, and each one is invisible on launch day.

Changed URLs without a redirect map erode the rankings that justified the project, slowly enough over the following quarter that nobody connects the decline to the launch. Forms rebuilt without mapping the plumbing behind them deliver leads that arrive unattributed or route to nobody. Live campaign pages that a paid program still points at either survive, redirect cleanly, or bill you for clicks landing on a 404. We covered all three in detail in the [B2B redesign strategy guide](/blog/b2b-website-redesign); the short version is that continuity belongs in the scope document, not in launch-day QA.

Here is the awkward finding from researching this list: only three of these ten agencies market a dedicated website-redesign service page. Several of the strongest do the work without naming it, and one well-known SaaS design studio refuses website work outright while ranking for redesign queries because their product-redesign service shares the word. Searching for "redesign agency" therefore hides good options and surfaces marketing pages. Which is why the criteria below matter more than the label an agency puts on itself.

## How we evaluated this list

**Migration discipline, tested with one question.** Ask a shortlisted agency what their redirect-map process is. Teams that have run real migrations answer in specifics: URL inventory before design starts, one-to-one redirects, content parity on ranking pages, Search Console monitoring for the first month. Teams that have not will move the conversation to design quality. That exchange sorts a shortlist faster than a week of portfolio review, and it is the closest thing to a reliable filter in agency selection.

**Evidence of redesigns, not just builds.** We looked for named redesign work: case studies that describe an existing site being moved rather than a new one being launched. An agency whose portfolio is entirely greenfield builds may still do good work, but you are paying them to learn the failure modes on your migration.

**Verified Clutch reviews.** [Clutch](https://clutch.co/web-designers) is the most reliable source of verified B2B agency reviews. All ratings, review counts, minimum project sizes, and hourly rates below were pulled from live Clutch profiles in August 2026. Ratings drift, so check them again before you sign anything.

**Pricing transparency.** Agencies opaque about cost on first contact are optimizing for closing rather than for fit. One agency on this list publishes its own redesign range on its website; that is rare and worth rewarding with a place on your shortlist.

## Ten website redesign agencies in 2026

### 1. Masterly

**Best for: Series A to Series D B2B SaaS, fintech, healthtech, and AI companies redesigning after a repositioning**

Full disclosure: this is our list, and we're on it. We've applied the same criteria to ourselves that we applied to everyone else.

We're a design-led studio working with B2B SaaS, fintech, healthtech, and AI companies. Most redesigns we take on start with the same trigger: the company repositioned, moved upmarket, or closed a round, and the site still sells to the buyer they outgrew. That makes positioning the first deliverable and visual design the second. Across 40+ B2B SaaS products, client companies have raised $200M+ after our design engagements, and our UX work lifts trial-to-paid and lead-to-call conversion by an average of 38%. The work has earned Red Dot Design Award recognition.

Two things shape how we run redesigns. We design in Figma with senior designers and hand the build to coding agents for clients optimizing on price and speed, or to Webflow for clients who want a platform their marketing team already knows. And we ship page by page rather than in one launch: a recent scale-up engagement ran as seventeen page-level projects over three and a half months, each page live and measured while the next was in design. We're not the right fit for enterprise procurement cycles or projects where the site is a checkmark rather than a sales asset.

**Clutch:** 5.0/5 | **Pricing:** $4K–$16K/mo retainer, or fixed-scope projects | **Based:** EU (remote)

### 2. Huemor

**Best for: Post-MVP companies whose site still looks like the early days**

Huemor has the clearest redesign positioning of any agency we looked at. They run a dedicated website-redesign practice, and their copy names the trigger directly: a site that still belongs to your MVP days while the company has moved on. That specificity is unusual in a market where most agencies treat redesign as a variant of web design.

They also publish their own pricing, which almost nobody does. Most of their website rebuilds fall between $50,000 and $100,000 on a 12 to 16 week timeline, stated openly rather than qualified into meaninglessness. Their client list includes Shopify, Cloudinary, BetterCloud, and Mark43. Founded in 2011, team of 10 to 49, and they hold a W3C Award Gold for website redesign.

Worth knowing: their Clutch profile carries 72 reviews at 4.8, the most redesign-specific review volume in this list.

**Clutch:** 4.8/5 (72 reviews) | **Pricing:** $25,000+ minimum, $150–199/hr | **Based:** Pittsburgh, PA

### 3. Orbit Media Studios

**Best for: Content-heavy B2B sites where organic traffic is the asset being protected**

Orbit Media has been building and rebuilding sites from Chicago since 2001, with roughly 57 people and no outsourcing. For a redesign where the primary risk is losing hard-won organic rankings, that combination of longevity and in-house delivery is the relevant signal.

They also publish original research on the exact question buyers of this service ask, which is how often a site should be rebuilt. Tracking 50 top marketing brands through the Internet Archive, they found an average of two years and one month between redesigns; across 78 of their own client sites, the average was six years and four months. The gap is the interesting part, and it is a more honest answer to "how often should we redesign" than most agencies will give you, since the second number represents sites that did not need rebuilding as often.

Their own estimate for a full redesign project is 10 to 30 or more weeks. At a $50,000 minimum they are not the budget option, and their strongest fit is a site where content volume and search performance are the reason the project exists.

**Clutch:** 5.0/5 (36 reviews) | **Pricing:** $50,000+ minimum, $150–199/hr | **Based:** Chicago, IL

### 4. Bop Design

**Best for: B2B companies that want an agency doing nothing else**

Bop Design carries the strongest combination of rating and review volume in this list: 5.0 across 127 verified Clutch reviews. Their positioning is equally unambiguous. Their homepage says "B2B. It's all we do," and their industry page states they have worked exclusively with B2B brands for more than a decade. For a category where most agencies claim every vertical, a consistent exclusion is a real signal.

Their redesign evidence is a case study rather than a service page. The Opus 2 engagement reports sessions up 25%, new users up 34%, and direct search sessions up 58%. That is the kind of outcome reporting worth asking every agency for, and few produce it. They also run a 30-day post-launch monitoring period, which addresses the failure mode this whole list is organized around.

The caveat is structural: with no dedicated redesign page, you will need to raise migration explicitly in the first conversation rather than assume it is scoped.

**Clutch:** 5.0/5 (127 reviews) | **Pricing:** $25,000+ minimum, $150–199/hr | **Based:** San Diego, CA

### 5. Ramotion

**Best for: Brand-led redesigns where the identity changes alongside the site**

Ramotion answers the redesign question more directly than anyone else here. Their web design page states they can redesign an existing site or improve selected parts of it, and they answer "can you redesign my existing website" as a standing question rather than a special case. A separate brand page lists end-to-end website redesign as its own line of work.

The verified work supports the brand-plus-web positioning: Firefox brand identity, and a separate Mozilla Labs website redesign. If your redesign is downstream of a rebrand, an agency that runs both without handing off between two vendors removes a coordination risk that shows up in most rebrand-plus-redesign timelines.

One distinction to hold onto when you talk to them: they run a separate product-redesign practice for applications, priced and scoped differently from website work. Make sure the conversation is about the one you need.

**Clutch:** 4.9/5 (29 reviews) | **Pricing:** $50,000+ minimum, $150–199/hr | **Based:** San Francisco, CA

### 6. Lounge Lizard

**Best for: Buyers who want a documented process more than a design point of view**

Lounge Lizard has been running since 1998, which makes them the oldest agency on this list by a decade. They market a dedicated redesign service built around a named eight-step process, from kick-off and rebranding through prototyping, design, content, development, testing, and launch, with Imagine Software as a named redesign case study.

A documented process is worth something specific in a redesign: it means the sequence is decided before your project starts rather than improvised around it. It also tends to correlate with a larger team and a more structured, slower engagement, which fits organizations with multiple stakeholders and suits fast-moving startups less well.

They serve B2B and SaaS but also run a B2C practice, so specialization is broader here than with Bop Design or the SaaS-focused studios. Their hourly rate is undisclosed on Clutch, so pricing conversations start from scratch.

**Clutch:** 4.8/5 (43 reviews) | **Pricing:** $25,000+ minimum, hourly undisclosed | **Based:** New York, NY

### 7. Clay

**Best for: Well-funded companies where the redesign has to clear a high aesthetic bar**

Clay is a San Francisco studio operating at the intersection of brand, product design, and front-end development, and their client list sets both the quality ceiling and the price floor: Slack, Google, ADP, VMware, Okta, Splunk. They built Slack's interactive demo experience and worked with Google on Project Jacquard.

Redesign is demonstrated rather than merchandised. It appears nowhere in their service list, but their portfolio labels it plainly: a web redesign for the world's largest crypto asset manager, Grayscale, and one for the payables automation platform Tipalti. B2B and enterprise software is a named industry category for them, so the work sits in their lane even though the word is not in their navigation.

Their Clutch sub-ratings tell you what to expect: quality 4.8, schedule 4.7, cost 4.5. That last number is the honest one. This is not a Series A engagement.

**Clutch:** 4.8/5 (32 reviews) | **Pricing:** $50,000+ minimum, $150–199/hr | **Based:** San Francisco, CA

### 8. DD.NYC

**Best for: Consumer-facing brands with volume requirements and a New York preference**

DD.NYC carries 104 Clutch reviews at 5.0, the second-largest verified review base here, and a client list that skews recognizable: Match Group brands including Tinder and Hinge, plus VTS and Forbes. Web design is their largest recorded service line at roughly half their work, and they ranked #58 on the Inc. 5000.

Two things to weigh. Their own web design page frames engagements as new builds rather than redesigns, and states that they never start from a theme or a previous website design, so migration continuity is something you would need to introduce into the scope rather than expect in it. And Clutch's aggregate review analysis flags that about a quarter of their reviews mention communication issues or project delays. High ratings and consistent process notes can coexist; both are worth reading before you commit.

**Clutch:** 5.0/5 (104 reviews) | **Pricing:** $10,000+ minimum, $150–199/hr | **Based:** New York, NY

### 9. Excited

**Best for: B2B SaaS teams with a real budget ceiling**

Excited is the most affordable option on this list that still holds a 5.0 Clutch rating, at 55 reviews and a $50–99 hourly band. Their positioning is B2B and SaaS website design, including a line most agencies avoid putting in writing: that a redesign may be more affordable than a full build. Clients include XILO, ClubReady, InsuredMine, and Timeero.

The caveat is where their revenue comes from. Their Clutch service breakdown is 90% UX/UI and 10% web design, so websites are a minority of recorded work despite the redesign-forward marketing. That does not make the work weak, but it does mean you should ask for redesign case studies specifically rather than portfolio work in general.

**Clutch:** 5.0/5 (55 reviews) | **Pricing:** $10,000+ minimum, $50–99/hr | **Based:** Lviv, Ukraine

### 10. Fireart Studio

**Best for: Redesigns where the build is the hard part**

Fireart works from Warsaw with 50 to 249 people and a client list that includes Rolls-Royce, Google, Crunchbase, Pipedrive, and Bolt. At a $10,000 minimum and a $50–99 hourly band, they sit at the accessible end of this list while carrying a 4.9 rating across 40 reviews.

Their profile is different from every other agency here in one way worth understanding: roughly 65% of their recorded Clutch work is engineering rather than design. If your redesign is technically demanding, a replatform with integrations or a custom CMS, that ratio is an advantage. If the hard part of your project is positioning and messaging, a design-led studio will serve you better. Redesign appears on their site as an FAQ answer rather than a service, which reinforces the same read.

**Clutch:** 4.9/5 (40 reviews) | **Pricing:** $10,000+ minimum, $50–99/hr | **Based:** Warsaw, Poland

## How to choose based on your situation

**Your site stopped matching how you sell.** You repositioned, moved upmarket, or closed a round, and the messaging contradicts the sales motion. Positioning is the deliverable and design is downstream of it. Look for agencies that lead the conversation with your buyer rather than your layout: Masterly, Huemor, or Ramotion if a rebrand is in scope.

**You have organic traffic to protect.** Content-heavy site, real rankings, a pipeline fed by search. Migration discipline outranks everything else, and the redirect-map question should be the first one you ask. Orbit Media and Bop Design both structure around this, and Bop's 30-day post-launch monitoring is the kind of commitment worth asking others to match.

**You need a replatform, not a reskin.** Marketing cannot ship a page without an engineer, and the real deliverable is a [design system](/glossary/design-system) plus the platform carrying it. Engineering depth matters more than art direction: Fireart at the accessible end, Clay at the premium one.

**Your budget has a hard ceiling.** Excited, DD.NYC, and Fireart all start at a $10,000 minimum on Clutch. Below that number you are buying a template refresh rather than a redesign, and the honest move is to run a [UX audit](/blog/ux-audit-guide) first: it costs a fraction of a rebuild and often finds that two pages, not the whole site, are the leak.

**You are running a formal selection.** Write the brief before you contact anyone. Our [RFP guide](/blog/website-redesign-rfp) covers the eight sections that get strong agencies to respond, and the single biggest lever is naming a budget range so the right tier self-selects in.

One timing note from our keyword data: search demand for redesign agencies peaks in September, when next year's budgets get planned. Everyone scopes at once and calendars fill. Scoping in summer means you pick your shortlist; scoping in Q4 means you pick from whoever has capacity left.

## How to find more agencies

This list covers ten agencies we can speak to at the time of writing. The market moves: agencies narrow their specialization, change pricing models, or get acquired.

[BrowseHub](https://browsehub.co) maintains a curated directory of vetted design agencies with filtering by specialization, pricing, and location, which is a useful starting point for comparison beyond this list.

For verified review data, [Clutch's web design rankings](https://clutch.co/web-designers) remain the most reliable source: client reviews, project sizes, hourly rates, and industry focus in one place. Every number in this article came from there, and every number will drift.

## What matters at the end

Redesign selection goes wrong in a predictable way. Buyers evaluate on portfolio because portfolio is easy to evaluate, then discover after launch that the thing they needed was migration discipline, which no portfolio displays.

The research behind this list found something worth repeating: [Clutch's 2025 survey of 406 US small business owners](https://clutch.co/resources/state-of-small-business-websites-2025) found 90% planning to invest in their website within the next twelve months. A lot of money is about to move through this category, and [a third of the marketers who spent it last time were unhappy with the result](https://blog.hubspot.com/marketing/website-redesign-timelines).

Ask the redirect question first. If you know what you need and want to talk scope, [we're here](/services/web-design).

---

### B2B Website Redesign: A Strategy That Protects Your Pipeline
URL: https://www.themasterly.com/blog/b2b-website-redesign
Product Design · 2026-08-07

A B2B website ages in a specific way: the company repositions, moves upmarket, closes a funding round, and the site keeps selling to the buyer you had two years ago. Nothing looks broken. The pipeline just gets quieter, and everyone blames the market until someone opens the homepage and reads it the way a prospect would.

We redesign B2B sites for SaaS and fintech companies, and this guide is the strategy we run: when a redesign is justified, what breaks pipelines mid-migration, and the sequence that protects revenue while the site changes under it.

What this guide covers:

1. Why the site carries most of your sales motion now, with the numbers
2. The five triggers that justify a B2B redesign, from real client work
3. The three places redesigns break pipelines, and the scope lines that prevent it
4. The sequence: audit, positioning, design system, phased rollout
5. Budget and timing by stage, including why fall is the wrong time to start scoping

## The Site Carries the Sales Motion Now

A B2B website redesign is a revenue project because the website does most of the selling. [Gartner's buying-journey research](https://www.gartner.com/en/sales/insights/b2b-buying-journey) puts time spent meeting with all potential suppliers combined at roughly 17% of the total buying process, which leaves 5–6% for any single rep, and by 2026 [67% of B2B buyers prefer a rep-free experience](https://www.gartner.com/en/newsroom/press-releases/2026-03-09-gartner-sales-survey-finds-67-percent-of-b2b-buyers-prefer-a-rep-free-experience) for at least part of the purchase. The evaluation your sales team used to run in discovery calls now happens on your pricing page, at midnight, without you.

The B2B twist is who's reading. The visitor is a committee wearing one browser: a champion who has to sell you internally, a researcher assembling a vendor shortlist who has no authority to book anything, an executive who will skim exactly one page. [McKinsey's B2B Pulse](https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/b2b-pulse) tracks buyers moving across ten or more channels in a single purchase, and the website is where those channels reconcile: the place that either survives a fifty-tab comparison or quietly loses it.

That framing changes what "redesign" means. The project rebuilds the argument your best rep would make, for a reader who never books the call. We tore down how the strongest B2B sites make that argument in our [B2B SaaS website teardown](/blog/b2b-saas-website-design); this guide covers what to do when yours no longer makes it.

## The Five Triggers That Justify a Redesign

"The site looks dated" is not on this list. Dated-but-converting is a refresh at most. These five come from the client work in our own tracker, and each one changes what the redesign must deliver.

**1. You repositioned, and the site didn't.** The most common trigger by far: a funding round, an upmarket move, a category change, and the site still sells to the buyer you outgrew. Messaging, proof, and pricing pages contradict the sales motion. This is the redesign where positioning work leads and design follows; skipping to visuals rebuilds the wrong argument faster. It's also the stage-change pattern we covered in [SaaS design mistakes at Series A](/blog/series-a-saas-design-mistakes): the most expensive site is the right site for the wrong stage.

**2. New marketing leadership arrived.** A new CMO or Head of Marketing inherits a site built for a predecessor's strategy, and an overhaul lands in the first-hundred-days plan. This trigger is legitimate; the risk is scope. A leadership-driven redesign wants to change everything at once: brand, message, stack. Sequence it instead: message first, brand as its own budgeted project, replatform only if velocity demands it.

**3. Conversion declines while traffic holds.** Rankings are fine, sessions are flat or growing, demo requests sink. Something between arrival and form-submit is broken, and a redesign may fix it, or a [UX audit](/blog/ux-audit-guide) may find that one pricing-page decision, not the whole site, is the leak. Audit before you rebuild: it costs a tenth of a redesign and tells you whether a redesign is the right fix.

**4. The team can't ship pages.** Every new landing page needs an engineer, every campaign waits two sprints, and marketing runs its program at the speed of the deploy queue. Here the real deliverable is a [design system](/glossary/design-system) marketing can publish on without engineering, plus the replatform that carries it. The launch is just the system's first proof.

**5. The brand outgrew the site.** Rebrands force site changes, and companies bundle them to save time. Keep the budgets separate even when the timelines touch: a rebrand is identity work, a redesign is conversion work, and folding "light rebrand" into a redesign quote underprices one of the two; we covered why in the [pricing breakdown](/blog/website-redesign-cost).

> The redesigns that fail rarely fail on design. They fail on a trigger nobody named, so the team polishes visuals while the pipeline needed positioning, velocity, or migration discipline.

## The Three Places Redesigns Break Pipelines

Every trigger above justifies change; change is what breaks running systems. Three failure points account for most of the revenue damage we see in inherited projects, and none of them appear in a typical brief.

**Organic rankings.** Changed URLs without a redirect map, dropped pages that ranked, content parity ignored. The traffic that justified the redesign erodes over the following quarter, slowly enough that nobody connects it to the launch. The discipline is boring and non-negotiable: full URL inventory before design starts, a redirect map for every changed URL, content parity on ranking pages, pre- and post-launch monitoring in Search Console. If a proposal doesn't mention redirects, the price is lower and the risk is yours.

**Form-to-CRM plumbing.** B2B sites are wired into revenue infrastructure in ways B2C sites aren't: field mappings, hidden attribution values, lead routing, enrichment, scoring. A redesign that rebuilds forms without mapping that plumbing delivers leads that arrive unattributed, route to nobody, or vanish. Attribution continuity deserves its own scope line and an end-to-end test before cutover: submit a test lead through every form and follow it into the CRM.

**Live campaign pages.** Paid traffic doesn't pause for your migration. Every landing page a campaign points at either survives the redesign, redirects cleanly, or bills you for clicks that land on a 404. Inventory campaign destinations the way you inventory rankings, and keep PPC landers on the old system until their replacements are proven if you have to.

The common thread: continuity belongs in the scope document. Priced and planned, it's a modest line item. Discovered in the post-launch retro, it's a quarter of pipeline.

## The Sequence That Protects Revenue

**Audit first.** One to two weeks against the site you have: what ranks, what converts, what the buying committee reads, where evaluators bounce. The audit output is the redesign's scope, and sometimes its cancellation, when the fix turns out to be messaging on two pages.

**Positioning before pixels.** The one-sentence answer to "what is this and who is it for," the proof hierarchy, the pricing-page argument. This is the judgment work that survives every future reskin, and the part AI tools cannot do for you.

**A system, not a set of pages.** Design the template system marketing will ship on, not a fixed set of layouts. Count unique templates; they drive cost and velocity. The goal state: a new landing page is a content task, not an engineering ticket.

**Phased rollout over big-bang launch.** Ship page by page, highest-impact first, measuring as you go. One real engagement from our tracker: a scale-up client's site rebuilt as seventeen page-level projects over 3.5 months at roughly $8K a month, each page live, measured, and earning while the next was in design. A big-bang launch bets every ranking, form, and campaign on one deploy; a phased one keeps each bet small enough to reverse. The full economics of that engagement are in the [pricing breakdown](/blog/website-redesign-cost).

## Budget and Timing by Stage

Budget follows the effort your stage requires, not agency rate cards; the full framework with receipts lives in our [redesign pricing guide](/blog/website-redesign-cost). The short version: Series A around $5–12K for sharp positioning on a handful of templates; Series B–C at $15–40K where SEO migration and a marketing-editable design system are justified; Series D into replatform territory where the design system is the real deliverable. If you're preparing to run a selection process, our [RFP guide](/blog/website-redesign-rfp) covers how to scope the document so strong agencies respond.

One timing note from our own keyword data: search demand for B2B website redesigns roughly triples in early fall, when next year's budgets get planned. Everyone scopes at once, agency calendars fill, and Q4 becomes the season of rushed selections. Scoping in late summer means you choose your shortlist; scoping in October means you choose from who's left.

If a trigger on this list is yours and you want a second opinion on whether it justifies a rebuild, [that's a 30-minute conversation](/services/product-redesign). We'll tell you which trigger you're facing. And if the honest answer is an audit and two rewritten pages, you'll hear that instead.

---

### Website Redesign Prices in 2026: What Agencies Charge Now
URL: https://www.themasterly.com/blog/website-redesign-cost
Product Design · 2026-08-07

Ask five agencies what a website redesign costs and you'll get a range wide enough to be useless: $2,500 from a freelancer marketplace, $150,000 from an enterprise shop, and three quotes in between that describe different projects with the same word. In 2026 that spread hides a repricing the industry would rather not discuss.

AI collapsed the cost of producing a website. Most agency price lists haven't noticed yet. And the question itself needs fixing: agencies don't set the number in the first place. The effort your stage requires sets it. A $4,000 site is the *correct* purchase at seed, a $30,000 site is the correct purchase at Series C, and buying either one at the other stage is the real overpayment. We redesign and build sites for B2B SaaS and fintech companies with an AI-assisted pipeline ourselves, so this guide does both jobs: separates what agencies still charge from what the work takes now, and shows how to scope the effort to your stage.

Here's what this guide covers:

1. The two price lists of 2026: what's still quoted vs. what the work takes now
2. What AI changed about redesign cost, and what it didn't touch
3. The honest effort tiers, from AI builders to replatforms, and which stage each fits
4. The four pricing models and when each one works for you, not the vendor
5. Scoping by stage, pre-seed to Series D

## The Two Price Lists of 2026

A marketing-site redesign is still quoted at $15,000–$60,000 by most full-service agencies. A specialized team that designs in Figma and lets coding agents do the build delivers the same scope for roughly $5,000–$20,000, in two to four weeks instead of two to four months. Both numbers are real. Only one reflects how teams produce the work now.

The first number is easy to verify: on [Clutch](https://clutch.co/agencies/ui-ux/pricing), specialized UI/UX agencies list rates that mostly land between $100 and $250 per hour, and a traditional six-to-twelve-week process at those rates lands in that $15K–$60K band. General-purpose guides like [Forbes'](https://www.forbes.com/advisor/business/software/how-much-does-a-website-cost/) still print ranges up to $150,000. Agencies built these prices for a world where teams hand-produced every page: designers handed files to developers, developers hand-wrote markup, QA took weeks.

That world ended. Design still happens in Figma, but the production layer (build, responsive states, CMS wiring, iteration) is now AI-generated code reviewed by seniors. When the hours collapse, either the price follows or the margin doubles. A lot of 2026 quotes are the old hours at the old rates for work that no longer takes the old time.

> "In 2026 you should be suspicious of a redesign quote in both directions: too cheap means no one did the thinking, too expensive means someone's billing you for hours AI already deleted."
> — Vlad Hrynchuk, Co-Founder of Masterly

## What AI Changed, and What It Didn't

AI moved the cost of a redesign from execution to judgment; every honest price on the market follows from that.

**What got cheap:** production. Turning approved designs into a live, responsive, CMS-connected site used to be the largest line item; it's now days of agent-coded work with senior review. Template variants, breakpoints, boilerplate sections, first-draft copy: near-free. The two-to-four-week timeline is the process without the padding, not a rush job. When we took Alterscope, a real-time risk analytics platform, from alpha to investor-ready, it took three weeks. That speed comes from the pipeline, not from heroics.

**What didn't get cheap:** the parts AI is bad at, which are the parts that make a redesign worth doing. Positioning: what this company is, for whom, in one sentence. Conversion judgment: which pages earn the demo, what a buying committee needs, why evaluators bounce from pricing. Taste: the difference between a site that looks like your company and a site that looks like this month's template. And accumulated [design debt](/glossary/design-debt): AI rebuilds your inconsistencies faster than ever; deciding what the system *should* be is still human work.

**What got worse:** sameness. AI builders produce the statistical average of every landing page they've seen, so default output converges: same hero rhythm, same section order, same gradients. When any competitor can generate a competent site in a day, "competent" stops being a differentiator. Sameness also costs you in places no analytics dashboard tracks. Founders we work with have heard it from investors verbatim: *the brand doesn't look like a brand that deserves the money.* No deck slide answers that objection. Distinctiveness was the premium tier; now it's what you're buying. (We tore down what distinctive looks like in [B2B SaaS website design](/blog/b2b-saas-website-design), and none of it comes out of a prompt.)

## The Honest Price Tiers

Read the table as effort levels, not as an agency menu. Each level is *correct* at a different company stage:

| Tier | What's actually in scope | Honest 2026 price | Timeline | Right stage |
| --- | --- | --- | --- | --- |
| AI builder / template | You + an AI site builder; generic but live | $0–$3,000 | Days | Pre-seed |
| AI-assisted redesign | Human design in Figma (positioning, 5–12 unique templates), agent-coded build, migration | $3,000–$20,000 | 2–4 weeks | Seed → Series A |
| Replatform + design system | New stack, full site [design system](/glossary/design-system), content and SEO migration, motion | $30,000–$80,000 | 6–10 weeks | Series B–D |
| Legacy full-service process | The middle two tiers, produced the 2019 way | $50,000–$150,000+ | 3–6 months | Enterprise procurement |

One definition, because "AI-assisted" carries the whole table. Done right, it means the design is human (positioning, the template system, every screen decided in Figma by a designer) and coding agents do the *build* instead of a developer, with the designer reviewing every page against the Figma source. Our own site is made this way: the same Figma design we always had, implemented by Claude on a modern stack instead of hand-built in a site builder. Prompting a website into existence is a different thing: that's tier one wearing a bigger invoice. The boundary: this economics applies to marketing sites and landing pages. A web application (authenticated flows, state, data, security) still needs real engineers on the build; vibe-coding your product is how you buy the same project twice.

Three honest notes on the table. The first tier is fine in survival mode, and founders in it know what they're doing. A seed-stage founder we've worked with rebuilt his site as AI-generated code in a weekend this year, and his defense was airtight: at this stage the website is a checkmark. Done, enough for this phase, every spare hour goes to revenue. He's right, for as long as the site's job is holding information for people who already know him. The tier stops working the day the site has to convince strangers with money (enterprise buyers, banks, investors), because that's when sameness starts reading as interchangeability. The checkmark test is worth stealing: if your site is a checkmark, spend nothing; if it's a sales asset, spend on judgment.

The last tier isn't a ripoff in every case either: enterprises with procurement, compliance review, and twelve stakeholders are partly buying process, and process is what those agencies sell. But if you're a Series A–D company paying tier-four prices for tier-two scope, you're subsidizing someone's unwillingness to update their pipeline.

"Trust our table" is what agencies say, so here are receipts from our own time tracker. Over the last 3.5 months we rebuilt the full marketing site of one scale-up B2B SaaS client: seventeen page-level projects shipped one by one, from the main landing page through customers, product pages, resources, competitor pages, and a glossary built for SEO and AI search. The totals: roughly 600 logged hours, 68% design and 32% build, just under $28,000, averaging around $8K a month, inside the retainer band below. The landing page alone, the deepest single piece, took 184 hours. A legacy full-service quote for the same seventeen-page scope starts at roughly triple that. And the 32% build share is the part collapsing next: that engagement still shipped on hand-built production; the model this article describes hands those hours to coding agents.

Our own position: Masterly works in the middle two tiers, with the design always done in Figma by senior designers, and two build tracks behind it. For clients optimizing for price and speed, coding agents do the build, and the people who designed each screen review it. For clients who want the conservative route, a platform their marketing team already knows with a decade of tooling behind it, we still build on Webflow. Same design either way; the build track changes the price, not the quality of the thinking. Fixed-scope for defined redesigns, or a $4K–$16K/month [retainer](/glossary/design-retainer) when the site keeps shipping after launch.

## What Still Moves the Price

With production cheap, judgment-heavy scope drives the quote. Reading a proposal in 2026 means checking these five lines:

**Unique templates, not pages.** A 40-page site built from six templates is a smaller design problem than a 12-page site of bespoke layouts. Production per template collapsed; design thinking per template didn't. Count the templates, not the pages.

**Design system: extend or build.** If your site runs on a coherent system, a redesign extends it cheaply. If every page is a hand-crafted exception, someone has to decide what the system should be before AI can build it. Named and scoped, that's the honest core of the budget. Unnamed, it's why the "simple" quote doubled by revision three.

**Positioning and copy.** Who decides what the site says? AI drafts copy for free; it can't decide your one-sentence answer to "what is this and why should I care." If the agency includes messaging strategy, that's judgment work priced as judgment work, and usually the best money in the project. "Client provides copy" is still the most expensive four-word sentence in a redesign contract, because waiting, not writing, kills timelines.

**SEO migration.** Change URLs without a redirect map and you erase the traffic that justified the redesign. Migration discipline (URL inventory, redirect map, content parity, pre/post monitoring) costs the same as it did before AI, which now makes it one of the larger honest line items. If it's missing from the quote, the risk is yours. If you're unsure the structure needs changing at all, a [UX audit](/blog/ux-audit-guide) answers that for a tenth of a redesign's price.

**Motion and interactive.** Scroll narrative, interactive product demos, calculators: still real engineering, still priced accordingly, still the easiest scope to phase in after launch.

One thing is missing from this list on purpose: brand identity. A rebrand (logo, [brand identity](/glossary/brand-identity), voice) is its own project with its own budget, and folding "light rebrand" into a redesign quote underprices one of the two.

## The Four Pricing Models, and Who Each One Protects

**Fixed-scope project.** One price, one deliverable, one launch. The default for a defined redesign, and the discipline it forces (writing scope down) is half its value. In the AI era it has a second virtue: a team confident in its pipeline can afford to fix the price, because production risk is low. Vagueness about scope now signals process risk, not flexibility.

**Retainer.** A monthly engagement, $4K–$16K/month at the specialized tier, where the redesign is phase one and the site keeps evolving: landing pages, experiments, repositioning as the company changes. Under the hood a retainer is usually a monthly block of tracked hours — what makes it different from raw hourly is the cap, the standing team, and a scope conversation every month instead of a meter running in the background. If you'd ship meaningful design work every month anyway, a retainer beats serial projects on price and context. If the site will sit untouched for a year, don't pay for a standing team.

**Open-ended hourly.** All scope risk sits with you, and in 2026 it has a new problem: on an opaque invoice, AI-assisted hours and manual hours bill the same. The issue isn't hours themselves — our own retainers are billed against tracked hours, and the receipts above come straight from that tracker, design/build split included. The red flag is the uncapped, unitemized meter: no monthly cap, no visibility into what the hours produced. Fine for small unpredictable engagements; as the primary model for a redesign, it's how you pay 2019 hours at 2026 speed.

**In-house.** A senior product designer runs $130K–$180K+ a year before you've hired anyone to build. Right when the marketing site is core product surface; overkill for twelve templates and a launch. Most Series A–C companies we work with land on agency-for-the-redesign, retainer-or-in-house for what comes after. (How that decision shifts by stage: [SaaS design mistakes at Series A](/blog/series-a-saas-design-mistakes).)

## How to Scope a Redesign by Stage

The right budget doesn't come from comparing agency rates. It comes from an honest answer to one question: what effort does the site's job require *at this stage*? The job changes as the company does, so the correct spend changes too, in both directions. What scale needs is irrelevant early; what's fine early is negligent at scale.

**Pre-seed and seed:** the site's job is to exist and not embarrass you: hold the one-liner, the proof you have, a way to book a call. A $3–5K site is the correct purchase: a few templates designed by a human, agent-built, shipped in days. Buying a design system, motion, or a content platform here is scale-stage scope dragged into a stage that doesn't need it, money that should have gone into finding product-market fit. The founders who treat the site as a checkmark at this stage are right.

**Series A:** the site starts earning first meetings from strangers, and credibility becomes a conversion factor. $5K–$12K: 5–8 templates, sharp positioning, real proof. Skip motion, skip the replatform; spend the savings on messaging, because that's the part AI-era competitors also skipped.

**Series B–C:** now the site is a pipeline channel with real traffic to protect, a team shipping pages monthly, and buyers who compare you against category leaders. $15K–$40K is justified effort here: SEO migration, a design system marketing can ship on without engineers, distinctiveness that survives a fifty-tab evaluation. The seventeen-page rebuild above is what that looks like in practice, page by page, at ~$8K a month instead of one $80K invoice. Running a B–C company on a seed-stage checkmark site is the mirror-image mistake of the over-bought seed site. It costs more, because now the site has a revenue number attached.

**Series D and later:** the site is infrastructure: multiple audiences, localization, a team publishing weekly. Replatform tier; the design system is the real deliverable and the launch design is its first proof.

At every stage the same test applies: price the redesign against what the site is supposed to produce. A site that books demos for a $50K-ACV product pays for a $20,000 redesign with a fraction of one incremental customer; a pre-revenue site produces nothing yet, which is why $4K is its ceiling. If the math doesn't close at your deal size, stop and ask whether the redesign is the constraint at all. McKinsey's [Business Value of Design](https://www.mckinsey.com/capabilities/mckinsey-design/our-insights/the-business-value-of-design) research tied design leadership to revenue outperformance long before AI; what changed is that the entry price for that leverage dropped by half, for the companies that scope by stage instead of paying 2019 prices.

If you're comparing teams right now, directories like [BrowseHub](https://browsehub.co) let you filter design agencies by specialization, pricing, and location. Worth checking who prices like it's 2026.

If you want real numbers against your scope (page count, stack, deadline), [that's a 30-minute conversation](/services/product-redesign). We'll tell you which tier you're in, what we'd cut, and if the honest answer is "you need an audit, not a redesign," we'll tell you that too.

---

### How to Write a Website Redesign RFP That Good Agencies Answer
URL: https://www.themasterly.com/blog/website-redesign-rfp
Product Design · 2026-08-07

An agency owner judges your RFP faster than you judged your website: opens it, scans for three numbers, and decides in minutes whether responding is worth a week of unpaid proposal work. Most RFPs fail that scan. The agencies you wanted send a polite pass, the agencies with nothing better to do respond, and the selection is over before the first call.

We're a design agency, so we sit on the receiving side of these documents. This guide is the view from that side of the table: what we read first, what scares strong teams away, and the eight sections that make a redesign RFP easy to answer well, with a full annotated example you can copy.

What this guide covers:

1. The three things an agency checks before deciding to respond
2. The eight sections of an RFP that gets good answers
3. Red flags that make quality agencies pass on you
4. An annotated example RFP for a Series B SaaS company
5. Where to send it, and how many agencies to include

## What the Agency Checks First

An agency reads your RFP the way you read inbound sales email: looking for a reason to stop. Three checks happen in the first minutes.

**Is there a budget?** A proposal costs an agency days of senior time, so the first scan is for a number. No number means one of two things, and agencies have learned to assume the worse one: either you haven't decided what this is worth, or you're hoping competition drives the price down. Both readings push quality teams out. What you collect instead are bids priced to win, from teams planning to make it back on change orders once vague scope meets reality.

**Is the timeline sane?** A quality team reads "full redesign, six weeks, starting Monday" and passes, because everyone who could say yes to that is either overcommitted or planning to cut the thinking. Realistic anchors, from [our pricing breakdown](/blog/website-redesign-cost): two to four weeks of work for an AI-assisted marketing-site redesign, six to ten for a replatform with a [design system](/glossary/design-system), plus your own selection and content time on top.

**Is the scope real?** "We need a modern website" gives an agency nothing to price. Scope counted in unique templates (the unit that drives cost), a migration requirement, and a named accessibility standard tells the reader you've done the thinking. Agencies read an RFP without real scope as a fishing expedition and budget fishing-expedition effort for it. The waste runs at industry scale: Forrester estimates [$12.5 billion a year burned on dysfunctional agency reviews](https://www.forrester.com/blogs/dysfunctional-agency-review-ditch-the-pitch/).

> An RFP is a sales document: you're competing for the attention of the exact teams you want answering it.

## The Eight Sections That Get Good Answers

**1. About you.** Three sentences: what you sell, who buys it, stage and size. The agency uses this to judge fit, and fit judgments cut both ways: a shop whose portfolio is e-commerce should rule itself out on paragraph one.

**2. Why now.** The trigger, in plain terms: repositioned after a round, moving upmarket, conversion decline, replatforming. Agencies scope against the trigger. "Redesign because the site no longer matches how we sell" produces a better proposal than any page inventory.

**3. Goals, measured.** Two or three metrics with baselines: demo requests from organic, time-to-publish for new pages, traffic held through migration. Goals do double duty: they scope the work now and settle "did it work" later.

**4. Scope, in templates.** Count unique templates, not pages; a 40-page site on six templates is a smaller project than 12 bespoke pages. Say who writes copy ("client provides copy" is the most expensive four-word sentence in a redesign contract, because waiting kills timelines). Name the migration requirement: URL inventory, redirect map, content parity on ranking pages. Most RFPs skip that line, which is how redesigns [erase the traffic that justified them](/blog/website-redesign-cost). And name what's out: rebrand, product UI, app work.

**5. Technical constraints.** Current stack, target stack (or "open to proposal"), integrations, and the accessibility standard by name. Vague language becomes contractual: "modern, accessible design" means WCAG 2.2 AA to you and "looks current" to the vendor, and you'll discover the gap at the worst possible moment. Worth stating too whether you're open to an agent-coded build or want a conventional platform: the price difference is real, and [the honest tiers](/blog/website-redesign-cost) differ by stage.

**6. Budget, as a range.** The section most RFPs omit and the one that most changes who responds. A range ($15,000–$30,000 fixed-scope, say) lets the right tier self-select. If you can't name a number, describe the effort level and stage instead; our [scoping-by-stage framework](/blog/website-redesign-cost) exists for that conversation.

**7. Timeline with decision dates.** Response deadline (two weeks is fair), shortlist calls, decision date, target launch. Dates signal that a decision will happen; RFPs without them read as market research, and get market-research effort back.

**8. Selection process.** Who decides, by name and role. How many agencies got the document, and keep it under six: at twenty recipients, responding is a lottery ticket, and strong teams don't buy lottery tickets. What you'll evaluate, and what a response should contain. Then the line that earns goodwill with the exact teams you want: no spec work, no credentials theater, a pointed one-pager with questions beats a generic proposal.

## Red Flags That Make Good Agencies Pass

Reading RFP threads in agency communities is an education in how selection fails from the vendor side. The patterns that make strong teams close the tab:

**No budget, twenty bidders.** Covered above, and worth repeating as a pair, because together they turn your RFP into a numbers game that only content-mill shops can afford to play.

**Spec work requests.** Asking for "initial design concepts" with the proposal means asking professionals to work free. The teams that comply are the teams that couldn't win on their record.

**The 20-page AI-generated RFP.** A new genre in our inbox this year: documents past twenty pages, written by AI, and the tell is that nobody on the sending side has read them either. Section four contradicts section nine, the accessibility standard changes halfway through, and "what did you mean here?" on the first call gets silence. Twenty pages meant serious intent when writing them cost a week; now that generating them costs nothing, length signals the opposite. If you generate your RFP, at least read it before sending it. Please. Or skip the document entirely: [book a free discovery call](https://calendly.com/vlad-masterly/discovery-call) and we'll ask the necessary questions ourselves. That's what a first call is for.

**Committee syndrome in the document.** Seven stakeholders listed, no decision-maker named, evaluation criteria that read like a compromise. Agencies price decision risk the way insurers price flood zones; some walk away instead.

**"We'll know it when we see it."** An RFP that can't articulate goals forces the agency to guess what you want, and the experienced ones decline: a project that starts on a guess ends in a dispute. If you can't write section three yet, you don't need proposals; you need a [UX audit](/blog/ux-audit-guide) to find out what's broken before you commission the fix.

**The silent migration.** Nothing about redirects, analytics continuity, or rankings. The agency that notices and prices it looks more expensive than the one that ignored it; your RFP punished the better vendor. One scope line fixes the incentive.

## An Annotated Example

A compressed version of an RFP that would get our best response, for a fictional company. The right column explains the move each section makes.

| Section | What Northbeam Ops wrote | The move it makes |
| --- | --- | --- |
| About | Series B procurement platform for mid-market manufacturers; 120 people, ~$14M ARR. The site is our second pipeline channel after outbound. | Stage and traffic reality in two sentences; the agency reads the effort tier off paragraph one. |
| Why now | We repositioned upmarket; the site still sells to the SMB buyer we've outgrown. | The trigger, not a page list. Scopes the project better than any inventory. |
| Goals | Demo requests from organic +30% in two quarters (baseline 45/mo). New landing page live in days without engineering. Organic traffic within 5% of baseline through migration. | Baselines included; the third goal forces a migration plan without naming it. |
| Scope | Nine unique templates, 41 pages to migrate. Copy shared: we draft, you edit. Design system: build new, marketing-editable. Out of scope: rebrand, product UI. | Templates counted, copy ownership named, out-of-scope explicit. |
| Constraints | Currently WordPress; open on target stack, including an agent-coded build if you show the review process. WCAG 2.2 AA. HubSpot forms, GA4 continuity. | Standard named. Build track open, with a quality bar attached. |
| Budget | $20,000–$35,000 fixed-scope. | A range at the Series B tier; every reader knows on sight whether to respond. |
| Timeline | Responses in two weeks; calls the week after; decision five days later; launch within the quarter. | Dates that signal a real decision, not market research. |
| Process | Four agencies received this. Decision by VP Marketing + Head of Design. Evaluating: relevant B2B work, migration plan, your questions, price vs. scope. One-pager, two case studies, no spec work. | Few bidders, named deciders, permission to skip the theater. |

## Where to Send It

Copy the structure from the annotated example above: eight short sections, one page, every bracket answered. Writing it takes an afternoon, and most of that afternoon is the useful part: deciding scope before agencies decide it for you at change-order prices.

Where to send it: [Clutch](https://clutch.co/agencies/ui-ux) for verified reviews of UI/UX agencies, and [BrowseHub](https://browsehub.co), a curated directory of vetted design agencies with filtering by specialization, pricing, and location. Our own take on choosing among them is in the [SaaS design agencies list](/blog/top-saas-design-agencies). Keep the list under six, and say the number in the document.

A standing offer: if your RFP lands in our inbox with a budget range, a template count, and a migration line, you'll get our sharpest proposal, because those are the documents worth a week of senior time. If you'd rather skip the RFP and talk scope directly, [we're here](/services/web-design).

---

### Design Tokens: A Practical Guide to Naming, Tiers, and the Figma-to-Code Workflow
URL: https://www.themasterly.com/blog/design-tokens
Design Systems · 2026-07-30

Somewhere in your product right now, the same brand blue exists as a Figma style, three slightly different hex values in CSS, a Tailwind class, and an iOS asset — and at least one of them doesn't match. Design tokens exist to make that state impossible. They're the least glamorous part of a [design system](/glossary/design-system) and the part everything else depends on.

Here's what this guide covers:

1. What design tokens actually are — and why they're not just variables
2. The three-tier architecture: reference, semantic, component
3. Naming rules that survive rebrands, themes, and new platforms
4. The 2026 toolchain: Figma Variables, Tokens Studio, Style Dictionary, and the W3C format
5. The seven mistakes that kill token adoption — and when tokens are overkill

## What Design Tokens Actually Are

A [design token](/glossary/design-token) is a single design decision — a color, a spacing step, a type size, a corner radius, a shadow — stored as named data instead of hardcoded into a design file or a stylesheet. `color.action.primary: #2563EB` is a token. The hex value pasted into forty components is the absence of one.

The distinction that trips people up is tokens versus variables. A CSS variable, a Sass variable, a Figma variable — each is one *implementation* of a token on one platform. The token itself lives upstream: a named decision in a data file that gets transformed into whatever each platform needs. That's the whole idea, and it's why the term was coined where it was — at Salesforce, where Jina Anne and the Lightning Design System team needed the same design decisions to reach web, iOS, Android, and partner platforms without anyone re-typing hex values. Their open-source tool Theo was the first token build system, and every modern pipeline is downstream of it.

> "This was a way to store our visual information as data."
> — Jina Anne, who coined the term at Salesforce, [on the Smashing Podcast](https://www.smashingmagazine.com/2019/11/smashing-podcast-episode-3/)

Store decisions as data and three expensive problems collapse into cheap ones. A rebrand becomes a value change in one file instead of a quarter-long hunt through two codebases. Dark mode becomes a second set of values instead of a parallel stylesheet. And design–code drift — the slow divergence where production stops matching Figma — loses its mechanism, because both sides read from the same source.

## The Three-Tier Token Architecture

Token sets that survive growth are structured in tiers: reference tokens hold raw values, semantic tokens give them meaning, component tokens scope them to specific UI. Skipping the middle tier is the most common structural mistake; building the third tier too early is the second.

**Reference tokens** are your raw palette with no opinions attached: `blue.600: #2563EB`, `gray.100: #F3F4F6`, `space.4: 16px`. They answer "what values exist," never "where values go." This is the only tier where a name may describe a value.

**Semantic tokens** are where the system earns its keep. `color.action.primary: {blue.600}` — the token references a reference token and carries the meaning: this is the color of primary actions, wherever they appear. Theming happens entirely at this tier: dark mode is a second set of semantic values pointing at different references, and no component knows the difference. When your danger color changes from red to orange, `color.text.danger` doesn't change its name — only its target.

**Component tokens** scope decisions to a single component: `button.primary.background: {color.action.primary}`. They exist so that at scale, a team can restyle one component without touching the global vocabulary. [Material Design 3](https://m3.material.io/foundations/design-tokens/overview) runs this exact cascade in public — `md.ref` palette tokens feed `md.sys` system tokens feed `md.comp` component tokens — and it's the most complete worked example you can study for free.

How Material, Atlassian, and the other major public systems run tiers at ecosystem scale is a story we've already told in our [breakdown of twelve design system examples](/blog/design-system-examples). The practical takeaway for a product team is simpler: you need the first two tiers from day one, and you almost certainly don't need the third until multiple teams ship against the same components. Two tiers is a system; one tier is a palette; three tiers before Series C is usually ceremony.

## How to Name Design Tokens

Name tokens by purpose, never by value. This is the one rule that decides whether your token set is an asset or a renaming project waiting to happen — a token called `red-600` is a fact about today; a token called `color.text.danger` is a decision that survives every future.

| Decision | Value-named (fragile) | Purpose-named (survives) |
| --- | --- | --- |
| Primary button background | `blue-500` | `color.action.primary` |
| Error message text | `red-600` | `color.text.danger` |
| Card inner padding | `spacing-16` | `space.inset.md` |
| Modal shadow | `shadow-black-20` | `elevation.overlay` |

Beyond the one rule, four conventions keep a growing set coherent:

**Follow a consistent anatomy.** Most mature systems converge on something like `category.concept.property.state`: `color.background.danger`, `color.border.focused`, `space.inset.lg`. The exact segments matter less than never improvising them — a token vocabulary where every name parses the same way is one your team can guess correctly without opening the docs, and that guessability is what adoption actually feels like.

**Put states last.** `color.action.primary.hovered`, `.pressed`, `.disabled`. When states live at the end, tooling can group a token with its variants, and designers scanning an alphabetized list see families instead of fragments.

**Keep value words out of the semantic tier entirely.** The moment `blue` appears in a semantic token name, you've created a lie waiting to happen — the classic failure is a `gray-blue-2` that renders green after a rebrand. Value words belong in the reference tier and nowhere else.

**Keep names portable.** In the W3C token format, dots express hierarchy and curly braces express references, so keep individual name segments to plain lowercase words and pick one case convention for the whole set. Renaming tokens later is possible — Atlassian famously migrated thousands of values to semantic names with codemods — but it's a project. Naming them right is a meeting.

## The 2026 Toolchain: Figma Variables, Style Dictionary, and the W3C Format

The token toolchain has consolidated into three layers: Figma Variables where designers work, a version-controlled token file as the source of record, and Style Dictionary as the build step that turns one source into every platform's format. Five years ago this was a zoo of custom scripts; today it's close to a standard stack.

**[Figma Variables](https://help.figma.com/hc/en-us/articles/15339657135383-Guide-to-variables-in-Figma)** are the design-side implementation of tokens: reusable values in four types (color, number, string, boolean), organized into collections, with aliasing so a semantic variable can reference a palette variable — your tier structure, native in the design tool. Modes are the theming mechanism: one variable, multiple definitions, so a frame flips from light to dark without duplicating a single screen. Two practical notes: publishing variables to team libraries requires a paid plan, and adoption is no longer the question it was — [Supernova's State of Design Tokens report](https://www.supernova.io/state-of-design-tokens) found 69.8% of design teams already working with Figma Variables.

**[Tokens Studio](https://docs.tokens.studio/)** is the Figma plugin that closes the gap Variables still leave: it manages tokens inside Figma while syncing them to a Git repository — GitHub, GitLab, Bitbucket, or Azure DevOps — and exporting through Style Dictionary. If your source of truth lives in the repo (it should — more below), Tokens Studio is the bridge that lets designers edit it without leaving Figma.

**[Style Dictionary](https://styledictionary.com/)** is the build step: it takes one token source and exports it to "any platform" in its own words — CSS custom properties, a Tailwind theme, JavaScript constants, iOS and Android resources, documentation. Version 4 is forward-compatible with the W3C community format, which makes it the default answer to "how do tokens become code."

**The [Design Tokens Community Group format](https://www.designtokens.org/tr/drafts/format/)** is the piece that makes the rest interchangeable: a W3C community specification for token files — `.tokens.json`, with `$value` and `$type` properties and `{group.token}` alias syntax. It's still a draft (latest published June 2026), so treat it as a converging standard rather than a finished one — but the direction is set, tools are aligning on it, and writing your tokens in it today is the cheapest insurance against ever being locked into one vendor's format.

## The Figma-to-Code Workflow That Holds

Before choosing tools, make the one decision that determines whether the pipeline survives: where a token's value is allowed to change. One place per token; everything downstream is generated, never edited. Every token workflow that rotted — and we've audited plenty — rotted because a value could be changed in two places and nobody could say which one was true.

Our recommendation for product teams: the token file lives in the repository, and changes ship as pull requests. Git gives you review, history, versioning, and rollback for free — infrastructure a design tool can't replicate — and Tokens Studio's sync means designers still edit tokens from inside Figma. The pipeline ends up looking like this:

1. A designer changes `color.action.primary` in Figma — via Tokens Studio or a Variables export — which opens a pull request with a readable diff.
2. The team reviews the diff. This is the quiet superpower of the whole approach: design review becomes code review, and "why did the primary blue change" has a commit message.
3. CI runs Style Dictionary and regenerates every output — CSS variables, the Tailwind theme, native resources — so no platform can lag behind.
4. The change ships under a version number with a changelog entry. Tokens are a public contract with every surface of your product; breaking changes deserve the same ceremony as an API.

There's a 2026-specific reason to get this right that didn't exist three years ago: AI-assisted development. Cursor, Claude, v0 and their siblings generate UI from patterns, and without a token file they guess — plausible colors, almost-right spacing, a product that slowly stops looking like itself. With defined tokens in the codebase, the token file functions as a constraint set the AI works within. We've made the full argument in our [design system decision guide](/blog/design-system-decision-guide); the short version is that a token file is now AI scaffolding, not just design infrastructure.

## Seven Design Token Mistakes That Kill Adoption

Failed token projects fail the same seven ways — every one cheaper to prevent than to unwind.

### 1. Naming tokens after values

`blue-500` as a semantic token means the first rebrand renames everything that references it. Value names belong in the reference tier only; if a name would become false when a value changes, it's the wrong name. This mistake is listed first because it's the one you can't lint your way out of later.

### 2. Tokenizing everything on day one

Teams discover tokens and mint four hundred of them in a week — five surface colors, twelve grays, tokens for decisions no one has made yet. Nobody adopts a vocabulary that large, so hardcoded values creep back and the set becomes fiction. Start with the 30–50 semantic tokens your actual UI needs; add the rest when a real component asks for them.

### 3. Letting Figma and code drift apart

If designers maintain Variables and engineers maintain a theme file and nothing connects them, you have two design systems that happen to agree today. Drift isn't a discipline problem, it's an architecture problem — it ends when one side is generated from the other, and not before.

### 4. Adding component tokens before component pain

`button.primary.background` earns its existence when multiple teams need to restyle components independently. Before that, it's indirection: three files to open where one semantic token would do. Let the component tier be pulled into existence by real needs, never pushed by completionism.

### 5. Changing tokens without rules

A token set with no change process becomes a token set nobody trusts. The fix is lightweight, not bureaucratic: changes go through review, breaking changes bump a version, deletions get a deprecation window. If that sounds like software release discipline, that's the point — tokens are a dependency of every surface you ship.

### 6. Letting raw values leak back in

The day one engineer ships `#2563eb` instead of the token, the file stops being the source of truth — entropy only runs one direction. Mature teams make the token path the easy path and lint the escape hatch shut: a stylelint or ESLint rule that flags raw hex values and magic numbers costs an afternoon and preserves the whole investment.

### 7. Treating dark mode as a redesign

If dark mode requires touching components, the token architecture failed — it's supposed to be a second set of semantic values, full stop. Teams that build dark mode as a parallel stylesheet pay for every future screen twice. Build the semantic tier first and themes become configuration; skip it and every theme is a fork.

## When Design Tokens Are Overkill

A single-surface product with one theme and two people shipping it doesn't need a token pipeline — and pretending otherwise is how design systems get their reputation for ceremony. Jina Anne herself is on record that a straightforward editorial site may need nothing more than CSS variables. The person who coined the term gets to define its limits.

The honest heuristic parallels the rule of three we use for [design system investment](/blog/design-system-decision-guide) generally: a well-named Tailwind theme or CSS variable set *is* your token layer at small scale, and it's enough — until a specific trigger fires. Four triggers, in the order they usually arrive: a second surface (native app, marketing site, partner portal), a theming requirement (dark mode, white-label), the first time production visibly disagrees with Figma, and the adoption of AI codegen anywhere in your UI workflow. Each one converts tokens from ceremony into infrastructure. Until one fires, keep your values purpose-named and in one file — that habit is 80% of the migration, pre-paid.

## Rolling Tokens Into an Existing Product

Almost nobody gets to start from a blank palette — the real project is retrofitting tokens into a product that's been shipping for years, and it follows the same arc every time. Inventory first: dump every color, spacing, and radius value in the codebase, and brace yourself — a typical Series A–B product carries a few hundred unique color values doing the work of about thirty decisions. Collapse those into a reference palette, define the semantic tier against your five most-used screens rather than in the abstract, then migrate leaf-first — newest components convert first, the lint rule from mistake #6 stops the bleeding, and the long tail converts opportunistically. No big bang, no freeze.

We've run this arc across 40+ B2B SaaS products, and the pattern holds from single-dashboard fintech products to multi-product platforms: the token layer is the highest-leverage week a design-engineering pair can spend, *if* it's sized to the stage. That sizing is what our Design System Readiness framework — Signal, Scope, Stack, Stewardship — exists to do, so a Series A team gets a token file and a pipeline, not an IBM-scale governance process.

If you know what you need and want to talk scope:

[Talk to us about your design system →](/services/design-system)

Related: [12 Design System Examples Worth Studying](/blog/design-system-examples) · [Do You Actually Need a Design System?](/blog/design-system-decision-guide) · [The Complete Guide to SaaS UI/UX Design](/blog/saas-ui-ux-design-guide) · [AI Product Design in 2026](/blog/ai-product-design-guide)

---

### B2B SaaS Website Design in 2026: 8 Sites That Actually Convert (Teardown)
URL: https://www.themasterly.com/blog/b2b-saas-website-design
Product Design · 2026-07-29

Most B2B SaaS websites are written for the wrong reader: they describe the product to people who already understand it, in language only the founding team loves. The sites that convert do something harder — they earn a skeptical evaluator's next thirty minutes in under ten seconds.

"SaaS website design inspiration" content won't show you how. Galleries like Saaspo and Dribbble tags are screenshot museums: pleasant to scroll, silent on why any of it works. So we did what we did for [design system examples](/blog/design-system-examples) — picked the strongest B2B SaaS websites live right now, verified what's actually on them (every hero headline below was checked this month, not quoted from memory), and tore down the conversion decisions behind the aesthetics.

Here's what this guide covers:

1. What a B2B SaaS marketing website's actual job is — and why it's not a smaller version of your product
2. Eight teardowns: Linear, PostHog, Stripe, Ramp, Attio, Clay, Vanta, Mercury — with the one pattern to steal from each
3. The seven mistakes founders get roasted for, from a culture that reviews hundreds of SaaS sites a week
4. The four conversion patterns behind all eight, including the 2026 shift nobody's site strategy accounts for yet: AI agents as visitors
5. The order we'd fix a real site in — five moves, cheapest first

## Your Website Is Not Your Product (And Shouldn't Be Designed Like It)

A B2B SaaS website has exactly one job: convert a qualified evaluator into a demo, trial, or signup. Your product earns retention over months; your website earns the first meeting in seconds — different jobs, different design problems, and conflating them is why so many beautifully designed products hide behind websites that read like spec sheets.

The evaluator arriving at your homepage is mid-[conversion funnel](/glossary/conversion-funnel): they've heard your name from a peer, a listicle, or an AI answer, and they're pattern-matching for three things — do you solve my problem, do companies like mine trust you, and what will this cost me. Every section that doesn't advance one of those three questions is decoration.

One B2B nuance that generic CRO advice misses: your site serves a buying committee, not a single converter. The researcher compiling a vendor shortlist often *can't* click "book a demo" — procurement happens above their pay grade — and marketers in r/marketing threads are blunt that aggressive conversion copy reads as desperate to exactly this reader. The homepage's job splits accordingly: convert the champion, equip the researcher.

This is also why "just make it look like Linear" is bad advice. What transfers from great SaaS websites isn't the aesthetic — it's the conversion decisions underneath: how they compress positioning into a sentence, how they sequence proof, where they put the price. That's what the teardowns below extract. (For the product side of this — the in-app experience that makes the promise true — see our [SaaS UI/UX design guide](/blog/saas-ui-ux-design-guide).)

## Eight B2B SaaS Website Designs Worth Stealing From in 2026

The eight below were selected from a wider audit for one quality: each is the best-in-class example of a specific conversion pattern, not just a pretty homepage. The table is the map; the teardowns are the territory.

| # | Site | What it sells | Signature pattern | Steal this |
| --- | --- | --- | --- | --- |
| 1 | Linear | Product development system | Restraint + product-as-hero | One-sentence positioning |
| 2 | PostHog | Product analytics suite | Personality + radical transparency | Pricing page as trust asset |
| 3 | Stripe | Payments infrastructure | Proof by numbers | Metrics over adjectives |
| 4 | Ramp | Finance operations | Live counters, agent-readable site | Design for non-human visitors |
| 5 | Attio | CRM | Agent-native metrics | Interactive product walkthrough |
| 6 | Clay | GTM data platform | Illustration-led hero | Differentiate against the category |
| 7 | Vanta | Compliance automation | Category message + mascot | Gated pricing done deliberately |
| 8 | Mercury | Startup banking | Explorable public demo | Let them touch the product |

### 1. Linear

**Best for: compressing positioning into one sentence.**

[Linear's](https://linear.app) hero reads, in full: "The product development system for teams and agents." Seven words that name the category, the buyer, and — with "agents" — the 2026 repositioning, without a single adjective. Below it, no illustration, no stock metaphor: the product itself, rendered as live-feeling UI.

The social proof choice is equally deliberate. Instead of the default logo wall, Linear leads with one number — over 37,000 product teams — and named quotes from executives at companies its buyers admire. That's proof sequenced for a technical audience that distrusts marketing: a count they can believe, faces they can verify.

Linear's site is the hardest kind of design to commission: the restraint only works because the positioning work was done first. Copy the sparseness without the clarity and you get an empty page. And plenty do copy it — r/web_design has entire threads rebuilding Linear's landing page component by component, to the point that "looks like a Linear clone" is now its own flavor of template sameness. Steal the discipline, not the dark gradient.

**Steal this:** the one-sentence test. If your hero can't name what you are and who you're for in under ten words, the problem is positioning, not design.

### 2. PostHog

**Best for: turning the pricing page into a trust asset.**

[PostHog](https://posthog.com) runs the most distinctive voice in B2B SaaS — jokes in section labels, a CLI command as a hero call-to-action, and a logo wall captioned with a line most marketing teams would veto:

> "Yes they actually use us, no it's not just some random engineer."
> — posthog.com, the caption under its own customer logos

And the commitment runs all the way down: the site itself is styled as a desktop operating system — draggable windows, a dock of icons, a literal Trash folder — and even the legally required cookie banner is written as a punchline. The personality is a moat precisely because it can't be templated — but the deeper conversion asset is transparency. PostHog publishes fully usage-based pricing down to the per-event rate, with a free tier generous enough to run a real product, and no sales-gated tier at all. For its developer buyer, the pricing page does what a demo call does elsewhere: it removes the fear of the conversation.

**Steal this:** write the pricing page for the skeptic, not the optimist. Every number you publish is an objection you never have to handle on a call.

### 3. Stripe

**Best for: proof by numbers instead of adjectives.**

[Stripe's](https://stripe.com) hero — "Financial infrastructure to grow your revenue." — is backed by the heaviest metrics play on the web: $1.9 trillion in payments processed in 2025, 99.999% uptime, half of the Fortune 100 as customers. There isn't an adjective on the page working as hard as those three numbers. The signature flourish is a live ticker computing the share of global GDP running on Stripe — an absurd, memorable way to say "we are load-bearing for the economy."

The lesson scales down further than most founders think. You don't need a trillion-dollar number; you need your *strongest true number* doing the work adjectives currently do. "Trusted by fast-growing teams" is filler. "212 companies migrated to us this year" is proof.

**Steal this:** replace your three strongest adjectives with your three strongest numbers. If you don't have three numbers, that's the real problem to fix.

### 4. Ramp

**Best for: designing for visitors who aren't human.**

[Ramp's](https://ramp.com) human-facing site is excellent — "Time is money. Save both." over an email-capture CTA, with live counters (payments processed, agents at work, receipts parsed) ticking as social proof. But the reason it's in this teardown is what it serves visitors who aren't people: Ramp detects AI agents and returns a dedicated machine-readable markdown version of the site — complete with an agent-specific signup incentive.

Sit with that: a finance platform decided that AI agents researching "corporate card providers" on a founder's behalf are a conversion channel worth building for. As more buying research runs through AI assistants, the sites that answer machine questions cleanly — structured data, clean markdown, direct answers — will get recommended, and the sites that are JavaScript soup will not. This is the same logic as GAIO for content, applied to the whole website.

**Steal this:** audit what an AI agent sees when it fetches your site. If the answer is unreadable markup, you're invisible to the fastest-growing referral channel of the decade.

### 5. Attio

**Best for: letting evaluators touch the product before signup.**

[Attio's](https://attio.com) hero — "Welcome to agentic revenue." — is the boldest repositioning bet of the eight: a CRM introducing itself by the agents inside it, with homepage metrics to match (76,000 active customer agents, 400M API calls a week, MCP call volume as a headline stat — that last one may be the most 2026 sentence in this article).

The conversion mechanism worth stealing is the interactive walkthrough embedded on the homepage: evaluators click through real product flows — no form, no sales call, no signup. For a category as commoditized as CRM, where every competitor claims the same features, letting the interface argue for itself is the only claim that can't be copied in a headline.

**Steal this:** an interactive walkthrough or clickable demo above the fold. Every step of product evidence you move before the form lifts the quality of who fills it.

### 6. Clay

**Best for: differentiating against your own category's visual clichés.**

Every GTM and data tool's website looks the same: dashboard screenshot, gradient, logo wall. [Clay](https://clay.com) opens instead with a playful retro-machine illustration — tubes, funnels, moving parts — that explains what the product does (data in, orchestrated plays out) better than a screenshot of tables ever could. In a screenshot-led category, being illustration-led is itself information: it says "we're not another dashboard."

The proof layer underneath is conventional but executed at full depth: a giant wall of recognizable logos, outcome stats attached to named customers, and C-level testimonials with names and faces. Clay earns the playfulness by stacking hard proof directly beneath it.

**Steal this:** find your category's visual cliché and deliberately break it — then over-invest in proof so the playfulness reads as confidence, not compensation.

### 7. Vanta

**Best for: gated pricing done as a deliberate choice.**

[Vanta's](https://vanta.com) hero is the tightest category-message fit on this list: "Trust is everything," from the company that sells compliance automation — the product is trust, the message is trust, the design's job is done in three words. The proof stack is textbook enterprise: 16,000+ customers, a logo wall, per-customer outcome stats, and the actual compliance badges its buyers need to see. Plus an animated llama mascot — a genuinely weird, memorable warmth play in the most sterile category in software.

Vanta is also the deliberate counter-example on pricing: no public numbers, four tiers, demo-gated. For a sales-led motion selling into a compliance journey that always involves a conversation anyway, the gate filters rather than leaks. The pattern fails only when product-led companies copy it by default.

**Steal this:** make the pricing-gate decision match your sales motion, consciously. Gated + sales-led = filter. Gated + product-led = drop-off.

### 8. Mercury

**Best for: letting anyone drive the product with zero commitment.**

[Mercury's](https://mercury.com) hero pairs "Radically different banking" with the most generous conversion mechanism of the eight: a "Launch demo" button that opens a fully explorable product dashboard — no signup, no email, no tour rails. For a financial product, where the evaluator's real question is "will I trust this interface with my company's money every day," the explorable demo answers it in a way no feature list can.

The proof layer is aggressive for a startup-facing brand: 300K+ customers, a claim to serve one in three US startups, $20B+ in monthly transaction volume, plus founder-portrait testimonials. And the whole thing is wrapped in genuinely art-directed [brand identity](/glossary/brand-identity) — proof that "fintech" and "beautiful" stopped being a contradiction some time ago.

**Steal this:** the zero-commitment demo. If your product's interface is a selling point, gating it behind a sales call is working against your best asset.

## What Founders Get Roasted For: The Same Seven Mistakes

The fastest education in SaaS website design isn't studying the winners — it's watching the "roast my landing page" culture on r/SaaS, where hundreds of founder sites get reviewed every week and the same seven mistakes never stop appearing. One practitioner who audited 200 SaaS landing pages found that one in eight was incomprehensible on first read, only one in five stated a differentiator anywhere on the page, and only two in five founders knew their own conversion rate.

The recurring failures, in roughly the order they get called out:

1. **The pitch-deck hero.** Copy that describes what the product *is* ("a next-gen platform for dynamic collaboration") instead of what the buyer *gets*. The most-repeated roast line is some variant of "no one can tell what you do."
2. **Features instead of outcomes.** Nobody buys "Advanced Analytics Dashboard"; they buy "know which customers will churn this month."
3. **Fake social proof — now worse than none.** Inflated user counters and generated testimonials get roasted harder than an honest "we're in early access." The accepted substitute for pre-customer products: short GIF demos of the product actually solving something.
4. **Hidden pricing on a self-serve product.** In roast threads it's treated as an instant exit; more on the thresholds below.
5. **Template sameness.** Reviewers describe clocking AI-built sites "in two seconds": identical section rhythm, three-icon feature grids, glassmorphism, everything at equal visual weight. Human-designed pages have asymmetry, because someone decided what mattered most.
6. **Competing CTAs.** Half the audited pages had multiple equally weighted calls-to-action — analysis paralysis by design.
7. **Sloppiness as a trust proxy.** Evaluators can't test your product in ten seconds, so they test your website instead:

> "Sloppy design subconsciously signals sloppy product."
> — recurring verdict in r/web_design threads on SaaS landing pages

Worth stealing from the roast culture itself: every one of these is checkable against your own site in an afternoon, by someone who isn't you.

## The Four Patterns Behind the Conversions

Strip the brands away and the eight sites converge on four decisions — none of which is an aesthetic.

**The hero is a positioning artifact, not a design artifact.** Linear's seven words, Vanta's three, Ramp's five. Every strong site on this list won the homepage in the messaging document before a pixel was placed. The weak version — "Empower your team's productivity journey" — isn't a design failure; it's unfinished positioning leaking into production.

**Proof escalates: logos → numbers → names → live data.** A logo wall is now the floor. Stripe leads with economy-scale metrics, Linear with named executives, Ramp with counters ticking in real time. The pattern to copy isn't any single format — it's matching the format to the strongest proof you truly have, one rung up from where you are today. Fake escalation is the one unforgivable move: inflated "happy users" counters and generated testimonials now destroy more trust than having no proof at all.

**Pricing transparency is the 2026 default.** Eight of the ten sites in our wider audit publish real numbers. The two that don't — Vanta fully, Ramp partially — are deliberate sales-led choices, not omissions. The working thresholds practitioners converge on: self-serve and mid-market products show real numbers; genuinely variable enterprise scopes can gate, but even then a "starting at" range reduces friction. The buyer-side sentiment is unambiguous — in communities where B2B buyers compare vendors, hidden pricing is read as "the price is whatever the rep thinks you'll pay." If your [conversion-rate optimization](/glossary/conversion-rate-optimization) roadmap still treats the pricing page as a lead-capture wall for a self-serve product, you're optimizing against the decade.

**And the newest pattern: your next visitor may not be human.** Eight of the ten sites we audited rewrote their hero messaging around AI and agents this cycle — Linear "for teams and agents," Attio's "agentic revenue," PostHog's "self-driving mode," Stripe's agentic commerce push. That's messaging. Ramp went further and rebuilt the medium: a machine-readable site for the agents doing the buying research. Both moves point the same direction — B2B SaaS websites are starting to serve two audiences, and only one of them cares about your gradient.

## The Order We'd Fix Yours In

Start with the cheapest, highest-leverage fixes first. This is the sequence we run when a Series A–D company hands us a site that isn't converting:

1. **Rewrite the hero against the one-sentence test** (Linear). Category, buyer, difference — under ten words. This costs nothing and moves everything.
2. **Swap adjectives for your strongest true numbers** (Stripe). Whatever scale you're at, real numbers beat superlatives at that same scale.
3. **Make the pricing decision consciously** (PostHog vs. Vanta). Self-serve motion → publish numbers. Sales-led motion → gate deliberately and say why.
4. **Move product evidence above the form** (Attio, Mercury). Screenshots minimum, walkthrough better, explorable demo best.
5. **Check what machines see** (Ramp). Structured data, clean semantics, direct answers — your site is being read by AI assistants whether you designed for them or not.

One warning that ties this to everything [we've written about design systems](/blog/design-system-examples): the fastest way to fail all five points at once is shipping a template. To be fair to templates, the counter-argument is real — conventional layouts work because users have learned them, and inside your product, convention is usually the right call. But the marketing site is the one surface whose entire job is differentiation, and there the template look — same fonts, same section rhythm, same component library defaults — tells an evaluator that the website, and by extension the company, is interchangeable. Your site doesn't need to be louder than these eight; it needs to be unmistakably yours, which is a [design-system problem](/glossary/design-system) before it's a website problem. And it's the same failure mode founders keep making [inside the product](/blog/series-a-saas-design-mistakes) — shipping something that works but signals nothing.

We design marketing websites for B2B SaaS, fintech, healthtech, and AI companies — most often at Series A–D, where the site has to carry real pipeline. Positioning-led, built on a site design system that matches your product, shipped via Webflow or modern code stacks. If you know what you need and want to talk scope, [we're here](/services/web-design).

Related: [The Complete Guide to SaaS UI/UX Design](/blog/saas-ui-ux-design-guide) · [12 Design System Examples Worth Studying](/blog/design-system-examples) · [SaaS Design Mistakes Series A Companies Keep Making](/blog/series-a-saas-design-mistakes) · [Top SaaS Design Agencies](/blog/top-saas-design-agencies)

---

### 12 Design System Examples Worth Studying in 2026 (And What to Steal From Each)
URL: https://www.themasterly.com/blog/design-system-examples
Design Systems · 2026-07-23

Most roundups of design system examples are museum tours: a screenshot of Material, a screenshot of Carbon, a line about "consistency at scale," next slide. Pleasant to scroll, useless to act on. The teams that published these systems made hundreds of documented decisions about tokens, naming, governance, and adoption — and the decisions, not the screenshots, are the part worth your time.

This guide reads the twelve most instructive public [design systems](/glossary/design-system) the way a product team should: what each one is unusually good at, and what a Series A–D B2B company can steal from it this quarter.

Here's what this guide covers:

1. Twelve design system examples worth studying in 2026 — ranked by usefulness to a product team, not by brand fame
2. The specific practice to steal from each one
3. What the best systems have in common (it's not the visuals)
4. What your team should copy — and what to skip — if you're not Google
5. Why serious brands build their own systems — and what that actually costs in 2026

## What Makes a Design System Example Worth Studying

A design system example is worth studying when it shows its decisions in public — token architecture, pattern documentation, contribution rules — not just its components. A pretty [component library](/glossary/component-library) tells you what a team shipped; the documentation around it tells you how they think, and that's the transferable part.

Three criteria filtered this list. First, public depth: full documentation and, in most cases, open-source code — so you can inspect real decisions instead of marketing pages. Second, survival: every system here has shipped through at least one major redesign or token migration, which is where systems either prove their architecture or quietly die. Third, relevance: collectively they cover the problems a B2B SaaS team actually has — dense data UI, multi-product consistency, accessibility, and making engineers adopt the thing.

We also pressure-tested every entry against what practitioners say when nobody is marketing to them — the recurring praise and complaints in Reddit communities like r/UXDesign, r/reactjs, r/webdev, and the platform-specific subs. Where the Reddit consensus contradicts the official story, we say so in the entry.

One stat worth keeping in mind while you study them: [according to Storybook and Brad Frost's research](https://storybook.js.org/blog/why-most-design-systems-implode/), only about 40% of design systems are considered successful by their own teams. Every system on this list is in the minority that survived — which is exactly why their published practices matter more than their visual style.

## Twelve Design System Examples Worth Studying in 2026

The twelve examples below are ranked by usefulness to a B2B product team, not by brand fame — which is why Shopify Polaris opens the list and Google Material sits in the middle. Each entry ends with the one practice worth stealing; the table gives you the whole list at a glance.

| # | Design system | Company | Best for | Steal this |
| --- | --- | --- | --- | --- |
| 1 | Polaris | Shopify | Documentation quality | "When to use / when not to use" sections |
| 2 | Atlassian Design System | Atlassian | Token migration at scale | Semantic token naming |
| 3 | Carbon | IBM | Accessibility + governance | Per-component a11y docs |
| 4 | Primer | GitHub | System as engineering product | Versioning + changelog |
| 5 | Material 3 | Google | Token architecture, theming | Three-tier token structure |
| 6 | Human Interface Guidelines | Apple | Platform conventions | A one-page conventions doc |
| 7 | Fluent 2 | Microsoft | Cross-platform coherence | Shared tokens, per-platform code |
| 8 | Spectrum | Adobe | Evolving a live system | Versioned token contract |
| 9 | Lightning | Salesforce | Enterprise density, token origin | Name every design decision |
| 10 | Base | Uber | Multi-brand theming | Components against tokens, not brand values |
| 11 | GOV.UK Design System | UK Government | Research-backed patterns | "Useful and unique" contribution bar |
| 12 | shadcn/ui | Community | Ownership model (not the theme) | Copy primitives, replace every default |

### 1. Shopify Polaris

**Best for: learning what design system documentation should look like.**

[Polaris](https://polaris.shopify.com/) is the system behind the Shopify admin — the interface a million merchants run their businesses in — and it remains the single most useful design system example for a B2B SaaS team, because your product almost certainly looks more like the Shopify admin than like a consumer app.

What sets Polaris apart is that the documentation is opinionated about usage, not just appearance. A component page doesn't stop at props and variants; it tells you when to use the component, when not to, and what to use instead. The content guidelines go further than any competitor's: voice and tone, capitalization, how to write an error message, how to name an action. Most teams treat microcopy as an afterthought; Polaris treats it as a system primitive.

The practitioner caveat is equally consistent: Polaris is built for the Shopify admin and it should stay there. Developers on r/shopifyDev describe the components as restrictive — layouts that take minutes in plain CSS take hours inside Polaris's composition rules — and the ongoing React-to-Web-Components migration has been rough on app builders. Nobody on Reddit recommends adopting the library outside embedded Shopify apps. Study the documentation; skip the npm package.

**Steal this:** the "when to use / when not to use" section on every component page. Adding that single section to your own docs does more for adoption than any amount of visual polish.

### 2. Atlassian Design System

**Best for: the design token migration playbook.**

The [Atlassian Design System](https://atlassian.design/) serves Jira, Confluence, Trello, and Bitbucket — products with wildly different histories that still need to feel related. That multi-product pressure forced Atlassian into the most instructive [design token](/glossary/design-token) migration in the industry: moving thousands of hardcoded color values across four products onto a semantic token layer, with codemods, lint rules, and adoption dashboards to enforce it.

The token naming alone is worth an afternoon of study. Tokens are named by purpose (`color.background.danger`), never by value (`red-600`), which is what made automated dark mode across the entire product suite possible — the theme swaps under the tokens and the products don't have to care.

One warning before anyone on your team runs `npm install`: the design system's license only permits use in products that integrate with Atlassian software — a detail teams on r/reactjs tend to discover late. This is a system to study, not to ship.

**Steal this:** semantic token naming from day one. If your tokens are named `blue-500` instead of `color.action.primary`, every future rebrand and every theme is a manual migration.

### 3. IBM Carbon

**Best for: accessibility as architecture, and governance you can copy.**

[Carbon](https://carbondesignsystem.com/) is IBM's open-source system, and it treats accessibility the way most systems treat color: as a foundation, not a checklist. Components ship with WCAG-tested keyboard navigation, screen-reader behavior, and documented accessibility notes per component. For any company selling into enterprise or government — where a VPAT shows up in procurement — Carbon is the reference for what "accessible by default" actually means in practice.

Carbon is also one of the few systems whose governance is fully public: contribution process, review criteria, release cadence, deprecation policy. Most internal design systems fail on exactly these mechanics, and Carbon lets you copy them instead of inventing them.

Reddit sentiment on Carbon splits cleanly along the design/code line. Among designers it's arguably the most-copied reference: the top-voted advice in r/UXDesign threads about starting a design system is literally to mirror Carbon's structure. Engineers are harsher — the React implementation's developer experience draws recurring complaints about customization friction and documentation sprawl. The pattern practitioners converge on: adopt Carbon's design rules and token naming, implement on your own component stack.

**Steal this:** per-component accessibility documentation. Write down the expected keyboard behavior for your five core components and you're ahead of most Series B products.

### 4. GitHub Primer

**Best for: running a design system as an engineering product.**

[Primer](https://primer.style/) is the system behind GitHub, and it's the clearest example of a system built engineering-first. Design tokens ship as code packages. Components are versioned, released, and deprecated like any other software dependency. Octicons, Primer's icon system, is one of the most widely reused icon sets in the industry precisely because it's distributed like software.

The lesson Primer teaches is cultural, not technical: at GitHub, the design system is infrastructure with an SLA, not a Figma file with aspirations. That framing — system as dependency, not as guideline — is what separates systems engineers adopt from systems they route around.

There's a 2026 footnote worth knowing: GitHub moved Primer's Rails implementation into maintenance mode as the company migrates to React, and the r/rails community's frustration is a useful reminder that a vendor's open-source system always follows the vendor's roadmap, not yours. The part to copy is that even the deprecation happened in the open, with notice — which is more than most internal systems manage.

**Steal this:** version your design system and write a changelog. The moment component changes have release notes, engineering starts treating the system as real.

### 5. Google Material Design 3

**Best for: token architecture and theming at planetary scale.**

[Material 3](https://m3.material.io/) is the most complete public specification of a design system in existence — color science, motion, typography, adaptive layouts, all documented to a depth no product team will ever need. Its dynamic color system, which generates a full accessible palette from a single seed color, is the most sophisticated public implementation of token-based theming you can study.

The caveat is equally important: Material is built for an ecosystem of millions of apps, and adopting it wholesale makes your product look like Android. Material is the system to read for architecture — how tokens cascade from reference to system to component level — and the system not to copy for visual identity.

Practitioner sentiment backs the split verdict. On r/UXDesign the spec earns respect while the official Figma kits are routinely called broken; on the React side, the defining complaint about MUI — Material's de facto web implementation — is the endless fight to not look like Google. The recurring punchline in those threads: if you're going to restyle every component anyway, you should have started headless.

**Steal this:** the three-tier token architecture (reference → system → component). It's the pattern that keeps a growing token set from collapsing into an unmaintainable flat list.

### 6. Apple Human Interface Guidelines

**Best for: platform conventions and restraint — guidelines without a component dump.**

The [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines) are the oldest living design documentation in the industry, and they're instructive precisely because they're not a component library. The HIG documents principles and platform conventions — how navigation should feel, when to use a sheet versus a popover, how depth and hierarchy communicate — and trusts you to implement them.

For product teams, the HIG is the best available education in *why* interface conventions exist. If your product ships on iOS, it's mandatory reading. Even if it doesn't, the sections on layout, feedback, and modality will sharpen how your team argues about [UI design](/glossary/ui-design) decisions.

The standing joke across r/MacOS and r/iOSProgramming is that the most frequent HIG violator is Apple itself — threads cataloguing Apple's own guideline-breaking UI are a genre of their own. Which sharpens the real lesson: read the HIG for its principles and reasoning, not as a compliance document even its author follows.

**Steal this:** write down your product's five non-negotiable conventions — the decisions that make your product feel like itself. That one page is a design system seed that costs nothing.

### 7. Microsoft Fluent 2

**Best for: one design language across web, desktop, and mobile.**

[Fluent 2](https://fluent2.microsoft.design/) is Microsoft's answer to a problem most companies hit at Series C, not Series A: shipping one product identity across web, Windows, iOS, and Android without four divergent codebases of UI decisions. Fluent's documentation is organized around that problem — shared tokens and principles at the top, per-platform implementations below.

It's also a useful case study in system evolution: Fluent 2 is a full redesign of a system already deployed across the largest software portfolio on earth, executed without stopping product development. The migration notes are a preview of decisions your team will face at a fraction of the scale.

Fluent's Reddit reputation is the mirror image of its docs: the engineering of the current React implementation gets genuine praise — accessibility, form-library interop — but the dominant sentiment is churn fatigue. Fabric became Fluent became v8 became v9, and developers outside the Microsoft ecosystem openly doubt any given version will be supported in two years. The takeaway for your own system: every rename and rewrite spends adoption trust you'll struggle to earn back.

**Steal this:** the shared-tokens, per-platform-implementation structure. The moment you add a mobile app, this is the only architecture that prevents drift.

### 8. Adobe Spectrum

**Best for: versioning and evolving a system without breaking the products on it.**

[Spectrum](https://spectrum.adobe.com/) runs across Creative Cloud — some of the most information-dense professional software in existence — and its public evolution to Spectrum 2 is the best available case study in redesigning a live system. Adobe publishes its design tokens as open-source packages, and the deliberate, versioned rollout shows how you change the foundations under dozens of shipping products without a big-bang rewrite.

Spectrum's documentation is also unusually strong on internationalization and platform scaling — the unglamorous constraints that most design system examples skip and most scaling products eventually hit.

Spectrum has the strangest Reddit profile on this list: practitioners largely ignore Adobe's visual layer and adopt what's underneath it. React Aria — the headless accessibility-and-behavior layer Spectrum is built on — is spoken of in r/reactjs with something close to reverence, especially its focus management and date pickers. It's the clearest proof of this article's thesis: the invisible layers of a design system are the valuable ones.

**Steal this:** treat your token file as a versioned public contract. Breaking changes to tokens get a version bump and a migration note, exactly like an API.

### 9. Salesforce Lightning

**Best for: understanding where design tokens came from — and enterprise density done deliberately.**

The term "design tokens" was coined at Salesforce, and the [Lightning Design System](https://www.lightningdesignsystem.com/) is where the idea was first proven at scale: name every design decision, store it as data, distribute it to every platform. Every token-based system on this list is downstream of that insight.

Lightning is also the reference for unapologetically dense enterprise UI. Where consumer-influenced systems optimize for whitespace, Lightning optimizes for operators who live in the product eight hours a day — tables, filters, record layouts. If you're designing a data-heavy B2B tool, Lightning's patterns are closer to your reality than Material's.

The view from inside the ecosystem is blunter: r/salesforce treats SLDS as a CSS toolkit rather than a full design system, and the recurring complaint is how hard styling against it becomes the moment a product shouldn't look like Salesforce. Study Lightning's density patterns and token discipline from a safe distance; the lock-in is a feature for Salesforce, not for you.

**Steal this:** the discipline of naming every design decision. If a value isn't a named token, it's a future inconsistency.

### 10. Uber Base

**Best for: multi-brand theming on one component set.**

[Base](https://base.uber.com/) is Uber's cross-platform system, built to serve distinct brands — Rides, Eats, Freight — from one component foundation. Its React implementation, Base Web, made an architectural bet worth studying: every component is themeable through a single override API, so one library can render as visually different products without forks.

For most companies this matters the day a second surface appears — a white-label offering, an acquired product, a partner portal. Base shows what the component API has to look like for "same system, different brand" to be a configuration change instead of a rewrite.

Full disclosure on its status, because roundups keep getting this wrong: the open-source repo isn't dead — it still mirrors Uber's internal development — but Uber formally limited its engagement with outside contributors back in 2023, and the r/reactjs consensus has settled on "study it, don't start a new product on it." Which is exactly how it earns its place here: as architecture to learn from, not a dependency to adopt.

**Steal this:** build components against tokens, never against brand values — even with one brand. Multi-brand capability is a cheap side effect of doing tokens correctly.

### 11. GOV.UK Design System

**Best for: research-backed patterns and the strictest contribution bar in the industry.**

The [GOV.UK Design System](https://design-system.service.gov.uk/) is the least glamorous system on this list and possibly the most rigorous. Every pattern is backed by user research across government services, and the docs tell you what the research found — including where a pattern failed and was revised. Nothing enters the system unless it's proven useful and unique, and that published contribution bar is why the system stays small, trusted, and adopted rather than bloated.

It's also the industry benchmark for designing forms and transactional flows in plain language — directly applicable to onboarding, checkout, and KYC flows in any [fintech or SaaS product](/blog/saas-ui-ux-design-guide). And it's the only system on this list with near-universal approval across developer Reddit — r/webdev threads regularly hold it up as the gold standard for accessibility. The single recurring criticism is visual austerity, which its defenders correctly point out is the entire point.

**Steal this:** the contribution criteria. Requiring evidence that a pattern is "useful and unique" before it enters your library is the cheapest defense against 300-component bloat.

### 12. shadcn/ui

**Best for: the ownership model — if you replace the defaults with your own system.**

Let's name the elephant first: in 2026, the default shadcn look is the uniform of AI-generated products. Every v0 demo, every Cursor-built dashboard, every weekend AI app ships the same cards, the same buttons, the same grayscale-plus-one-accent theme. When people say an interface "looks AI-generated," this is usually the interface they mean.

The complaint isn't fringe: "every shadcn app looks the same" threads are a recurring genre on r/webdev, and "shadcn slop" has become a stock insult across programming subreddits. Notably, the community's own standard rebuttal is the thesis of this article: the sameness is a defaults problem, not a library problem — the entire look hangs off a small token file that most teams never edit.

That's precisely why [shadcn/ui](https://ui.shadcn.com/) belongs on this list — for the opposite reason most roundups include it. Its real contribution isn't the theme; it's the ownership model. Components are copied into your codebase, not imported from a styled dependency, with accessible Radix primitives underneath. Used correctly, it's invisible plumbing under your own design system: you keep the interaction and accessibility engineering, replace every default token and radius with your own visual language, and none of your users ever guesses what's under the hood. Used lazily — defaults shipped as-is — it announces that no designer was involved, which is the exact opposite of what a design system is for. The difference between the two outcomes is whether you did the [token work this whole list is about](/blog/design-system-decision-guide).

**Steal this:** the ownership model, never the default theme. Copy the primitives into your repo, then systematically replace the defaults with your own tokens — the unmodified look now reads as "built by AI, reviewed by nobody."

## What the Best Design Systems Have in Common

Strip the branding and the twelve systems above converge on four practices — and none of them is visual.

**Tokens are the foundation, components are the output.** Every system that survived a redesign did it by swapping values under a stable token layer. [Supernova's State of Design Tokens report](https://www.supernova.io/state-of-design-tokens) found 69.8% of design teams have adopted Figma Variables — the industry has already voted: tokens, not components, are the core asset. How to actually build that layer — naming, tiers, the Figma-to-code pipeline — is its own discipline, and we've written a [practical guide to design tokens](/blog/design-tokens) for it.

**Documentation explains when, not just what.** Polaris, GOV.UK, and Carbon all spend more words on usage guidance than on visual specs. A component without usage rules is a [style guide](/glossary/style-guide) entry; with them, it's a decision your team no longer has to re-make.

**Governance is visible.** Contribution rules, deprecation policies, release notes. The systems that engineers actually adopt behave like software products, which is the point of the most-quoted line in the field:

> "A design system isn't a project. It's a product, serving products."
> — Nathan Curtis, co-founder of EightShapes

**The design layer earns the praise; the implementation draws the complaints.** Across hundreds of Reddit threads the pattern never varies: designers admire the docs, tokens, and guidelines; engineers curse the shipped component code — Carbon's React library, MUI's theming, Polaris's composition rules. That's not an argument against studying these systems. It's the argument for the 2026 consensus: borrow the design decisions, then implement on headless primitives you control.

**They're allowed to say no.** GOV.UK's "useful and unique" bar, Polaris's "when not to use" sections, Primer's deprecations. Weak systems accumulate; strong systems curate. The 60% of systems that fail mostly fail by becoming warehouses of unused components — the accumulated [design debt](/glossary/design-debt) of never refusing anything.

## What to Copy If You're Not Google

Copy the practices, not the systems. Material has hundreds of contributors; you have, at best, a design lead with 20% of their time. The good news is that the practices above scale down to almost zero cost, and we've watched lean versions of them work across 40+ B2B SaaS products:

1. **Semantic tokens from day one** (Atlassian, Lightning) — a Tailwind config with purpose-named tokens is a one-day investment that every future theme and rebrand depends on.
2. **Usage rules on your core components** (Polaris, GOV.UK) — one paragraph of "when to use / when not to" per component, in the codebase, next to the code.
3. **Version it like software** (Primer, Spectrum) — a changelog and named releases turn "the Figma file" into infrastructure engineering trusts.
4. **A bar for entry** (GOV.UK) — the rule of three: a pattern gets extracted into the system the third time it's rebuilt, not before.

What to skip at Series A–B: a documentation site, a dedicated system team, multi-brand theming before a second brand exists, and adopting any of these systems wholesale. Whether you should be investing in a system at all right now — and how deep — is a stage question, and we've written a full decision framework for it: [Do You Actually Need a Design System?](/blog/design-system-decision-guide)

## Serious Brands Own Their Design System

Notice what's not on this list: a single serious brand shipping someone else's design system. Shopify, Atlassian, Uber, and GitHub could all have adopted Material and saved millions — and none of them did, because at a certain level of ambition your interface language *is* your brand, and you don't rent your brand. A design system is how visual identity survives contact with shipping velocity: the difference between a product that looks intentional in every screen an investor, enterprise buyer, or new hire opens, and one that visibly accreted.

That bar used to be reserved for companies with IBM-sized budgets. It isn't anymore — a lean owned system (semantic tokens, 15–25 governed components, usage rules in the repo) is a weeks-scale investment, and it's the work we do most often for Series A–D B2B SaaS, fintech, healthtech, and AI companies: token architecture, component libraries, Figma-to-code pipelines, and the governance that makes engineering actually adopt them. Our Design System Readiness framework — Signal, Scope, Stack, Stewardship — exists to size that system to your stage, not to IBM's.

If you know what you need and want to talk scope:

[Talk to us about your design system →](/services/design-system)

Related: [Do You Actually Need a Design System? A Decision Guide](/blog/design-system-decision-guide) · [Design Tokens: A Practical Guide](/blog/design-tokens) · [The Complete Guide to SaaS UI/UX Design](/blog/saas-ui-ux-design-guide) · [AI Product Design in 2026](/blog/ai-product-design-guide) · [How to Conduct a UX Audit](/blog/ux-audit-guide)

---

### Best Fintech Design Agencies in 2026 (Ranked for Financial Products)
URL: https://www.themasterly.com/blog/best-fintech-design-agencies
Fintech · 2026-07-21

Fintech design is where most generalist UI/UX agencies get exposed. The work looks familiar from the outside — onboarding flows, dashboards, transaction screens — but the constraints are specific: regulatory compliance that shapes every design decision, financial data that requires precision layout, security UX that has to communicate trust without creating friction, and error handling where ambiguity has actual legal and monetary consequences.

An agency that hasn't navigated KYC/AML flows, built around PSD2 requirements, or designed for audit-trail visibility will learn all of this for the first time on your engagement. That's a risk most funded fintech companies can't afford.

Here's what this guide covers:

1. What makes fintech UX design genuinely different
2. How we evaluated the agencies on this list
3. Ten fintech design agencies in 2026 — who they are, what they specialize in, and what to expect on price
4. How to choose based on your product type and stage

For broader context on what good [fintech design](/blog/fintech-design-guide) requires before you start evaluating agencies, that breakdown is here.


## What fintech UX design actually requires

The four constraints that separate fintech UX from standard product design:

**Regulatory compliance in the interface.** KYC/AML, PSD2, SOC 2, GDPR, and jurisdiction-specific requirements aren't handled in the backend alone — they shape onboarding flows, consent architecture, data disclosure, and audit trail design. Designers who haven't worked within these constraints will create flows that legal will reject, or flows that technically comply but convert poorly.

**Financial data density.** A transaction history, portfolio breakdown, or payment dashboard can't be simplified the way a SaaS feature dashboard can. The information density is part of the product's value — users need to see it. The design challenge is making dense data readable, not removing it.

**Trust architecture.** In financial products, every visual decision communicates something about security and reliability. Typography, color usage, motion, empty states, and error messages all carry trust signals that non-financial designers underestimate. A single poorly worded error message during a payment flow can permanently damage user confidence.

**Error handling with legal weight.** In a SaaS product, a vague error message is a UX problem. In a fintech product, it can be a compliance problem, a chargeback trigger, or the first step in a fraud dispute. Error handling in financial products requires specificity that most design teams treat as an afterthought.

> The agencies that design fintech products well share one trait: they treat compliance and trust architecture as design constraints to work within, not legal problems to hand off.

A [UX audit](/blog/ux-audit-guide) against these four criteria is the fastest way to identify where an existing fintech product is failing before redesigning it.


## How we evaluated this list

**Fintech-specific case studies.** We looked for actual evidence of fintech product work: onboarding flows, dashboards, transaction screens, compliance handling. Marketing sites for fintech brands don't qualify.

**Regulatory and compliance awareness.** Does the agency's case study language show they understood the regulatory context, or are they presenting generic UX work that happened to be for a financial client?

**Verified reputation.** [Clutch](https://clutch.co/agencies/ui-ux) reviews with fintech context, longevity, and documented client work across the fintech spectrum.

**Pricing and process transparency.** Same standard as our other agency lists — agencies that are opaque on both aren't optimizing for client fit.


## Ten fintech design agencies in 2026

### 1. Masterly

**Best for: Fintech startups and scale-ups from Series A to Series D — AI finance, fintech SaaS, and B2B financial tools**

Full disclosure: our list, we're on it, same criteria applied.

Masterly is a design-led studio that works with funded fintech and SaaS companies. Our [fintech design practice](/services/fintech-design) covers the full product surface: landing pages that build trust before the first click, KYC and onboarding flows designed for conversion within compliance constraints, data-dense dashboards where risk, spending, and position data need to be readable under pressure, and transaction flows with clear state management and error handling.

Case work includes [Light](/cases/light-ai-finance-mobile-app-ux-ui-design-masterly-case-study) — an AI-powered personal finance app with smart budgeting, goal tracking, and daily AI-driven insights — and [Alterscope](/cases/alterscope-fintech-saas-platform-redesign-masterly-case-study), a real-time risk analytics platform taken from alpha to investor-ready in three weeks. Across 40+ products, client companies have raised $200M+ after our engagements, our UX work lifts conversion by an average of 38%, and the work has earned Red Dot Design Award recognition.

**Clutch:** 5.0/5 | **Pricing:** $4K–$16K/mo retainer, or fixed-scope projects | **Based:** EU (remote)


### 2. UXDA

**Best for: Banking, neobanks, and regulated financial institutions**

UXDA is the most fintech-specialized design agency on this list — financial UX is the only thing they do. Founded in Latvia, they've worked with banks, credit unions, neobanks, and financial service providers across Europe, North America, and the Middle East. Their portfolio is almost exclusively banking and financial apps — onboarding, mobile banking, wealth management, insurance.

The depth of domain knowledge is the value: they understand the regulatory constraints, the incumbent bank legacy system integrations, and the user trust dynamics specific to financial services in a way that takes generalist agencies years to develop. For traditional financial institutions or regulated neobanks, UXDA's specialization closes a knowledge gap that's otherwise expensive to fill.

**Pricing:** $50K–$200K | **Based:** Riga, Latvia (remote)


### 3. Clay

**Best for: Premium fintech brand and product design for well-funded companies**

Clay's fintech credentials are visible in the client list: Stripe, Coinbase, Credit Karma. Their work covers the full premium tier — brand identity, marketing sites, and product design — held together by a visual quality standard that's harder to achieve in regulated financial products than it looks.

For fintech companies where brand trust and design quality are part of the product's competitive positioning, Clay sets the benchmark. The price point reflects it.

**Clutch:** 4.8/5 | **Pricing:** $75K–$250K+ | **Based:** San Francisco


### 4. Momentum Design Lab

**Best for: Enterprise fintech — trading platforms, wealth management, and B2B payments**

Momentum Design Lab specializes in complex B2B software, with significant experience in enterprise financial products: trading interfaces, portfolio management tools, corporate treasury dashboards, and complex multi-persona financial platforms. Their strength is in data-dense, high-stakes interfaces where information hierarchy and error handling carry professional-grade consequences.

For consumer fintech, they're the wrong fit. For enterprise financial products where the interface is used by professionals under time pressure with real money at stake, their specialization in complexity has real value.

**Pricing:** $75K–$200K+ | **Based:** San Jose, CA


### 5. Eleken

**Best for: Continuous fintech design on a subscription model**

Eleken's SaaS-first, embedded designer model works well for fintech teams that need ongoing design capacity rather than a defined engagement. With 4.9/5 on Clutch from 125+ reviews and a SaaS-only positioning, they attract fintech clients across payment tools, financial dashboards, and B2B finance platforms. The embedded model means a dedicated designer works inside your product team — attending standups, inside your Figma files — rather than running parallel to it.

Best fit for teams with a PM or head of product who can direct design work day-to-day. Not the right model if you need strategic design leadership from the agency side.

**Clutch:** 4.9/5 (125+ reviews) | **Pricing:** ~$3,800–$9,500/month | **Based:** Kyiv (remote)


### 6. Fuzzy Math

**Best for: B2B fintech with complex data and enterprise workflows**

Fuzzy Math is a Chicago-based UX studio with a strong track record in B2B products — financial services, healthcare, and enterprise software. Their fintech work leans toward the data-heavy, workflow-intensive end: financial dashboards, reporting tools, and enterprise finance platforms where information architecture and task efficiency matter more than visual sophistication.

Strong for B2B fintech companies building internal tools, back-office platforms, or financial reporting products. Less suited for consumer-facing fintech where brand and visual quality carry more weight.

**Pricing:** $50K–$150K | **Based:** Chicago (remote)


### 7. Miquido

**Best for: Mobile-first fintech for European and emerging markets**

Miquido is a Polish product agency with a strong mobile fintech portfolio. Their work spans neobanking apps, payment platforms, and financial management tools — with particular depth in European market requirements (PSD2, GDPR, Open Banking) and mobile-first delivery. They cover design and development under one roof, which reduces integration overhead for fintech teams that want a single vendor.

**Clutch:** Top-rated | **Pricing:** $50K–$150K | **Based:** Kraków, Poland (remote)


### 8. Ramotion

**Best for: Fintech brand identity and product design**

Ramotion is a San Francisco studio with a practice that spans brand identity, product design, and web — with documented fintech work in the crypto and payments space. Their strength is in the intersection of brand trust and product clarity: making a financial product feel credible and premium before the user has read a word of copy.

Good fit for fintech companies at a stage where brand credibility and first impression are active conversion variables — Series A fundraising, product launches, market repositioning.

**Pricing:** $50K–$150K | **Based:** San Francisco


### 9. Thoughtbot

**Best for: Fintech products that need design and engineering delivered together**

Thoughtbot pairs UX and product design with engineering from day one — which is particularly valuable in fintech, where compliance requirements, API integrations, and security constraints shape what's designable before the first wireframe. Running design and development in the same engagement eliminates the handoff gap where compliance complexity typically gets lost.

Their fintech work spans payments, financial management, and B2B finance tools. For technical fintech founding teams who want one partner rather than coordinating between a design agency and a dev shop, the integrated model is worth the consideration.

**Pricing:** $50K–$150K | **Based:** Boston, New York, San Francisco (remote)


### 10. Neuron

**Best for: Enterprise B2B fintech and financial workplace tools**

Neuron is a San Francisco B2B-focused design team that works on enterprise software — including financial tools used in workplace contexts: internal banking platforms, financial operations software, and analyst-facing dashboards. Their thesis is that workplace software needs to make the people using it more effective at their jobs, not just usable — a meaningful distinction in financial contexts where professionals' output is measured in dollars and basis points.

**Pricing:** $50K–$150K | **Based:** San Francisco


## Consumer fintech vs. enterprise fintech: different agencies for different products

The distinction matters more in fintech than in most other verticals because the UX requirements are genuinely different.

**Consumer fintech** (neobanks, investment apps, personal finance, crypto wallets) demands high visual quality, friction-minimized onboarding, and emotional trust signals. Users chose your product; they can unchose it. UXDA, Ramotion, Miquido, and Clay are stronger here.

**Enterprise and B2B fintech** (treasury management, trading platforms, corporate payments, financial operations) demands data density, professional precision, and workflow efficiency. Users didn't choose your product — their employer did. Momentum Design Lab, Fuzzy Math, Neuron, and Thoughtbot are stronger here.

**AI-driven finance** (AI budgeting assistants, copilots for financial workflows, ML-powered analytics) cuts across both: it demands the data-density discipline of enterprise tools and the trust-building of consumer products, plus honest UX around what the AI can and can't do. Masterly's practice is focused here and on B2B fintech SaaS. For DeFi and crypto products specifically, Clay has documented work in the space.

If you're uncertain which your product is, run a [UX audit](/blog/ux-audit-guide) first — it will tell you which failure modes you're actually hitting before you commit to an engagement scope.


## How to find more agencies

This list covers ten agencies with verifiable fintech credibility at the time of writing. The fintech design agency space is not static.

[BrowseHub](https://browsehub.co) maintains a curated directory of vetted design agencies with filtering by specialization, pricing, and location.

[Clutch's fintech UX rankings](https://clutch.co/agencies/ui-ux/financial-services-industry) are the most reliable source of verified client reviews with project context — filter by industry to see agencies with documented financial services work.

For broader digital product agency options beyond fintech, see [Top Product Design Agencies 2026](/blog/top-product-design-agencies) and [Top SaaS Design Agencies 2026](/blog/top-saas-design-agencies).

---

### Top Product Design Agencies in 2026 (For Digital Products)
URL: https://www.themasterly.com/blog/top-product-design-agencies
Product Design · 2026-07-14

"[Product design](/glossary/product-design) agency" is one of the most overloaded phrases in the design industry. It covers industrial designers who build physical consumer goods, digital studios that design SaaS dashboards, and large consultancies that do both under one roof. Searching for one without being precise about what you mean returns a list that's mostly irrelevant.

This guide is specifically about digital product design — UX/UI for web applications, mobile apps, SaaS platforms, and tech products. Physical product design firms, branding-only studios, and marketing site agencies are excluded regardless of how they describe themselves.

Here's what this guide covers:

1. What separates a genuine digital product design agency from a generalist studio
2. How we evaluated the agencies on this list
3. Ten digital product design agencies worth knowing in 2026
4. How to choose based on your product type and stage

If your product is specifically B2B SaaS, we've written a more focused breakdown with SaaS-specific criteria: [Top SaaS Design Agencies 2026](/blog/top-saas-design-agencies).


## What makes a digital product design agency different

A digital product design agency's job is to design software that users can navigate, understand, and return to. That sounds basic — it's not. The gap between teams that understand this and teams that don't shows up in activation rates, feature adoption, and churn, not in portfolio screenshots.

The agencies that do this well share a few traits: they ask about user behavior before asking about brand, they build [design systems](/glossary/design-system) that engineers can actually maintain, and they measure success with product metrics rather than awards. They've also done it before — many times, across enough product types that they recognize patterns before they become problems.

A general creative agency can make a product look sophisticated. A digital product design agency makes it work.

> "Design is not just what it looks like and feels like. Design is how it works." — Steve Jobs

The [principles behind good SaaS UX design](/blog/saas-ui-ux-design-guide) apply broadly to any recurring-use digital product — worth reading before you shortlist agencies.


## How we evaluated this list

**Digital product case studies with depth.** We looked for agencies whose case studies show problem definition, design reasoning, and outcome context — not just polished final screens. Agencies with primarily brand, marketing, or illustration portfolios didn't qualify.

**Verified reputation.** A mix of [Clutch](https://clutch.co/agencies/ui-ux) reviews, industry recognition, and documented client work. Longevity matters here too — agencies that have sustained quality across multiple years and clients are lower risk than one-project wonders.

**Specialization or breadth with clear positioning.** Some agencies specialize narrowly (one vertical, one product type); others cover the full range of digital product work. Both can be excellent — what matters is that the positioning is honest and the portfolio backs it up.

**Transparency.** Agencies that share their process, pricing range, and decision-making frameworks publicly are usually easier to work with than those that optimize for pitch theater.


## Ten digital product design agencies in 2026

### 1. Masterly

**Best for: B2B SaaS, fintech, healthtech, and AI product teams from Series A to Series D**

Full disclosure: this is our list and we're on it. Same criteria applied.

Masterly is a design-led studio specializing in B2B digital product design: UX/UI for web and mobile and [design systems](/blog/design-system-decision-guide) your engineering team can build on — from onboarding and activation flows to the data-dense product interior. Our work spans DeFi platforms, two-sided marketplaces, AI-driven product tools, and health program brands, across verticals where UX is a competitive variable, not a production step. Across 40+ products, client companies have raised $200M+ after our engagements, and our UX work lifts conversion by an average of 38%. The work has earned Red Dot Design Award recognition.

We work as fixed-scope projects or ongoing monthly engagements, and we own the outcome either way. Series A through D, complex product problems, verticals where the audience has high expectations and low tolerance for friction.

**Clutch:** 5.0/5 | **Pricing:** $4K–$16K/mo retainer, or fixed-scope projects | **Based:** EU (remote)


### 2. Clay

**Best for: Premium digital product + brand design for well-funded tech companies**

Clay is a San Francisco studio that has become one of the most referenced names in premium digital product design. Their client list — Slack, Google, Facebook, Stripe, Amazon, Coinbase — reflects both their quality standard and their price point. Clay handles strategy, UX, visual design, and front-end development as parallel disciplines, which is why their output holds together from marketing site through product interior to mobile without the fragmentation that plagues multi-vendor engagements.

The work is genuinely distinctive, not just competent. If visual quality and technical precision both need to be at the top of the range, Clay is the benchmark.

**Clutch:** 4.8/5 (32 reviews) | **Pricing:** $50K–$200K+ | **Based:** San Francisco


### 3. IDEO

**Best for: Design thinking-led transformation and new product category creation**

IDEO is where modern design thinking as a methodology originated. They've been the reference point for human-centered design for decades, and their digital product practice applies that methodology to complex, ambiguous product problems — the kind where you don't yet know what you're building.

Their sweet spot is early-stage product strategy and category creation, not execution-speed. If you have a well-defined product and need quality execution, IDEO is likely the wrong fit and definitely the wrong price. If you're entering a new market, building a product category, or solving a genuinely novel user problem, their methodology is hard to replicate elsewhere.

**Pricing:** $200K+ | **Based:** San Francisco, Cambridge, New York, global


### 4. Frog Design

**Best for: Large-scale digital transformation for enterprise and established brands**

Frog has operated at the intersection of product strategy, UX, and technology since 1969 — first in industrial design, then increasingly in digital. Their current practice is focused on digital transformation: helping established enterprises redesign products, internal tools, and customer experiences at scale.

For a startup or Series A company, Frog is almost certainly the wrong choice — the model is built for enterprise timelines and budgets. For an established company undertaking significant digital transformation with meaningful resources, their combination of strategic depth and execution capability is real.

**Pricing:** $200K+ | **Based:** San Francisco, Austin, New York, global


### 5. Huge

**Best for: Enterprise digital product design with a data-informed approach**

Huge is a digital-native agency that combines product design, data strategy, and technology across large-scale digital engagements. Their clients are primarily enterprise — retail, financial services, media — and their work tends toward redesigning complex multi-surface digital ecosystems rather than building new products from scratch.

The data-informed approach is genuine: they use behavioral analytics to shape UX decisions throughout the engagement, not just at the research phase. A strong fit for established companies with existing digital products that need strategic redesign.

**Pricing:** $150K+ | **Based:** Brooklyn, NY (global offices)


### 6. Work & Co

**Best for: Digital product design for consumer tech, retail, and media companies**

Work & Co is a Brooklyn-based digital product agency with a focused, senior-heavy team model. Clients include Apple, Google, Twitter, Nike, and Condé Nast — a portfolio that reflects their strength in consumer-facing digital products with high design expectations.

Their distinguishing characteristic is team composition: fewer, more senior designers who own the work end-to-end rather than large teams with significant junior involvement. That model produces more consistent quality and tighter strategic alignment, at a premium price point.

**Pricing:** $100K–$300K+ | **Based:** Brooklyn, NY (Portland, São Paulo)


### 7. Instrument

**Best for: Digital product and brand design for technology companies**

Instrument is a Portland-based independent agency with a strong reputation in the Pacific Northwest tech ecosystem. Their work spans digital product design, brand identity, and interactive campaigns — with particular strength in the intersection of product and marketing, where the two surfaces need to feel like they come from the same design language.

Notable clients include Google, Nike, VSCO, and Dropbox. The agency is smaller and more nimble than IDEO or Frog, with faster cycles and a more hands-on principal involvement.

**Pricing:** $75K–$200K | **Based:** Portland, OR


### 8. Fantasy Interactive

**Best for: Premium digital product design for luxury, media, and consumer tech**

Fantasy is a San Francisco and New York agency known for producing some of the most visually sophisticated digital product work in the industry. Their clients include HBO, NFL, MIT, and Range Rover — a mix of luxury, media, and institutions with high aesthetic standards and resources to match.

They're not a SaaS or B2B agency — their strength is in consumer-facing digital products and brand-led interactive experiences. If your product competes on visual quality and experience distinctiveness, Fantasy is worth the consideration.

**Pricing:** $100K–$300K+ | **Based:** San Francisco, New York


### 9. Thoughtbot

**Best for: Product design paired with engineering for technical founders**

Thoughtbot is an engineering-first agency with a serious design practice built around it. Their model pairs UX and product design with development — which makes them particularly well-suited for early-stage technical products where design and engineering need to stay in lock-step rather than operating sequentially.

They've shipped hundreds of products across SaaS, fintech, healthcare, and consumer apps. For a technical founding team that doesn't want to manage a design-only agency plus a separate development partner, Thoughtbot's integrated model reduces coordination overhead significantly.

**Clutch:** Top-rated | **Pricing:** $50K–$150K | **Based:** Boston, New York, San Francisco (remote)


### 10. Designit

**Best for: Large-scale digital product design across complex enterprise organizations**

Designit is a global strategy and design agency (a Wipro company) with offices across Europe, the US, and Latin America. Their practice spans service design, digital product design, and organizational design — with clients including BMW, Ikea, Banco Santander, and Volkswagen.

The scale and global footprint make Designit a fit for organizations running multi-market, multi-platform product programs that need design consistency across geographies. For startups or companies that need fast, focused execution, the enterprise model and overhead won't be the right match.

**Pricing:** $100K–$500K+ | **Based:** Global (Copenhagen HQ)


## How to choose based on your stage and scope

**Seed and early Series A:** You need speed, low process overhead, and a partner who can make decisions with incomplete information. Avoid agencies whose model is built around extensive discovery phases, large team allocations, and formal sign-off cycles. Look at boutique studios with a strong track record in your vertical — Thoughtbot or similar-tier options depending on your product type.

**Series A to Series C:** You need process and system thinking. The deliverable should be something your in-house design function (current or future) can inherit, operate, and extend — proper component libraries, documented patterns, clean handoff. A [UX audit](/blog/ux-audit-guide) before the engagement is worth doing to scope the work accurately. Clay, Work & Co, and Instrument operate well at this tier; so do focused specialists like Masterly for B2B SaaS.

**Enterprise and Series D+:** Strategic transformation over execution speed. You need an agency that can operate at your organizational scale, manage multiple stakeholders, and maintain coherence across a complex product surface. IDEO, Frog, Huge, and Designit are built for this tier.

> The most expensive mistake in agency selection isn't hiring the wrong agency — it's hiring the right agency for the wrong stage. A Series D enterprise agency engaged at Series A produces a deliverable that's too slow to build, too rigid to iterate, and too expensive to justify.

For a SaaS-specific breakdown with more detailed criteria, see [Top SaaS Design Agencies 2026](/blog/top-saas-design-agencies).


## Finding more options

This list is a starting point, not exhaustive. The digital product design agency space is large and changes regularly — agencies grow, specialize, pivot, or get acquired.

[BrowseHub](https://browsehub.co) maintains a curated directory of vetted digital product design agencies with filtering by specialization, pricing, and location.

[Clutch's UX agency rankings](https://clutch.co/agencies/ui-ux) remain the most reliable source of verified client reviews with project size and industry context.

The right agency for your product is more likely to be found by matching on vertical expertise and stage fit than by shortlisting based on client logos. The logos tell you the quality ceiling. The case studies tell you whether they can help you specifically.

---

### Top SaaS Design Agencies in 2026 (Ranked by What Actually Matters)
URL: https://www.themasterly.com/blog/top-saas-design-agencies
Product Design · 2026-07-08

Most SaaS design agencies are chosen the same way: someone finds a name in a listicle, scans the portfolio, thinks "close enough," and signs the contract. The result is usually screens that look professional and fail to move activation.

This list is an attempt to fix that. We're Masterly — a design agency specializing in SaaS, fintech, healthtech, and AI startups — and we've included ourselves with the same criteria applied to everyone else. No padding the list with agencies we can't speak to. No omissions that make the competitive landscape look cleaner than it is.

Here's what this guide covers:

1. What makes a SaaS design agency different from a general UI/UX studio
2. The four criteria we used to evaluate agencies
3. Ten SaaS design agencies worth knowing in 2026 — who they are, who they're best for, and what to expect on price
4. How to choose based on your product stage

If you need the full breakdown of what SaaS UX design actually requires before evaluating agencies, [the principles are here](/blog/saas-ui-ux-design-guide).


## What makes a SaaS design agency different

SaaS design is not [UI design](/glossary/ui-design) applied to software. It's a specific discipline built around how users interact with products they use every day, under workflow pressure, often without choosing the product themselves.

A general design agency produces screens that look good in a presentation. A SaaS-focused agency knows what those screens need to do: reduce time-to-first-value, guide users to activation, support expert efficiency as the product matures, and scale through a [design system](/glossary/design-system) a growing engineering team can actually maintain.

The tell is what they ask about in the first conversation. A SaaS design agency asks about your activation rate, your onboarding drop-off, your core feature adoption. A general agency asks about your brand.

> "We started with quality. Then we learned that people actually noticed — because it's a rare approach, especially for startups." — Karri Saarinen, co-founder of Linear

That orientation — designing for the person who uses your product 200 times a year, not the person evaluating it once — is the thing that separates genuinely SaaS-literate agencies from the rest.


## How we evaluated this list

**SaaS case studies with product context.** Screenshots alone don't demonstrate SaaS expertise. We looked for agencies whose case studies show problem definition, design reasoning, and — where available — product outcome context. Agencies whose portfolio is primarily branding, marketing sites, and e-commerce didn't make the cut regardless of visual quality.

**Clutch reviews.** [Clutch](https://clutch.co/agencies/ui-ux/business-services-industry) is the most reliable source of verified B2B agency reviews. Volume matters less than specificity: 20 detailed reviews from real SaaS founders are more useful than 100 generic ratings.

**Specialization signal.** Does the agency's positioning show genuine SaaS focus, or is SaaS one vertical among many? Specialization compounds — agencies that have done 50 SaaS products understand patterns that generalists will rediscover on your budget.

**Transparency on pricing and process.** Agencies that are opaque about cost ranges or process on first contact are usually optimizing for closing, not for fit. Fit matters more than closing.


## Ten SaaS design agencies in 2026

### 1. Masterly

**Best for: B2B SaaS, fintech, healthtech, and AI product teams from Series A to Series D**

Full disclosure: this is our list, and we're on it. We've applied the same criteria to ourselves that we applied to everyone else.

Masterly is a design-led studio specializing in B2B SaaS, fintech, healthtech, and AI startups. We design end-to-end: [UX/UI for web and mobile](/services/ui-ux-design) and [design systems](/blog/design-system-decision-guide) your engineering team can build on — from onboarding and activation flows to the data-dense product interior. Our work spans DeFi yield platforms, two-sided real estate marketplaces, AI-driven proptech, and health program brands. Across 40+ B2B SaaS products, client companies have raised $200M+ after our design engagements, and our UX work lifts trial-to-paid and lead-to-call conversion by an average of 38%. The work has earned Red Dot Design Award recognition.

The positioning is deliberate: Series A to Series D, design-complex problems, verticals where UX is a competitive variable. We work as fixed-scope projects or an ongoing monthly retainer — whichever fits your stage — and we own the outcome either way. We're not the right fit for enterprise tooling or slow, process-heavy engagements.

**Clutch:** 5.0/5 | **Pricing:** $4K–$16K/mo retainer, or fixed-scope projects | **Based:** EU (remote)


### 2. Eleken

**Best for: Dedicated embedded SaaS design on a subscription basis**

Eleken works exclusively with SaaS companies. Their model is structured differently from most agencies: you get a dedicated senior designer (or small team) embedded directly into your product process — in your Slack, in your Figma files, syncing with your PM daily. No project scoping, no handoff ceremony. Monthly subscription, cancel when you're done.

With a 4.9/5 Clutch rating across 125+ verified reviews, the model has consistent demand from teams that need design continuity rather than a defined deliverable. Best fit for companies with a PM who can direct design work independently; less suited for teams that need strategic design leadership from the agency.

**Clutch:** 4.9/5 (125+ reviews) | **Pricing:** ~$3,800–$9,500/month | **Based:** Kyiv (remote)


### 3. Clay

**Best for: Premium brand + [product design](/glossary/product-design) for well-funded SaaS teams**

Clay is a San Francisco design studio that operates at the intersection of brand, UX, and front-end development. Their client list — Slack, Google, Facebook, Amazon, Stripe, Coinbase — tells you both the quality ceiling and the price floor. Work is technically precise and visually distinctive: not just dashboards and flows, but full brand and product systems that hold together from marketing site through product interior to mobile.

If you need everything to look like it was designed by one team with significant resources and high aesthetic standards, Clay is the reference point. Budget accordingly — this is not a pre-Series A engagement.

**Clutch:** 4.8/5 (32 reviews) | **Pricing:** $50K–$200K+ | **Based:** San Francisco


### 4. Qubstudio

**Best for: Research-led design for complex SaaS products**

Qubstudio is a digital experience design agency with Red Dot recognition and a structured UX research practice that precedes design — not as an upsell, but as the foundation of every engagement. For SaaS products with multi-persona user models, high technical density, or significant edge-case complexity, the discovery investment pays back in avoided redesigns.

Strong in data-heavy dashboards and workflow-intensive B2B products. Expect a thorough discovery process before pixels are committed.

**Clutch:** Top 100 Global | **Pricing:** $50K–$150K | **Based:** Lviv (remote)


### 5. Neuron

**Best for: B2B enterprise and workplace SaaS**

Neuron is a San Francisco-based design team that focuses specifically on B2B workplace products: SaaS platforms, internal tools, and enterprise software. Their thesis is that enterprise software needs to help companies succeed in measurable terms, not just be usable — which means designing for power users and administrative workflows, not for demos.

If your product targets operations teams, enterprise buyers, or internal tooling markets, Neuron's specialization in workplace software gives them a genuine edge over generalist studios. Not a fit for consumer-adjacent SaaS or marketing-heavy products.

**Pricing:** $50K–$150K | **Based:** San Francisco


### 6. UX Studio

**Best for: UX research-first design with validated testing before build**

UX Studio is a Budapest-based agency with a strong reputation in the research and strategy layer of product design. Their methodology centers on validating assumptions with real users before committing to design direction — concept testing, usability studies, and competitive research that inform the design rather than follow it.

Best fit for SaaS teams with a conversion or retention problem they can't diagnose from analytics alone. If you know what you want to build and need execution speed, they're not the fastest-moving option.

**Pricing:** $30K–$100K | **Based:** Budapest (remote)


### 7. Fuselab Creative

**Best for: B2B SaaS UX with a conversion and pipeline focus**

Fuselab Creative is a B2B-focused design agency that connects UX decisions directly to lead generation, trial conversion, and commercial metrics. Their work shows up consistently in SaaS evaluations for marketing sites, top-of-funnel flows, and product-led growth experiments where design is expected to produce measurable commercial output.

A good fit for teams where the brief is "our trial conversion is X, we need it to be Y" rather than a longer-horizon product design engagement.

**Pricing:** $25K–$75K | **Based:** Vancouver (remote)


### 8. Orbix Studio

**Best for: Early-stage B2B SaaS with tighter budgets**

Orbix Studio is a smaller agency with a perfect 5.0/5 on Clutch across 43 verified reviews — a rating that's harder to maintain at volume than it appears, and a meaningful signal. Their focus is B2B SaaS product design, with a $10,000+ project minimum that puts them within reach for early-stage companies.

Case studies show solid UX thinking without the premium visual production of the top-tier studios. A rational choice when you need a capable SaaS design partner and the budget doesn't stretch to $50K+.

**Clutch:** 5.0/5 (43 reviews) | **Pricing:** $10K–$50K | **Based:** New York (remote)


### 9. Momentum Design Lab

**Best for: Enterprise SaaS and complex multi-product systems**

Momentum Design Lab specializes in enterprise-grade UX for complex software: multi-module SaaS platforms, internal tooling, and large-scale product redesigns where design coherence needs to hold across multiple teams and workstreams. Their process is structured for enterprise timelines and stakeholder management requirements.

Not the fastest-moving option on this list — enterprise specialization comes with enterprise process overhead — but strong for the right scope.

**Pricing:** $75K–$200K+ | **Based:** San Jose, CA


### 10. Wavespace Agency

**Best for: Product-led growth SaaS with a metrics-forward brief**

Wavespace operates in the product-led growth space, with clients having collectively raised significant venture capital through Wavespace-designed products. Their work skews toward trial-to-paid conversion optimization, onboarding redesign, and pricing page architecture — design work scoped to commercial outcomes rather than full product builds.

Strong for teams with clear metrics to optimize toward. Less suited for early discovery where the right product direction hasn't been validated yet.

**Pricing:** $30K–$100K | **Based:** Remote


## How to choose based on your stage

**Pre-seed to seed:** Speed and founder alignment matter more than process. You need a team that turns ambiguous product direction into testable screens quickly, and thinks about UX problems the way a product person does — not a studio that runs six-week discovery phases before the first wireframe. Look at Orbix Studio or Eleken's subscription model depending on how your design needs are structured.

**Series A:** You need process and system thinking. The agency should build in a way your in-house design team — current or future — can inherit: proper component libraries, documented patterns, clean Figma organization. A [UX audit](/blog/ux-audit-guide) before the engagement scopes the work more accurately than a brief alone. Look at Masterly, Qubstudio, Neuron, or Clay depending on scope and budget.

**Series B and above:** At this stage, an in-house design function with targeted agency support is usually the right model. Agency engagements should be scoped to specific problems: a design system overhaul, a new product line, a conversion-focused redesign — well-scoped, high-craft work that Masterly takes on as a project or an ongoing retainer. If you're encountering [the design patterns that compound before Series B](/blog/series-a-saas-design-mistakes), address those before the next funding cycle.

> The most common mistake is hiring a Series B design agency at seed stage — you get process overhead, timeline friction, and a deliverable that's too polished to iterate on quickly.


## How to find more agencies

This list covers ten agencies we can vouch for at the time of writing. The SaaS design agency space is not static — agencies grow, narrow their specialization, change their pricing model, or acquire adjacent capabilities.

[BrowseHub](https://browsehub.co) maintains a curated directory of vetted design agencies with filtering by specialization, pricing range, and location — a useful starting point for comparison beyond this list.

For verified review data, [Clutch's UX agency rankings](https://clutch.co/agencies/ui-ux) are the most reliable source: verified client reviews, project sizes, hourly rates, and industry focus all in one place.


## What matters at the end

The five mistakes we see in agency selection: choosing on price without checking for SaaS case studies, choosing on portfolio aesthetics without looking at product reasoning, choosing without a clear scope definition that allows real comparison between proposals, choosing an agency whose process doesn't fit the team's operating rhythm, and hiring a design agency as a substitute for a product strategy conversation.

The agencies above have the SaaS domain knowledge to deliver real work. The right fit is mostly about your stage, your budget, and what you need the engagement to produce. If you know what you need and want to talk scope, [we're here](/services/ui-ux-design).

---

### SaaS UI/UX Design: The Complete Guide for Product Teams
URL: https://www.themasterly.com/blog/saas-ui-ux-design-guide
Product Design · 2026-07-01

Most B2B SaaS products are designed for demos and sales calls. The people who use them every day are an afterthought.

That's not an accident — it's a predictable consequence of how SaaS products get built. Founders optimize for the moments that close deals. Engineers build for the use cases that get reported in tickets. Designers polish the screens that show up in investor decks. Meanwhile, the daily user — the person who opens your product at 9am and closes it at 6pm — inherits whatever's left.

[Karri Saarinen](https://linear.app/method), co-founder of Linear, built the entire company around rejecting this:

> "We started with quality. Then we learned that people actually noticed, because it's a rare approach — especially for startups."

Linear didn't win by moving faster than Jira. It won by building for the person who uses the product 200 times a year, not the person evaluating it once.

Here's what this guide covers:

1. Why B2B SaaS design is fundamentally different
2. The Masterly SaaS UX Model: five principles for resident users
3. The patterns that have the highest documented impact
4. How to measure UX quality (and what most teams track instead)
5. What the best SaaS products do that others copy but rarely understand


## SaaS users are residents, not tourists

Consumer apps serve tourists. Someone opens Instagram, Spotify, or Uber for a few minutes — novelty matters, the first impression is nearly everything. If a feature is hard to find, most users just don't use it.

B2B SaaS serves residents. Someone opens your product at 9am, works inside it until 6pm, and comes back tomorrow. They are executing — running a workflow, closing a ticket, reviewing a pipeline — not exploring. They become deeply familiar with the interface, develop opinions about it, and notice every small inefficiency.

This changes the design contract entirely.

A feature that takes four clicks to reach is tolerable the first time. Over 200 sessions it becomes friction that erodes satisfaction, slows output, and eventually shows up in your churn data. Conversely, information density — which looks overwhelming to a first-time user — becomes a productivity advantage once someone knows what they're looking at.

Consumer UI intuitions backfire here. The B2B designer's job is not to minimize friction for a newcomer. It's to make the product faster and more powerful over time.


## The Masterly SaaS UX Model

Five principles that separate products built for residents from products built for screenshots.

**1. Efficiency compounds.** The best SaaS interfaces get faster with use. Keyboard shortcuts, command palettes, saved filters, and persistent state turn a capable product into an extension of how someone thinks. Design for the person who has used your product 500 times, not the one who just signed up.

**2. Roles are different users.** An admin configuring SSO, a manager reviewing team workload, and a contributor closing tasks are not the same person. Serving them one interface consistently underserves all three. Role-based default views, gated complexity, and contextual toolbars reduce cognitive load for everyone.

**3. Progressive disclosure, always.** [Jakob Nielsen at NNG](https://www.nngroup.com/articles/progressive-disclosure/) defined this in 2006: defer advanced or rarely used features to secondary screens. The implementation challenge is getting the split right — too much deferred and experts feel constrained; too little and new users feel overwhelmed. The answer is almost always to defer more than feels comfortable initially.

**4. Empty states are activation moments.** A blank screen on first login is not a neutral experience — it's the highest-friction moment in your entire product. NNG's guidelines are clear: an empty state should communicate status, demonstrate the product's purpose, and provide one direct path to the primary action. Trello's "Create your first board," Notion's template quiz, Intercom's guided first message — all of them treat emptiness as an onboarding surface.

**5. Errors are product quality.** Poor error handling is the most common signal that a product was designed for the happy path only. Nielsen's heuristic #9: errors should be expressed in plain language (no codes), identify the problem precisely, and offer a constructive solution. The gap between products that preserve user work and recover gracefully and those that don't is enormous — and entirely visible to daily users.


## The patterns that move the metrics

These are the most-documented high-impact patterns in B2B SaaS, with evidence.

**Onboarding: optimize for first value, not feature coverage**

Average SaaS activation is [37.5% (Userpilot benchmark, 62 B2B SaaS companies)](https://userpilot.com/blog/user-activation-rate/). That means roughly 2 of every 3 signups never reach the moment your product delivers value. The gap between median and top-quartile products is almost entirely explained by onboarding quality.

[Des Traynor](https://intercom.com), co-founder of Intercom:

> "We can't hit you with all the power upfront. The first few steps should be simple and they should demonstrate the product value early."

The failure pattern is consistent: long onboarding checklists (average completion rate: 19.2%, median 10.1% per Userpilot's 2025 benchmark of 188 companies), feature tours that walk users through every button before they've seen any value, and generic flows that treat a developer and a marketing manager identically.

The fix is conceptually simple: get users to their first meaningful outcome as fast as possible. Notion's onboarding quiz — role, team size, use case — then serves 5 relevant templates instead of a blank canvas. That single design decision converts the most paralyzing moment in a flexible tool into a guided start.

Limit onboarding to 3–5 steps. Trigger guidance contextually. Personalize by role. Everything else can wait until after the user has seen value. A deeper breakdown of what this looks like in practice: [high-converting SaaS onboarding patterns](/blog/saas-onboarding-ux-guide).

**Feature adoption: the 80/20 problem**

[Pendo's 2019 Feature Adoption Report](https://www.pendo.io/resources/the-2019-feature-adoption-report/) (615 products, 1+ year of data) found that 80% of features are rarely or never used, while 12% of features generate 80% of daily usage volume. An estimated $29.5 billion in public cloud R&D was spent on features that don't get used.

This isn't a product strategy problem in isolation — it's a design and discoverability problem. Most of those unused features exist. Users just don't know about them or can't find them when they're relevant.

Intercom's insight is instructive: when Microsoft asked users what features to add to Office, roughly 90% of requests were for features that already existed. The product had failed to onboard users onto the right features at the right time.

Progressive disclosure and contextual guidance (tooltips triggered when a use case becomes relevant, not upfront) are the structural answers. The [design system](/blog/design-system-decision-guide) underneath them is what makes those answers consistent across a growing product.

**Command palettes: power-user table stakes**

Linear, Slack, GitHub, Notion, Figma, Vercel — every product competing for keyboard-first power users ships a command palette (Cmd+K). It's no longer a differentiator. Its absence is a friction signal.

The pattern does two things simultaneously: it surfaces every action in one place (reducing navigation overhead) and it teaches keyboard shortcuts inline. Superhuman's implementation surfaces the shortcut next to each command — every time a user executes an action via the palette, they see the shortcut that could have been faster. Over time, power users migrate off the palette entirely.

Best practice: one global shortcut everywhere, context-aware results (on a customer record, "send email" should assume that customer), recent commands surfaced on open, no conflation with search.

**Data tables: the underrated core surface**

For most B2B SaaS products, a data table is the primary interface — the place users spend most of their time. It deserves more design attention than it typically receives.

High-impact specifics: left-align text, right-align numbers (scannable at a glance), fixed headers and pinned identifying columns when scrolling, hover-revealed checkboxes for bulk selection, contextual bulk-action toolbars that appear after selection (not permanently, which wastes space), inline editing triggered by clear affordances, and adjustable display density. Jira's bulk-change wizard — select → choose fields → resolve conflicts → review → apply — is the reference implementation for complex bulk operations.

**Role-based interfaces: serve every user, not the average**

HubSpot is the most cited multi-persona reference: buyers and leaders get ROI dashboards and pipeline summaries; daily users get task-driven interfaces; admins get a governance and permissions layer. Each role gets a default view built for how they actually use the product.

The common failure is designing for the average user — which means the interface is 60% relevant to everyone and 100% relevant to no one. Gate complexity by permission so adding more roles never increases cognitive load for existing ones.


## How to measure SaaS UX quality

Most teams measure UX through NPS and support ticket volume — both lagging indicators that tell you what already happened, not what's about to.

The NNG CASTLE framework was built specifically for workplace software where users don't choose the product. CASTLE: **C**ognitive load, **A**dvanced feature usage, **S**atisfaction, **T**ask efficiency, **L**earnability, **E**rrors. Google's HEART framework (which CASTLE was designed to complement) works for consumer products; CASTLE accounts for the coercion context of enterprise software.

| | NNG CASTLE | Google HEART |
|---|---|---|
| **Best for** | B2B enterprise / SaaS | Consumer apps |
| **Accounts for coerced use** | Yes — built for "users can't choose the product" | No |
| **Dimensions** | Cognitive load, Advanced feature usage, Satisfaction, Task efficiency, Learnability, Errors | Happiness, Engagement, Adoption, Retention, Task success |
| **Primary signal** | Task efficiency + error rate | Engagement + retention |
| **When to use** | Enterprise software, internal tools, B2B SaaS | Consumer mobile, social products, content platforms |

The leading metrics that predict retention before it shows up in churn:

**Activation rate** — the percentage of signups who reach a defined first-value event. The benchmark to beat: 40%+ (top quartile per Userpilot). Below 25%: onboarding is your only investment that matters right now.

**Time-to-first-value (TTV)** — how long from signup to the first moment the user gets value. Userpilot's 2024 benchmark (547 SaaS companies): average TTV ~1.5 days, with wide variance by category. AI products reach value in hours; HR products in days.

**Core feature adoption** — the percentage of users who engage with the features that predict retention. Userpilot found average core-feature adoption of 24.5% across 181 companies. If fewer than 1 in 4 users touches your core feature, the product either isn't reaching the right users or isn't getting them there.

**90-day retention** — Amplitude's 2025 benchmark (2,600+ companies, 10,600+ products): top 10% of products retain 18.5% of users at 3 months vs. a 3.8% median. A 7% day-7 return rate puts a product in the top quartile.

Shreyas Doshi, former product leader at Stripe:

> "Good PMs are detail-obsessed, making sure that the product meets the desired quality bar for launch. Great PMs pay this degree of attention to the entire customer experience: they know that the documentation, the API, the blog post, the website, the canned responses, etc. are also the product."

The word "product" in that quote is doing a lot of work. UX quality isn't just the interface — it's every touchpoint a user has with the product. Measuring it requires tracking the whole journey, not just screen-level satisfaction scores.


## What the best SaaS products understand

[McKinsey's Business Value of Design study](https://www.mckinsey.com/capabilities/mckinsey-design/our-insights/the-business-value-of-design) (300 companies tracked over 5 years, 2M+ financial data points) found that top-quartile design organizations achieved 32 percentage points higher revenue growth and 56 percentage points higher total returns to shareholders than industry peers. More than 40% of those companies weren't talking to end users during development. Fewer than 5% of leaders felt they could make objective design decisions.

The gap isn't talent. It's process and measurement. Companies that treat design with the same rigor as revenue — that tie design decisions to activation rates, feature adoption, and retention, not to how good the product looks in a demo — consistently outperform those that don't.

The products that get cited in this guide — Linear, Stripe, Figma, Notion, Intercom — share one trait: they designed for the person who uses the product every day, not the person evaluating it for the first time. That orientation shows up in every decision, from command palette implementation to error message copy.

It's available to any team that makes it a priority. Most don't, which is precisely why it's still a competitive advantage.


## Where to go from here

If you're reading this as a CPO or founder and your activation is below 40%, start with a [UX audit](/blog/ux-audit-guide) — a structured review of where users drop off, what they don't find, and what's working. That tells you where to invest before you commit engineering cycles to a redesign.

If you're at Series A and your design process is still founder-led, we've written specifically about [the five SaaS design mistakes that compound quietly before your Series B](/blog/series-a-saas-design-mistakes).

The question isn't whether SaaS [UX design](/glossary/ux-design) matters. The data on that is settled. The question is whether your team is measuring it with enough precision to act on.

---

### What Series A SaaS Teams Get Wrong About Product Design
URL: https://www.themasterly.com/blog/series-a-saas-design-mistakes
Product Design · 2026-06-30

> "When we see startups pitch product-led growth as their primary GTM strategy with zero product design experience on the team, it's an immediate red flag."

That's [Sandhya Hegde](https://www.unusual.vc/field-guide/how-to-hire-a-product-designer-for-early-stage-startups), General Partner at Unusual Ventures. She's not talking about taste. She's talking about survival.

Most Series A SaaS teams are making the same [product design](/glossary/product-design) mistakes right now — not because they don't care, but because they have the wrong mental model of what SaaS UX design actually is. It's not decoration. It's the structure of how your product works. And when that structure is wrong, no amount of visual polish fixes it.

These are the five mistakes we see most often, what they actually cost, and what to do instead:

1. Treating UI polish as a UX solution
2. Designing for demos, not for daily users
3. Building features without validating the UX first
4. Skipping the design system
5. Treating onboarding as an afterthought


## Why Series A is the inflection point

At Seed, speed is the right priority. You're validating assumptions, cutting corners, shipping to learn. [Design debt](/glossary/design-debt) is almost always the correct trade-off at that stage.

At Series A, the priorities change. Now you're optimizing for activation, retention, and conversion at scale. The product that got you here — with its founder-logic UI, inconsistent patterns, and shortcuts — isn't the product that gets you to Series B. The design decisions you deferred at Seed start compounding against you, quietly, in churn metrics and activation rates that don't respond to engineering work alone.

This is the moment most teams double down on the wrong things.


## Mistake 1: Treating UI polish as a UX solution

This is the most expensive mistake in SaaS design, and the hardest to see from the inside.

Your designer ships beautiful screens. Investors say the product looks great. The sales team uses the new UI in demos and it closes deals. Everything feels like momentum.

Then six months later, activation is flat. Power users complain they can't find things. Support tickets are rising. Churn is quietly accelerating.

What happened: the team hired UI designers to solve UX problems. The screens look polished, but the architecture — the information structure, the user flows, the mental models — is broken. As one UX practitioner put it bluntly:

> "Most companies hire UI designers to solve UX problems, then wonder why their beautiful app has terrible retention."

This happens because UI is visible and UX is structural. A founder can point to a screen and say "make this better." UX requires understanding why users navigate the way they do, what they're actually trying to accomplish, and where friction exists in their real workflow — before touching a single pixel.

The signal: if your design reviews spend more time on visual details — spacing, color, font weight — than on flow, task completion, and drop-off points, you have a UI team doing UX work. They're optimizing the wrong variable.

The fix isn't hiring more designers. It's changing what design is measured against. Activation rate. Time-to-first-value. Trial-to-paid conversion. Those are UX metrics, not UI metrics, and they need to be the brief. If you're not sure where your product's UX breaks down, a [structured UX audit](/blog/ux-audit-guide) is usually the fastest way to find out.


## Mistake 2: Designing for demos, not for daily use

B2B SaaS products serve multiple audiences simultaneously: the executive buyer who approved the budget, the admin who manages configurations, and the daily users who live inside the product every working day.

Series A teams almost universally prioritize the first group. Dashboards get packed with analytics, KPI summaries, and executive-level reporting that looks impressive in a 45-minute sales call. The daily user experience — the workflows people repeat dozens of times a week — gets neglected in favor of the demo.

The result is a specific and painful churn pattern: the product sells well but retains poorly. The champion who signed the contract is satisfied. The people actually using it quietly stop using it. Renewal conversations get difficult.

Part of this is Conway's Law in practice. Startups build UIs that mirror their internal team structure rather than user tasks. Navigation is named after engineering concepts or internal departments instead of what users are actually trying to do. The product makes perfect sense to the people who built it — and confuses everyone else.

> "Founders build interfaces that mirror system architecture instead of user goals."

The user is not the person who understands your system. The user is the person who needs to accomplish a task.

The discipline required: separate your demo environment from your product metrics. Let your sales team have what they need to close deals. Measure the product team on what daily users actually do — activation, feature adoption, session frequency, and retention. Those two scorecards will often point in different directions. Follow the retention one.


## Mistake 3: Building features without validating the UX first

The sequence matters more than most teams realize.

The typical build order at a Series A startup:

1. Engineer a solution
2. Design the UI
3. Ship it
4. Wait for feedback

The correct order:

1. Understand what the user is actually trying to accomplish
2. Validate the flow and structure before designing
3. Design the interface
4. Build

The trap is designing for yourself. Founders understand their product deeply — the backend logic, the data model, what every setting does. That knowledge creates a blind spot. They build interfaces that make perfect sense to someone who knows the system and are confusing to everyone else. The product feels intuitive to the team that built it and opaque to everyone who didn't.

One 30-minute user interview can kill a bad flow before engineering spends three weeks building it. Every hour spent in discovery saves three to five hours in redesign. This isn't a design principle — it's a math problem.

The minimum viable process: before any new feature goes to design, someone on the team needs to have watched a real user attempt to accomplish the relevant task. Not assumed what they'd do. Watched.


## The business case: what the numbers say

Before continuing, the ROI context is worth establishing — with one honest caveat.

[McKinsey tracked 300 companies](https://www.mckinsey.com/capabilities/mckinsey-design/our-insights/the-business-value-of-design) over five years and found that top-quartile design organizations achieved 32 percentage points higher revenue growth and 56 percentage points higher total shareholder returns than their peers. These aren't SaaS-specific figures — the study covers medical technology, consumer goods, and retail banking. But the directional logic holds.

The SaaS-specific mechanisms are concrete:

**Activation:** Better onboarding and first-session UX converts more trials to paid. Even a modest improvement in trial-to-paid conversion — say, from 8% to 14% — compounds significantly at scale without adding a single dollar to acquisition costs.

**Retention:** UX friction is a leading indicator of churn. Users who can't accomplish their goal in a reasonable number of steps don't stay. They cancel quietly at renewal.

**Engineering velocity:** Uber rebuilt their [design system](/glossary/design-system) in 2018 and cut feature delivery time from 8 weeks to approximately 2.3 weeks. Not by adding engineers — by eliminating the design fragmentation that was making every sprint slower.

[Tomer London](https://designerfund.com/bridge/a-founders-guide-to-the-first-design-hire/), co-founder of Gusto, put it plainly:

> "Design is still the most under-appreciated part of what makes startups win. Truly understanding that puts you ahead of 90% of the competition."


## Mistake 4: Skipping the design system

This one has a slow fuse.

At Series A, your product typically has three to five major flows, each built at different times by different people under different constraints. Buttons look slightly different across sections. Modals behave differently depending on where you are. Error states are inconsistent. Color usage is arbitrary.

Users notice this — even when they can't articulate it. Inconsistency signals instability. In B2B SaaS, where trust is foundational to the product relationship, visual and behavioral inconsistency erodes that trust more than founders expect.

[Jeff Kalmikoff](https://review.firstround.com/what-to-do-when-youre-the-only-designer-theyve-got/), who served as first or sole designer at Digg and SimpleGeo, described the debt problem directly:

> "If you don't take on design debt the same way engineers take on technical debt, you're not going to be able to make progress at the same rate."

He wasn't being abstract — he was describing the moment when every new feature takes longer than it should because every team is making the same low-level decisions from scratch.

Without a shared component library, developers rebuild slightly different versions of the same elements repeatedly. Research suggests teams without [design systems](/blog/design-system-decision-guide) ship up to 52% slower. That's not a UX problem in isolation — it's a business velocity problem.

The investment required at Series A is real but bounded: roughly $50K–$100K to build a foundational system. Within 6–12 months, that typically pays for itself in recovered engineering hours alone — not counting the retention benefit of a more coherent product experience.

The common objection is timing: "we'll do it when we have a bigger team." This gets it backwards. The bigger the team gets without a system, the more expensive the system becomes to build. Build it while the codebase is still manageable.


## Mistake 5: Treating onboarding as an afterthought

Onboarding is where retention is won or lost. Not in the core product — in the first session.

The most common failure pattern: users log in for the first time and see an empty dashboard. No data, no guidance, no clear next step. In our experience reviewing onboarding flows across B2B SaaS products, the majority present new users with a blank state and expect them to figure out what to do next.

The pattern compounds. Feature-first onboarding tours that walk users through every button before they've seen any value. Generic flows that treat a developer and a marketing manager identically. No clear next step after the first successful action. Each additional minute of required onboarding reduces trial conversion by approximately 3%.

A 12-step onboarding flow isn't just slow — it's directly destroying revenue. The math is merciless.

The teams who get this right operate on a single principle: get users to their first meaningful outcome as fast as possible. Everything else — secondary features, account configuration, advanced settings — waits until after the user has seen the value of the product for themselves. We've written a detailed breakdown of what [high-converting SaaS onboarding](/blog/saas-onboarding-ux-guide) actually looks like if you want to go deeper.

[David Dat Nguyen](https://review.firstround.com/the-ultimate-guide-to-the-founding-designer-role/), first designer at Gusto:

> "If you wait to start thinking of structure when the team is larger, it's already too late."

Onboarding is structure. If it isn't designed deliberately from the start, it gets bolted on later — and it never works as well as it would have if it had been built into the product's architecture from the beginning.


## What the right design motion looks like at Series A

Teams that get design right at this stage share a few characteristics.

They treat design as a business function, not a delivery function. Design decisions are tied explicitly to activation rates, trial-to-paid conversion, and retention — not to how good the product looks in a screenshot or a sales demo.

They validate structure before building. Discovery and flow definition happen before anything goes into Figma. User interviews happen before engineering begins. The process sounds slow; it's actually faster, because it eliminates the expensive redesign cycles that happen when you skip it.

They invest in systems early. Not perfect systems — just enough standardization to prevent the fragmentation that will slow down every engineer and designer who joins after Series A.

They separate what the sales team needs from what the product team is measured on. Both matter. They're not the same thing.

And critically: they have someone responsible for this who isn't also responsible for everything else. Founder-led design works at Seed. It breaks at Series A — not because founders can't design, but because they can't also be designing while running fundraising, hiring, and customer conversations simultaneously.


## A note on how you resource this

There's a practical question underneath all of this: who does the work?

| | Full-time hire | Freelancer | Embedded team |
|---|---|---|---|
| **Cost** | $13.5K–$18K/mo loaded | $20–$40/hr, variable | $4K–$7K/mo T&M |
| **Time to start** | 2–4 months to hire | 1–2 weeks | Days |
| **Context retention** | High — but takes 3–6 months to build | Low — resets each engagement | High — compounds over time |
| **Management overhead** | High (HR, onboarding, career pathing) | High (briefing, reviews, re-onboarding) | Low — integrates into your workflow |
| **Best for** | Series B+ with stable roadmap | Isolated one-off tasks | Series A–B moving fast |

Full-time senior designers carry a fully-loaded cost of $13.5K–$18K per month — salary plus benefits, taxes, and overhead. Add 2–4 months to hire and another 3–6 months before they're genuinely effective. That's a significant runway commitment during a period when priorities are still shifting.

Freelancers look cheap at $20–$40/hr, but the math changes when you factor in management overhead, re-onboarding every engagement, and the context that evaporates between projects. At 80 hours a month, you're paying $1.6K–$3.2K for fragmented, part-time attention with no continuity.

An embedded team at $4K–$7K/month delivers senior output, accumulates product context over time, and costs 40–60% less than a full-time hire — without the recruiting cycle.

The [embedded design team](/blog/embedded-design-team-guide) model — a dedicated senior designer (or a small embedded team) integrated directly into your product workflow, your Figma, your standups — exists because the timing problem at Series A is real. You need senior-level execution now, without the overhead of a full hiring cycle.

This is how we work with Series A and Series B teams at Masterly. If you're at that inflection point and want to understand what the right design motion looks like for your specific product and stage, [the conversation starts here](/services/embedded-design-team).

---

### What Is Growth Design? (And Why the Consumer Playbook Breaks in B2B SaaS)
URL: https://www.themasterly.com/blog/what-is-growth-design
Product · 2026-06-18

Every time someone asks "what is [growth design](/glossary/growth-design)?", they get the same answer.

A definition borrowed from [Growth.Design](https://growth.design/about). A case study about Duolingo's streaks. A mention of Slack's 2,000-message [activation](/glossary/activation) threshold. And then a vague conclusion that growth designers are like product designers, but more data-driven.

That content isn't wrong. It's just written for consumer apps.

If you're a CPO or VP Product at a Series B–D SaaS company — where your product serves multiple stakeholders, deals with procurement, lives inside someone's company infrastructure, and grows through account expansion rather than viral sharing — most of what you'll read about growth design is not designed for you.

This article is.

## What Growth Design Actually Is

Growth design emerged as a named discipline around 2018–2019, when designers embedded in growth teams at Airbnb, Dropbox, and Pinterest began formalizing what made their work different from traditional product design.

The most widely cited definition comes from Growth.Design's Dan Benoni: _"a process at the intersection of Growth (a scientific method to improve business metrics) and Design (a human-centered process used to solve problems)."_

[Angel Steger's 2019 interview with First Round Review](https://review.firstround.com/defining-growth-design-the-guide-to-the-role-most-startups-are-missing/) — the canonical text on the discipline — put it in operational terms: traditional product teams "own particular surfaces" — a dashboard, an onboarding screen. Growth designers "own user problems more generally" and traverse the entire product to move a specific metric.

Two things all definitions agree on:

-   Growth design is **outcome-focused**, not output-focused. The deliverable isn't a screen — it's a measurable change in user behavior.
-   It's **experiment-driven**. [Approximately 10% of growth experiments produce a statistically significant positive result](https://www.reforge.com/blog/growth-experiment-management-system). That's not a failure rate — it's the operating model. You learn from 90% of your tests even when they don't win.

What the field disagrees on is almost everything else — which tells you it's still young and fragmented. There's no single canonical framework, no accreditation, no consensus on what a growth designer's job title should be. The field was born at Airbnb, Facebook, and Dropbox. It was popularized through a handful of case studies. And it's been misapplied to B2B ever since.

## Growth Design vs. UX Design: The Actual Difference

The common framing — "growth designers are UX designers who care about metrics" — is technically accurate but operationally useless.

Here's the cleaner distinction:

| Dimension | Traditional UX / Product Design | Growth Design |
| --- | --- | --- |
| What success looks like | Usability, aesthetics, design system consistency | Activation rate, Day-30 retention, account expansion |
| Scope of ownership | A surface — a specific screen, flow, or feature | A user problem or metric, spanning the entire product |
| Validation method | Qualitative research, usability testing, stakeholder review | Live A/B experiments, multivariate testing, in-market iteration |
| Relationship to design systems | Strict adherence to established patterns | Dynamic exploration of pattern variations to test behavioral hypotheses |
| Tolerance for imperfect work | Low — aims for polished, comprehensive releases | High — ships lightweight versions to gather behavioral data fast |
| Definition of done | Design approved and shipped | Experiment ran, results measured, learning applied |

The key word is _hypothesis_. A growth designer doesn't ship a redesigned onboarding flow — they ship a hypothesis ("if we reduce this flow from 7 steps to 3, Day-7 retention will increase by X%") and measure it.

[Kate Syuma](https://uxdesign.cc/from-ux-to-growth-design-5-principles-to-multiply-your-value-81278d4d3735), former Head of Growth Design at Miro, frames it this way: the value of a design is measured by its impact on business growth, not aesthetic beauty or consistency alone. That's not anti-craft — it's a different frame for what craft is _for_.

## Why the Consumer Playbook Breaks in B2B

The dominant growth design canon was built at consumer companies — Airbnb, Dropbox, Duolingo, Pinterest, Spotify. That's where the discipline matured, where the frameworks were codified, and where almost all the documented case studies come from.

The problem: consumer apps and B2B SaaS have fundamentally different growth mechanics.

In a consumer app, the unit of growth is the **individual user**. Design for one person. Get them to their aha moment. Trigger a habit. Enable sharing. Repeat.

In B2B SaaS, the unit of growth is the **account**. And an account contains multiple people with different roles, different needs, and different definitions of value:

-   The **economic buyer** (CFO, Head of Engineering, IT) cares about security, compliance, ROI reporting, and switching costs.
-   The **product champion** (the designer, PM, or analyst who will actually use the tool daily) cares about speed, low cognitive load, and whether the product makes their job easier.
-   The **end users** (everyone the champion invited) care about not being forced to change their workflow unless it obviously improves it.

Growth design that optimizes for one of these people and ignores the others doesn't work. Designing a slick individual onboarding experience but leaving the admin portal as a spreadsheet in disguise doesn't produce expansion. Designing gamified daily streaks for a B2B analytics tool alienates the economic buyer faster than any sales objection.

There are also structural B2B constraints that consumer playbooks don't address:

**Longer, non-linear funnels.** B2B buying cycles involve multiple touchpoints across weeks or months. The aha moment rarely happens in the first session.

**Team-based activation.** In Slack's case, the aha moment isn't one person sending a message — it's a team sending 2,000 messages. That's a collaborative behavior, not an individual one. No amount of personal gamification gets you there.

**Land-and-expand economics.** In B2B SaaS, net revenue retention (NRR) — how much revenue you retain and expand within existing accounts — is frequently more important than new logo acquisition. Growth design that ignores expansion is leaving the most valuable lever untouched.

**Regulated environments.** In fintech, healthtech, and enterprise software, aggressive permission prompts, notification stacks, and artificial urgency create compliance risk and erode institutional trust.

## The Masterly B2B Growth Design Model: Hook, Hold, Harden, Harvest

Consumer growth design has one primary job: get the individual user to their aha moment fast. In B2B SaaS, that's just the first of four jobs.

We use four design moments to think about B2B growth. Each requires different design decisions, different success metrics, and a different understanding of who you're actually designing for.

### Hook — Individual activation (TTFV)

The first design moment is getting the individual champion — the person who chose your product and is trying to make it work — to experience genuine value as fast as possible.

In B2B SaaS, this means designing for **Time to First Value (TTFV)**. The goal is not a product tour or an empty dashboard with encouraging copy. It is one real work moment: importing data, connecting an integration, completing a task the user was going to do anyway — inside your product, in under three minutes.

Miro's approach illustrates the failure mode: their growth team ran over 20 consecutive experiments on their onboarding flow before finding a single statistically significant positive trend. Most of those failures were designs that tried to explain the product instead of letting the user experience it.

Hook is not about delight. It's about collapsing the gap between "signed up" and "did something real."

### Hold — Team activation

The second design moment is where B2B growth design fundamentally diverges from the consumer playbook.

In B2B SaaS, individual activation is a precondition — not the destination. If the champion is activated but their team isn't, the product churns. Growth design for B2B has to manufacture the conditions for team activation: collaboration triggers, shared workspaces, invitation mechanics that feel natural rather than forced.

Slack's original onboarding redesigned workspace setup to immediately connect new users with coworkers in channels. The metric they found that predicted whether a team would stay: 2,000 messages sent. Once a team crossed that threshold, 93% of them were still using Slack — [as CEO Stewart Butterfield described to First Round Review](https://review.firstround.com/defining-growth-design-the-guide-to-the-role-most-startups-are-missing/). The product was designed to get teams to that threshold as fast as possible — not individual users, teams.

The Hold moment requires designing for the social dynamics of a team, not just the behavioral psychology of a single person.

### Harden — Deep embedding

The third design moment is one most growth designers don't explicitly design for — but every B2B product eventually depends on.

Hardening is the process by which your product moves from "tool we use" to "infrastructure we depend on." It happens through data accumulation, workflow integration, institutional knowledge, and switching cost. Growth design can accelerate this by making it easy to go deep.

Notion's freemium model illustrates this: offering a generous free personal tier with unlimited pages before pushing team upgrade prompts. Users built extensive personal databases, and by the time the collaboration limit appeared, switching felt costly. The product had become infrastructure before it asked to be paid for.

Linear's approach is arguably more instructive for B2B teams: an opinionated, minimalist interface with progressive disclosure and fast keyboard shortcuts that create deep workflow habits. [The product achieved a $400M valuation on a $35,000 lifetime marketing budget](https://www.eleken.co/blog-posts/linear-app-case-study) — almost entirely through word-of-mouth from teams who had made it infrastructure.

The Harden moment is where craft becomes a growth lever. Products that are genuinely good to use become infrastructure. Products that are merely functional get replaced.

### Harvest — Account expansion

The fourth design moment is where B2B growth compounds.

Harvest is designing for organic expansion within the account — turning a 5-person pilot into a 50-person team deployment without a sales call. The design lever is collaborative functionality that creates natural invitations: file sharing that requires a colleague to have access, dashboards designed to be shared upward, reports that loop in a new stakeholder.

Figma is the clearest B2B example: browser-based multiplayer viewing and commenting that required no account to participate. A designer shares a file, the stakeholder opens it without a signup wall, and sees something worth having access to. Figma turned shared links into an acquisition engine because the design of the sharing experience was itself a growth mechanism.

Harvest requires designing for the account, not just the user. Every collaborative feature is a potential expansion surface if the access mechanics are designed to create natural onboarding for new team members.

## Verified B2B Examples (What's Actually Documented)

Most growth design content repeats the same case studies without distinguishing what's documented from what's been mythologized. Here's what holds up under scrutiny:

| Company | Growth Challenge | Design Decision | Verified Outcome |
| --- | --- | --- | --- |
| Slack | High workspace abandonment during complex enterprise setup | Redesigned onboarding to immediately connect users with coworkers in channels (4-step guided setup) | 93% of teams that sent 2,000 messages continued using Slack — cited directly by CEO Stewart Butterfield, First Round Review |
| Figma | High friction for stakeholders viewing and commenting on design files | Browser-based multiplayer viewing, guest access without signup wall, onboarding scoped to 3 core use cases | Shared links became a viral acquisition engine; viewing-only guests regularly converted to paid accounts (Aakash Gupta, 25 Product Design Examples) |
| Linear | Saturated market of complex, slow legacy issue trackers | Opinionated minimalist UI — single-column default view, progressive disclosure, keyboard-first navigation — built without A/B testing | $400M valuation with $35,000 lifetime marketing budget; growth driven entirely by word-of-mouth from teams that embedded it as workflow infrastructure (Eleken) |
| Miro | High drop-off rates on primary interface during early onboarding | Replaced high-velocity GIF animations with static human-led walkthroughs and contextual template suggestions | Onboarding completion rates increased; Kate Syuma's team scaled Miro to 20M+ users through systematic iteration on this flow |

**A note on Notion:** The frequently cited "20% activation increase" attributed to Notion's growth design actually belongs to **Airtable** — [specifically to Lauryn Isford's work there, documented by Aakash Gupta](https://www.news.aakashg.com/p/25-product-design-examples). Isford now leads growth at Notion, which is the likely source of the conflation. Notion's decisions are real and well-documented qualitatively, but the specific figure is Airtable's. If you're citing it, cite it correctly.

## Growth Design in the AI-Native Era

One shift worth naming: AI-native development has compressed the product development cycle. Teams that previously ran Idea → PRD → Prototype → Test over weeks are now running Idea → Prototype → Instant Learning → Iterate in real time.

This changes what growth design is _for_. When 10x more design variations can be generated and shipped, the constraint is no longer how fast you can produce design — it's how fast you can identify which hypotheses are worth testing and what the results mean.

Growth designers are increasingly the strategic filter in this cycle: identifying high-leverage hypotheses, defining success criteria before shipping, and protecting the user experience from fragmentation caused by pure experimentation velocity.

This is especially relevant in B2B SaaS, where onboarding chaos or UI churn alienates the economic buyer faster than it ever could a consumer app user. The growth designer's job in 2026 is not just to run experiments — it's to make sure the experiments are the right ones, and that velocity doesn't produce chaos.

## What This Means for Your Product Team

Growth design is not a role you hire for when growth is stalling. It's a way of thinking about design that should inform how your team defines success, validates decisions, and structures the product experience at every stage of the user journey.

For B2B SaaS teams, the practical translation:

-   Define your activation metric before you redesign your onboarding
-   Design for team activation, not just individual aha moments
-   Every collaborative feature is a potential expansion surface — design the access mechanics accordingly
-   Use counter-metrics alongside every growth metric to protect long-term retention
-   Ship to learn, not to ship

If your design team is shipping screens without a hypothesis about what will change, you're doing product design. That's not wrong — but it's not growth design.

The difference is measurability. In B2B SaaS, where the cost of getting onboarding wrong compounds across every seat, every renewal, and every expansion conversation, that difference is worth designing for.

_Need a design team that thinks in activation metrics and account expansion — and can ship fast enough to actually test hypotheses?_

_That's the core of how we work as an_ [_embedded design team_](/services/embedded-design-team)_. We join your sprints, own the hypotheses, and measure what we ship._

_You might also find these useful:_ [_How to Conduct a UX Audit_](/blog/ux-audit-guide) _— for identifying exactly where your funnel is breaking before redesigning anything._

_And_ [_The Complete Guide to SaaS Onboarding UX_](/blog/saas-onboarding-ux-guide) _— for the activation design layer specifically._

---

### Fintech Dashboard Design: Patterns & Real Examples (2026)
URL: https://www.themasterly.com/blog/fintech-dashboard-design-guide
Fintech · 2026-06-13

The fintech dashboard is the moment of truth.

It's the screen users see every time they open the product. It's where they decide — subconsciously, in the first few seconds — whether the product is worth their attention today. And it's where most fintech products fail not because of bad visual design, but because of wrong hierarchy.

A dashboard that opens on total transaction count is a dashboard designed for the product team, not the user. A dashboard that opens on current balance for a finance professional managing a $10M budget is a dashboard that misunderstands the job. A dashboard that shows the same view to a CFO, a founder, and a developer is a dashboard that treats all users as interchangeable — which they are not.

We analyzed five of the most-referenced fintech dashboards — Ramp, Mercury, Brex, Stripe, and Wise — through the lens of a single question: whose job does this dashboard make easier, and how?

The findings reinforce what we outlined in our broader [fintech design analysis](/blog/fintech-design-guide): the products that stand out aren't the most visually refined — they're the ones designed for a specific user's role and context.

## Why Dashboard Design Is a Retention Problem, Not a Visual Problem

[Research on financial management tools consistently shows](https://baymard.com/blog/dashboard-design) that the primary reason users stop actively engaging with a product is not feature gaps — it's that the default view doesn't answer their most important question quickly enough. The product trained them that it takes effort to get to the useful information, so they stop making the effort.

This makes dashboard hierarchy a retention lever, not just a UX preference. And hierarchy decisions are almost entirely about user role.

## The Masterly Fintech Dashboard Framework

After analyzing fintech dashboards across spend management, banking, payments, and transfer products, we identified four decisions that determine whether a dashboard retains users or loses them:

**Role** — Who is the primary user, and what do they care about most?

**Metric** — What is the one number or status that answers the user's first question? This should dominate the dashboard hierarchy above everything else.

**Density** — How much information can the user process at once without cognitive overload?

**Action** — What is the primary action the dashboard should drive? The best fintech dashboards aren't just reports — they create a clear next step.

## Ramp: Savings as the Primary Metric

Ramp's dashboard does something almost no other spend management product does: it leads with savings, not spend.

Most expense management tools open on transaction lists or budget summaries — useful reports, but passive. Ramp's dashboard opens on a savings number: how much the company saved this period versus prior spend. For a finance team whose job is to control and reduce expenditure, this is the most motivating possible opening screen.

[After a 2024 expense-flow refresh](https://ramp.com/blog/simpler-more-efficient-expenses), Ramp customers saw 20% of memos auto-suggested by AI, 33% faster transaction review, and 50% faster repayment of non-compliant spend.

**Framework breakdown:** Role: Finance team at a growth-stage company. Metric: Savings vs. prior period. Density: High. Action: Review flagged transactions, approve pending items.

## Mercury: Clarity for Founders Who Aren't Bankers

Mercury's dashboard solves a different problem. The user is a founder in their first 18 months, managing their own banking. Their most important number is cash balance and implied runway — not transaction velocity or payment method breakdown.

Mercury's primary dashboard metric is current balance with a visible trend. Everything else is secondary. The navigation is shallow, the most important actions are always one tap away, and the product never makes the user feel like they need to understand banking to use it.

**Framework breakdown:** Role: Early-stage founder. Metric: Current balance + cash trend. Density: Low. Action: Check balance, initiate payment, review recent activity.

![Fintech dashboard hierarchy comparison: spend management vs banking vs payments](/images/blog/fintech-dashboard-design-guide/body-1.png)

## Brex: The Finance Operating System

Brex took a structurally different approach. Rather than optimizing for one user role, the product is built as a finance operating system that adapts to the org chart. The 2025 Spring Release introduced custom fields, custom roles, and a policy engine that lets finance teams bring their own HRIS or ERP data into Brex to automatically provision cards, set limits, and automate accounting rules.

This makes the Brex dashboard look less like a banking interface and more like an administrative console — because for a finance leader at a 500-person company, that's exactly what it needs to be.

**Framework breakdown:** Role: Finance leadership at mid-market companies. Metric: Policy compliance + spend vs. budget by department. Density: Very high. Action: Review exceptions, adjust policies, approve escalations.

## Stripe: Infrastructure Designed for Inspection

Stripe's dashboard is designed for developers and technical finance teams who need to inspect, debug, and understand the behavior of a payment system. The primary metric is operational: transaction volume, success rate, and error breakdown.

Stripe earns trust through completeness — every log entry is actionable, every error code links to documentation, every transaction can be replicated and inspected. The mistake fintech products make when copying Stripe's dashboard: they adopt the visual language without adopting the logic. Event logs work in Stripe because every entry is linked to an API call a developer can replicate. Applied to a consumer or SMB product, the same format is noise formatted to look sophisticated.

**Framework breakdown:** Role: Developer or technical finance team. Metric: Transaction success rate + error breakdown. Density: Very high. Action: Investigate error, replicate failed transaction.

## Wise: The Dashboard as a Trust Signal

Wise leads with pending transfers and their exact status — not balance. For a user sending money internationally, the most anxious moment is the period between initiating a transfer and seeing it confirmed. The Wise dashboard acknowledges this anxiety directly.

[Wise's own design leadership described](https://nessgrixti.com/portfolio/wise-refresh) a rebrand process driven by the recognition that the company had "slowly started drowning in the sea of sameness." The differentiation they returned to was transparency — showing the numbers a competitor would hide, making the fee visible before commitment.

**Framework breakdown:** Role: Individual or SMB sending international transfers. Metric: Pending transfer status + fee transparency. Density: Low to medium. Action: Track active transfer, initiate new transfer.

## Real Fintech Dashboard Examples We've Designed

The patterns above aren't theoretical. Here's how the same Role-Metric-Density-Action logic plays out in fintech products we've shipped — three points on the density scale, from professional risk analytics to a consumer wallet.

### Crypto risk analytics — Alterscope

![Alterscope crypto risk-analytics dashboard: token score cards with sparklines above a high-density projects table showing TVL, trading volume, inline charts, and risk tier per row](/images/blog/fintech-dashboard-example-alterscope.png)

A DeFi risk platform where analysts assess dozens of protocols at once. The default view leads with **Top Scores** — the single number that ranks each asset — then drops into a high-density **Projects** table: TVL, trading volume, inline sparklines, and a risk tier on every row. Density is a feature here, not a flaw: the user is a professional comparing assets, not a founder glancing at a balance. [See the Alterscope case study →](/cases/alterscope-fintech-saas-platform-redesign-masterly-case-study)

### Analytics dashboard — SaaS platform

![Performance overview dashboard: KPI cards for total views, leads generated, and conversion rate, each with a trend delta, above an interactive views-over-time chart](/images/blog/fintech-dashboard-example-real-estate.png)

Here the user is an operator asking one question — "how am I doing?" — and the dashboard answers it in under two seconds. **Total Views, Leads Generated, Conversion Rate** sit as KPI cards with trend deltas, above a single interactive time-series. One primary question, one screen, no hunting. [See the case study →](/cases/expert-listing-proptech-marketplace-ux-ui-design)

### Consumer fintech — Flyra

![Flyra consumer fintech wallet: a large balance figure with Send, Add Money, and Withdraw actions, a virtual debit card, and a clear first-transaction empty state](/images/blog/fintech-dashboard-example-flyra.png)

The opposite end of the scale. In a consumer wallet, the balance *is* the dashboard: one number, three actions (Send, Add Money, Withdraw), and an empty state that tells a first-time user exactly what to do next. Minimal by design — the user isn't analyzing data, they're moving money. [See the Flyra case study →](/cases/fintech-brand-identity-product-design)

## The Four Most Common Fintech Dashboard Mistakes

**1\. Leading with the wrong primary metric.** Showing total transaction count to a CFO. Showing account balance to a developer. The wrong metric as the hero signals immediately that the product doesn't understand the user's job.

**2\. Applying Stripe's density to non-technical users.** Stripe's event log format is designed for developers. Applied to a small business owner or consumer user, the same format produces anxiety and confusion. Density is not a proxy for seriousness.

**3\. Treating all dashboard users as identical.** Most products have multiple user types. Designing a single dashboard that serves all of them at 60% rather than serving the primary user at 100% is the most common mistake.

**4\. Eliminating friction from high-stakes flows.** In high-stakes financial flows — large transfers, significant transactions, irreversible actions — friction is the trust signal. A final confirmation screen, a visible processing state, a clear warning — these aren't UX failures. They're what users need to feel the system is taking the action seriously.

![Masterly Fintech Dashboard Framework: Role, Metric, Density, Action](/images/blog/fintech-dashboard-design-guide/body-2.png)

## Dashboard Design Checklist

Before finalizing any fintech dashboard design, these questions should have clear answers:

| Question | What a good answer looks like |
| --- | --- |
| Who is the primary user and what is their job? | Specific role + context, not "our users" |
| What question do they need answered first? | One specific question, validated with real users |
| What metric answers that question? | One number or status that dominates the hierarchy |
| What is the primary action the dashboard drives? | One clear next step that appears without searching |
| What is the appropriate density for this user? | Calibrated to role and frequency of use |
| Where are the high-stakes flows that need friction? | Explicitly mapped — not eliminated by default |
| What trust signals are structural vs. decorative? | Structural signals (fee transparency, status visibility) prioritized over badges |

## What This Means for Fintech Product Teams

The pattern across all five products is consistent: the dashboards that retain users are not the most visually sophisticated — they're the most role-aware. If your fintech dashboard isn't retaining users the way you'd expect, a [UX audit](/blog/ux-audit-guide) almost always reveals the same root cause: the hierarchy was designed around available data rather than around the user's job.

## Want to Audit Your Fintech Dashboard?

Masterly works with [fintech companies](/client-industries/fintech) at Series A–D to audit, redesign, and test financial product interfaces — including dashboards, transaction flows, and onboarding. If your retention metrics are lower than your activation metrics, the dashboard is usually where the gap lives.

[View our fintech design work](/client-industries/fintech) or [learn about our UX audit service](/services/ux-audit).

---

### Fintech Design Trends 2026: Why Apps Look the Same (And What Works)
URL: https://www.themasterly.com/blog/fintech-design-guide
Fintech · 2026-06-13

Open almost any fintech product launched in the past three years. Dark background or clinical white. Clean sans-serif — almost certainly Inter. A gradient somewhere. Monospace elements near anything that looks like a number. Maybe a bento grid on the marketing page.

It looks credible. It looks modern. It looks exactly like everything else.

This isn't coincidence. It's what happens when an industry decides to optimize by copying its most successful player.

And Lenny Rachitsky put the problem bluntly:

> "Too many teams try the 'copy Stripe, copy Retool, copy OpenAI' shortcut and then wonder why the same moves fizzle."

Stripe's design is one of the most influential interfaces in B2B software history. It made complex payment infrastructure feel approachable, earned developer trust before enterprise buyers existed, and established a visual language so coherent that thousands of products adopted it wholesale. The problem: most of them adopted the surface, not the logic underneath.

We analyzed five products — Stripe, Wise, Ramp, Brex, and Mercury — to understand what their design actually communicates, why it works for their specific users, and what gets lost in translation when those decisions are copied without context.

## What We Analyzed

Five fintech products, each frequently cited as a design reference when a fintech team says "we want to look like that" — and each one that's made meaningfully different design decisions from the others.

| Product | Category | Primary user |
| --- | --- | --- |
| Stripe | Payment infrastructure | Developers + finance teams |
| Wise | International transfers | Individuals + SMBs |
| Ramp | Corporate cards + spend management | Finance teams at growth-stage companies |
| Brex | Corporate finance platform | Startups + mid-market finance teams |
| Mercury | Banking for startups | Founders + early-stage operators |

The analysis focused on: information hierarchy on core user flows, trust signals and how they're communicated, visual differentiation relative to ICP, and how each product handles data density — the defining challenge of financial UX.

## What the Best Fintech Products Actually Do

### Pattern 1: The core action is never ambiguous

The most consistent differentiator between products that feel polished and products that feel generic: whether the most important thing a user needs to do is immediately obvious.

Wise makes this a brand principle. Before committing to anything, a user sees the exact fee and exact exchange rate for their specific transfer. The fee calculator isn't buried in a flow — it's the hero. The design communicates: _we have nothing to hide, and we know the fee question is the first thing you want answered._ That's not just good UX. It's a competitive position rendered as interface.

Ramp's dashboard leads with savings. Not transactions, not account balance — savings. Specifically, how much the company saved this period compared to prior spend. For a finance team whose job is to control and reduce expenditure, this is the most relevant number in the product. A 2024 expense-flow refresh made the hierarchy more precise: after the update, [Ramp customers saw 20% of memos auto-suggested by AI, 33% faster transaction review, and 50% faster repayment of non-compliant spend](https://ramp.com/blog/simpler-more-efficient-expenses). These aren't branding wins. They're the product of choosing the right hierarchy for the right user.

The specific decisions behind dashboard hierarchy — metric selection, data density, role-aware views — are covered in detail in our [fintech dashboard design patterns guide](/blog/fintech-dashboard-design-guide).

Stripe does it differently again. Every product page leads with the simplest possible implementation — a code snippet, a dashboard screenshot, a flow diagram. Complexity is always one level deeper than you need right now. The design says: _start here, go deeper when you're ready._ For a developer evaluating infrastructure, this is exactly the right hierarchy.

![Core Action Clarity](/images/blog/fintech-design-guide/body-1.png)

Core Action Clarity

### Pattern 2: Designing for the actual buyer role — not a generic user

The biggest design failure in fintech isn't bad aesthetics. It's designing for a fictional user — a composite of consumer and professional, sophisticated and beginner, emotional and analytical.

Ramp is built for finance teams. Not founders, not individual contributors — finance professionals managing company spend at scale. The product's data density would feel overwhelming in a consumer context. In a corporate finance context, it's appropriate and expected. CEO Eric Glyman frames the company's entire design philosophy around this: [Ramp is a "finance automation platform" that helps businesses cut expenses by approximately 3.4% per year and shorten month-end close by about a week](https://www.mckinsey.com/industries/financial-services/our-insights/the-end-of-the-expense-report-a-conversation-with-ramps-eric-glyman). The product isn't selling a financial product. It's selling time.

> "Sell time, not money"

That's how Glyman describes Ramp's positioning. The design follows from the positioning.

Mercury went in a different direction and got it right for a different reason. The user is a founder in the first 18 months of their company, doing their own banking because there's no one else. They're sophisticated about their business but not necessarily about banking operations. Mercury's interface is simple not because it's for unsophisticated users, but because the user's attention is elsewhere.

Founder Immad Akhund has written about what "taste" actually means in product design: many startups mistake multicolored gradients and dark-mode homepages for taste, when real taste is a product that does exactly what users need with minimal friction, feels intuitive but anticipatory, and aligns with what Dieter Rams called "less but better." Mercury's design doesn't look minimal by accident — it looks minimal because that's the correct answer for a founder who should be running their company, not navigating their bank.

Brex sits between the two — and handles it in the most structurally interesting way. Rather than pretending there is one fintech user, the company built the product as a finance operating system. The 2025 Spring Release introduced custom fields, custom roles, and a policy engine that lets finance teams bring their own HRIS or ERP data into Brex to automatically provision cards, set limits, and automate accounting. One policy adapts dynamically across department, entity, and spend type. The result is an interface that looks less like a banking app and more like an administrative console where finance leaders map their org chart to financial rules. The visual language follows from that structural decision — not from copying a competitor's color palette.

Mercury made an equally deliberate structural choice in the other direction. In March 2026, the company published a piece called "Designing in the Open" — confirming that they had launched a fully public product demo with no contact form, no gate, no sales call required. Prospects entered sales conversations already knowing the product could handle their use case. It's a trust decision expressed not through the interface itself, but through the decision to expose the interface before commitment.

### Pattern 3: Trust through data, not decoration

Financial products have a trust problem that design alone cannot solve — but design can either close the gap or widen it.

The conventional approach: badges, certifications, security logos, recognizable client testimonials. These signal credibility but don't demonstrate it.

Wise's approach is different, and it came from a specific strategic decision. After years of iteration, [Wise's own design leadership recognized](https://nessgrixti.com/portfolio/wise-refresh) that the company had _"slowly started drowning in the sea of sameness, getting lost in the mix of every other fintech and bank in the market with no key differentiators."_ The rebrand that followed wasn't primarily a visual exercise — it was a commitment to making differentiation real rather than cosmetic. The mechanism: show the numbers a competitor would hide. The fee. The exchange rate. The comparison to what your bank would charge. The design says _look at what we're showing you_ rather than _look at these logos._

A UX analysis of Wise's iOS app praised its multi-step transfer flow specifically for this reason: transparent fee breakdowns appear in a dedicated step, the pre-transfer review page shows amounts, fees, and timelines before the user commits, and a post-payment timeline builds trust by showing work-in-progress rather than hiding processing states. These are instances of what designers call "intentional friction" — the product slows down to show its work, because in high-stakes money transfers, speed can feel like loss of control.

Stripe earns trust through a different mechanism: documentation completeness. The developer who can read the API docs and immediately understand every edge case is a developer who trusts the product. As one technical analysis put it, Stripe's real moat is _"not its gradients but its structural design decisions — clear documentation, thoughtful error states, and an architecture that 'absorbs complexity' so integrators don't have to."_ The completeness is the trust signal. The interface invites inspection rather than discouraging it.

Mercury builds trust through transparency about limits. When Mercury communicates clearly about what FDIC insurance covers and what it doesn't, that honesty reinforces trust more effectively than any badge placement. The "10-minute application" is a UX commitment, not marketing copy — the [onboarding](/glossary/onboarding) is designed to deliver on it.

One insight that runs counter to most UX orthodoxy: in high-stakes financial flows, friction is the trust signal. For large transfers or significant transactions, users don't want instant — they want a visible pause that signals the system is performing security checks. This is what designers call "purposeful friction": a one-second processing delay during a wire transfer, a haptic pulse when a payment completes, a final confirmation screen that functions as a digital receipt. The instinct to eliminate all friction from financial UX misunderstands what users actually feel in high-stakes moments. Speed can register as carelessness.

The contrast with dark patterns makes this point sharper. The industry is rife with design that weaponizes the opposite impulse — obscuring fees until the final step, pre-selecting high tip amounts in earned wage access apps, making cancellation flows deliberately confusing. In 2026, the UK's Consumer Duty standard now legally requires fintech firms to demonstrate that their UX facilitates genuine customer understanding, not just buried disclosures. The gap between "trust-first" design and dark-pattern design is widening — and it's being measured in regulatory exposure as much as user satisfaction.

### Pattern 4: Visual conviction that matches the brand promise

Brex made a deliberate choice: orange and black in a category dominated by blues, grays, and whites. That's not a minor decision. Blue signals trustworthiness and stability — the default for anything involving money. Orange signals energy, speed, and a willingness to challenge convention.

For a corporate card company positioning itself against legacy expense management tools and traditional corporate banking, orange is coherent. It says: _we're not a bank, and we're not trying to be._ The company's [Chief Design Officer put it explicitly](https://www.brex.com/journal/design-as-a-catalyst-for-growth): design has become _"central to so many decisions at Brex — shaping product vision, driving strategy, and pushing forward our brand as one that will be here in 100 years."_ That's not the language of a team adding visual polish. That's a team treating visual conviction as a strategic commitment.

Mercury chose the opposite signals. The company built its visual identity around a custom typeface (Arcadia), cinematic photography, dark-first palettes, and intentional use of purple rather than the blue and green that dominate financial color conventions. The choice to avoid blue is deliberate — it signals "we are not a traditional bank." [A detailed design analysis of Mercury's visual system](https://blakecrosley.com/guides/design/mercury) described the result as closer in aesthetic register to luxury automotive or fashion than to conventional bank UI. For a user who is already suspicious of banks and wants their finances to feel more like their other SaaS tools, that signal is exactly right.

Most products copying Stripe copy neither the logic nor the conviction. They adopt a vague version of "clean and modern" that communicates nothing. The irony is that Stripe's aesthetic communicates something very specific: _this is infrastructure built by engineers who care about craft._ When applied to a B2C payment app or a consumer neobank, that signal doesn't transfer — it just looks like a product that looked at Stripe.

## The Stripe Monoculture: What Gets Copied vs. What Actually Works

The Stripe design monoculture is real, and it's specific. One analysis of B2B SaaS branding in 2026 noted that "most developers can identify Stripe aesthetic on sight" and warned that fintech teams now default to the look — dark background, gradient accents, Inter typography — _"without a deeper brand story, contributing to a sense of visual sameness."_

Design commentary has named the pattern directly: a 2025 piece on aesthetic homogeneity described AI and big-tech-adjacent design culture as producing "visual averaging" — with Stripe sitting at the center of the ecosystem and its design patterns functioning as a gravitational default rather than a deliberate choice.

Here's what gets copied:

-   Dark backgrounds or dark-accented marketing pages
-   Monospace type near numbers or code
-   Bento grid layouts on product marketing pages
-   Minimal color with one gradient accent (usually indigo-to-purple)
-   Dense, data-forward dashboard aesthetics

The failures are predictable and recurring.

**Event logs without guidance**: Stripe's transaction logs are useful because developers can replicate API calls and inspect side effects. Fintech clones mimic the format — rows of events as the primary interface — expecting non-technical users to infer meaning. Without context or next-step recommendations, the log is noise.

**Code-like aesthetics in consumer interfaces**: internal IDs, hash-like reference numbers, and dark developer themes applied to consumer products or SMB tools feel alien and raise anxiety. They signal determinism to engineers; they signal confusion to everyone else.

**Density as a proxy for seriousness**: packing dashboards with charts and toggles reads as professional in a screenshot, but raises cognitive load for non-finance users and hides the actual value proposition.

**Three-column layouts without interactive content**: Stripe's famously structured documentation — navigation left, content center, live code right — works because every column has a distinct functional role (hovering text highlights the corresponding code sample, everything is linked to an API call). The same layout without that logic is just clutter.

Here's what doesn't get copied — and what makes Stripe's design actually work:

![What Gets Copied vs. What Actually Works](/images/blog/fintech-design-guide/body-2.png)

What Gets Copied vs. What Actually Works

### Progressive disclosure of complexity

Stripe hides nothing, but surfaces the simplest path first. The complexity is always accessible — it's never the default. A developer can go from zero to implementation before needing to understand the full system.

### Developer-first information hierarchy

Every design decision assumes a user who will read the docs, inspect the API, and evaluate the product technically before committing. The design doesn't just look credible to this user — it communicates _in their language._

### Trust through transparency and completeness

As Stripe's own technical analysis stated:

> "Stripe didn't simplify payments visually. They simplified them structurally... trust scales when risk is handled inside the system, not pushed to the integrator."

The design reflects a systemic decision, not an aesthetic one.

### Aesthetic coherence with ICP

Stripe's design looks like tools that developers already trust — GitHub, Linear, Vercel. The visual language is borrowed from a world the user already inhabits.

When a consumer neobank adopts Stripe's dark palette and bento layout, none of this transfers. The user isn't a developer. The product isn't infrastructure. The trust signals don't map. The result: a product that looks credible in a screenshot and feels generic in use.

## Masterly Fintech Design Clarity Framework

Three questions that separate fintech products that differentiate from fintech products that blend in.

| Dimension | The question | What good looks like |
| --- | --- | --- |
| Clarity | Is the core action immediately obvious for this specific user? | Wise's fee-first hero. Ramp's savings-first dashboard. One thing, one hierarchy. |
| Context | Is the design built for the actual buyer role — not a generic user? | Ramp for finance teams. Mercury for founders. Brex for growth-stage operators. Different densities, different tones. |
| Conviction | Does the visual language match the brand's actual position? | Brex's orange challenges banking convention. Mercury's Arcadia typeface and dark palette signal software-first. Neither is accidental. |

A product that scores well on all three doesn't need to look like Stripe. It looks like itself — which is the only differentiator that compounds over time.

## The Numbers Behind Good Fintech UX

Good design in fintech isn't just aesthetically satisfying — it's measurable. A [2026 benchmark report on fintech experimentation](https://growthlayer.app/guides/ab-testing-for-fintech) found an average conversion rate of approximately 5.5% for core application flows, with top-quartile performers reaching around 11%. The gap between median and top quartile isn't primarily explained by visual polish — it's explained by trust cues, flow simplicity, and transparency of pricing and status.

Ramp's 2024 expense-flow data makes the same point at the workflow level: the gains from redesigning micro-interactions and automating friction points (20% memos auto-suggested, 33% faster reviews, 50% faster repayments) were larger than most visual redesigns deliver. The design investment was in the right place — inside the product's actual critical path, not on the marketing site.

The KYC onboarding data tells the same story at the acquisition layer. Traditional fintech onboarding — manual data entry, disconnected verification steps, no progress visibility — sees roughly 68% of users abandoning mid-flow. High-performing onboarding in 2026, built on API-based instant verification, intelligent OCR auto-fill, and progressive disclosure with visible progress indicators, measurably closes that gap. The difference isn't the color of the button. It's whether the structural design respects the user's time and anxiety level during an inherently high-friction moment.

The implication: most fintech teams are optimizing the wrong layer. They're refining the surface while leaving the structure — the hierarchy, the trust architecture, the workflow — unchanged.

## What to Do If Your Product Has This Problem

Most fintech teams know their product looks generic. They attribute it to constraints — timeline, team size, budget, "we'll fix it after launch." But the problem is usually upstream of execution. It's a positioning problem that surfaces as a design problem.

Three diagnostic questions worth asking before a redesign:

**1\. Can you describe your user's job role in one sentence?**

Not their demographic, not their pain point — their actual professional accountability. What are they measured on? What decision are they making right now? If you can't answer this precisely, your design doesn't know who it's for either.

**2\. What is the one number or action your user needs to see first?**

Not the most impressive metric, not the most complex feature — the thing that most directly maps to why they're in the product right now. Ramp chose savings. Wise chose the fee. Stripe chose the implementation path. If your answer is "it depends," the hierarchy is unresolved.

**3\. If you removed your logo, could a user tell who built this product?**

If the answer is no — if it could be any of twelve companies — the visual conviction is missing. Mercury's dark palette and custom typeface are recognizable without a logo. Brex's orange is recognizable without a logo. That's the bar.

These aren't purely design questions. They're strategy questions that have design answers.

If your fintech product looks polished in a screenshot but feels generic in use — the problem is usually not execution. It's that the design doesn't know who it's for.

We work with fintech teams to close the gap between what the product looks like and what it needs to communicate. Brand, product design, and design systems built around a specific user and a specific position.

[Talk to us about your fintech product →](/client-industries/fintech)

Related: [The Hims Effect: Why Healthtech Built a Clone Factory](/blog/hims-effect-healthtech-design-monoculture) · [Fintech Dashboard Design Patterns](/blog/fintech-dashboard-design-guide) · [How to Conduct a UX Audit](/blog/ux-audit-guide) · [The Complete Guide to SaaS Onboarding UX](/blog/saas-onboarding-ux-guide)

---

### The Complete Guide to SaaS Onboarding UX: What Works in 2026
URL: https://www.themasterly.com/blog/saas-onboarding-ux-guide
UX · 2026-06-13

## The Product Isn't the Problem. The First Five Minutes Are.

Acquisition is expensive. A user who signs up, bounces in the first session, and never returns is a complete loss — you paid to acquire them and got nothing back. And yet most product teams invest far more in building features than in designing the experience that determines whether users ever reach those features.

[Research from Userpilot](https://userpilot.com/blog/user-[onboarding](/glossary/onboarding)-statistics/) suggests that users who complete onboarding are significantly more likely to convert from trial to paid and to remain customers long-term. The specific numbers vary by product, but the directional finding is consistent: onboarding is not a nice-to-have. It's the highest-leverage moment in the user lifecycle.

The reason most onboarding fails comes down to three patterns.

**Treating onboarding as a tutorial.** The instinct is to explain everything: features, settings, shortcuts, integrations. The result is a 12-step walkthrough that users click through without reading — just to get to the product. Onboarding isn't documentation. It's the first product experience. The goal isn't to inform — it's to activate.

**Front-loading friction.** Profile setup. Team invites. Workspace configuration. Billing. All before the user has seen why your product is worth configuring. Every step before the first value delivery is a dropout risk. The best products defer everything that isn't essential to [activation](/glossary/activation).

**Designing onboarding separately from the product.** Onboarding is often built as an overlay on top of the product — tooltips, modals, checklists — rather than as an integral part of the product experience. When onboarding ends, users are dropped into an interface they don't know how to use. The products with the best [retention](/glossary/retention) design onboarding into the product itself, not on top of it.

## Masterly Onboarding Framework

After auditing onboarding flows across dozens of SaaS products — including the [UX audits we run for B2B product companies](/services/ux-audit) — we've identified four phases that separate the products users stick with from the ones they abandon.

### Phase 1: Activation

**Goal:** Get the user to their first moment of value as fast as possible.

Activation is not account creation. It's not email verification. It's the moment when the user does the thing your product is built for — sends a message, creates a document, completes a task, sees a result.

Everything before that moment is overhead. Design to minimize it.

**Key principle:** Identify your activation event, then remove every step between signup and that event that isn't strictly necessary.

### Phase 2: Orientation

**Goal:** Help the user build a mental model of where they are and what they can do.

Once the user has completed their first action, they need to understand the space they're in. This isn't a feature tour — it's spatial orientation. Where are things? How do they relate to each other? What's the next logical step?

Good orientation design uses the product itself — empty states, default content, and progressive disclosure — rather than overlays and tooltips.

**Key principle:** Show, don't explain. Use example content and default states to communicate structure.

### Phase 3: Habit Loop

**Goal:** Get the user to repeat the core action.

A single activation isn't retention. Retention is built on repeated behavior. The third phase is about designing the conditions for return — notifications, streaks, collaborative triggers, or simply a product that users want to come back to.

**Key principle:** Identify the behavior you want to become habitual and design a trigger for it in the first session.

### Phase 4: Expansion

**Goal:** Surface additional value at the right moment, not all at once.

Features users discover at the right moment feel like rewards. Features dumped on users in the first session feel like complexity. Expansion is the ongoing onboarding — revealing more of the product as the user demonstrates readiness for it.

**Key principle:** Gate feature discovery behind behavior, not time. Show the next feature when the user has mastered the current one.

## Teardowns: Three Products, Three Approaches

### Notion — Segmentation First, Checklist as Option

Notion faces an unusually hard onboarding problem: it's a blank canvas product that means different things to different users. A solo writer, a project manager, and a student all need a different first experience.

Notion's answer is segmentation. Before the user sees a single page of the product, they answer two questions: how they want to use Notion (work, personal life, or school) and whether they'll use it alone or with others. Then they select their interests from a multi-select list — to-do lists, habit tracking, project tracking, and more.

![Notion — "How do you want to use Notion?" screen. Source: mobbin.com](/images/blog/saas-onboarding-ux-guide/body-1.png)

_Notion — "How do you want to use Notion?" screen. Source: mobbin.com_

![Notion — "What's on your mind?" multi-select screen. Source: mobbin.com](/images/blog/saas-onboarding-ux-guide/body-2.png)

_Notion — "What's on your mind?" multi-select screen. Source: mobbin.com_

Only after this does the user land in the product — a "Welcome to Notion!" page with an interactive in-product checklist that teaches the basics by doing, not by watching.

The checklist is the core of Notion's onboarding philosophy: it gives structure to users who want guidance, while staying completely out of the way for users who don't. There are no blocking modals, no forced walkthroughs. A user can close the welcome page and start building immediately. The checklist is an offer, not a requirement.

![Notion — "Welcome to Notion!" in-product checklist\]Source: mobbin.com](/images/blog/saas-onboarding-ux-guide/body-6.png)

_Notion — "Welcome to Notion!" in-product checklist. Source: mobbin.com_

**What works:**Use-case segmentation sets up a personalized experience before the user touches the product. The in-product checklist gives structure without forcing it. No blocking overlays or forced walkthrough steps — the product respects the user's autonomy.

**What could be better:**The flow has too many steps before the user reaches the product: email verification → profile setup → use case → interests → desktop app upsell = 5+ screens of friction before first value delivery. The desktop app upsell appears immediately before the user enters the product — a classic example of interrupting the activation moment with a sales message.

### Loom — The Product Teaches Itself

Loom has an elegant solution to the onboarding problem: the product demonstrates its own value throughout every step of the flow.

During the use-case selection screen — before the user has even entered the product — a Loom video is already playing on the right side of the screen. The user is watching Loom while signing up for Loom. Once inside the dashboard, the "Inspiration from the Loom Community" section fills the screen with real Loom videos from real users. There's no abstract explanation of what Loom does — only proof of it.

![Loom — "How are you planning to use Loom?" with video playing on right. Source: mobbin.com](/images/blog/saas-onboarding-ux-guide/body-3.png)

_Loom — "How are you planning to use Loom?" with video playing on right. Source: mobbin.com_

![Loom — dashboard with "Record your first Loom" and community videos. Source: mobbin.com](/images/blog/saas-onboarding-ux-guide/body-4.png)

_Loom — dashboard with "Record your first Loom" and community videos. Source: mobbin.com_

When the user is ready to record, the guided tutorial gives them a choice: "I want to practice" or "I'll explore on my own." The practice path is framed deliberately: "No pressure here. This is just for practice, with friendly tips." Low stakes, high encouragement.

![Loom — guided tutorial record screen with "Ready or not, let's record"\]Source: mobbin.com](/images/blog/saas-onboarding-ux-guide/body-7.png)

_Loom — guided tutorial record screen. Source: mobbin.com_

The activation event — recording a video — immediately produces the shareable artifact that is the product's entire value proposition. The moment the user finishes recording, they have a Loom video ready to share. The product has demonstrated its value not by explaining it, but by delivering it.

**What works:**The product demonstrates itself before the user has finished signing up. Community videos on the dashboard are the best possible product demo: real use cases, real people, no marketing language. "I want to practice / I'll explore on my own" gives the user agency over how much guidance they receive. The first recording immediately produces a shareable link — activation and value delivery happen simultaneously.

**What could be better:**The "Invite your teammates" step appears before the user has recorded anything — asking for referrals before delivering value is the wrong sequence. The choice between Chrome extension and desktop app adds a decision point where there should be a clear recommendation.

### Linear — Onboarding Inside the Product

[Linear](https://linear.app) takes a fundamentally different approach: there's no separate onboarding experience. The workspace you land in after signup IS the onboarding. It comes pre-populated with a set of issues — actual Linear issues, in the actual Linear interface — that guide you through the product one step at a time.

"Welcome to Linear 🎉." "Try 3 ways to navigate Linear: Command menu, keyboard or mouse." "Connect to Slack." "Use Cycles to focus work over n-weeks." Each item is a real issue in your real workspace. You onboard by doing exactly what Linear is built for: working through a list of issues.

![Linear — workspace with pre-populated onboarding issues. Source: mobbin.com](/images/blog/saas-onboarding-ux-guide/body-5.png)

Linear — workspace with pre-populated onboarding issues. Source: mobbin.com

There's one moment before this where Linear breaks from its minimalism deliberately: the command menu screen. Before the user enters the product, they're shown a single screen — "Meet the command menu" — and prompted to press Cmd+K. One shortcut. One lesson. The most important interaction in the product, taught at the moment of highest attention.

_\[Screenshot: Linear — "Meet the command menu" screen with Cmd+K\]Source: mobbin.com_

**What works:**Onboarding happens inside the product using the product's own interface — there's no disconnect between learning and doing. Pre-populated issues mean the workspace never feels empty on day one. Teaching Cmd+K before anything else is a smart prioritization: if a user learns one thing, it should be the command that unlocks everything else. "Choose your style" (light/dark) creates a sense of ownership before the user has done any real work.

**What could be better:**Workspace configuration (company size, role) is front-loaded before the user has seen any value. The pre-populated issues are useful, but users who want to create their first real issue have to navigate past the onboarding content to start actual work.

## What All Three Get Right

Notion, Loom, and Linear use different approaches — segmentation, self-demonstration, product-native onboarding — but they share three principles:

**The product teaches through itself.** None of them rely on a separate tutorial layer that describes the product abstractly. Notion uses its own checklist system. Loom uses its own videos. Linear uses its own issue tracker. Onboarding and product are the same thing.

**User agency is preserved.** In all three cases, the user can choose to skip or explore freely. There are no mandatory walkthroughs, no blocking modals, no "you must complete this before proceeding." The guidance is offered, not imposed.

**One lesson at a time.** Linear teaches Cmd+K before anything else. Loom gets you to record before anything else. Notion gets you to pick a use case before anything else. Each product identifies the single most important thing for a new user to understand — and makes that the onboarding.

## SaaS Onboarding Patterns That Actually Work

**Empty states are onboarding.** Most teams treat empty states as placeholders. The best products treat them as the first onboarding screen. A well-designed empty state explains what goes here, why it matters, and what the user should do first.

**Progressive disclosure over front-loading.** Don't show users everything at once. Start with the minimum viable interface and surface additional options as they become relevant. Front-loading complexity is the most common onboarding mistake.

**Checklists work — but only for the right actions.** Onboarding checklists work when completion is genuinely meaningful — when users who complete all items are demonstrably more likely to stay. They don't work as feature tours. A checklist should contain only the actions that predictably lead to retention, not "add a profile photo" or "explore the dashboard."

**In-product onboarding beats tooltips.** Tooltips and modals are overlays — they sit on top of the product and explain it abstractly. In-product onboarding uses the product itself as the learning environment. The user learns the feature by using it, not by reading about it.

## How to Audit Your Own SaaS Onboarding

If you're not sure whether your onboarding is working, start with five questions. (If you want a structured audit by an outside team, [see how we approach UX audits →](/services/ux-audit))

**1\. What is your activation event?**Define it precisely — not "the user logs in" but "the user completes \[specific action\] for the first time." If you can't define it, your onboarding has no target.

**2\. How many steps are between signup and activation?**Count every click, form field, and decision point. Each one is a potential dropout. For most products, this number is higher than it should be.

**3\. What does a new user see in the first 30 seconds?**Not what you intended them to see — what they actually see. Watch session recordings of first-time users. The gap between intention and reality is usually where the problem lives. Tools like [Hotjar](https://hotjar.com) or [FullStory](https://fullstory.com) make this straightforward.

**4\. What is your Day 1 retention rate?**If users aren't coming back after the first session, the onboarding isn't creating the habit loop. Day 1 retention below 30% is a signal to investigate.

**5\. When do users who churn drop off?**Map your churn against the onboarding flow. If users consistently drop off at the same step, that step is the problem.

## The Bottom Line

SaaS onboarding isn't a tutorial. It's the first product experience — and the first test of whether your product delivers on its promise.

The best onboarding flows share three traits: they're short, they're purposeful, and they teach through doing rather than explaining. They get users to the activation event as fast as possible, orient them in the product space, and create the conditions for repeated behavior.

If your onboarding isn't doing those three things, you're losing users who would have stayed.

_Looking at your own onboarding and not sure what's breaking? We run structured UX audits for B2B SaaS and AI product companies —_ [_see how it works →_](/services/ux-audit)

_Also worth reading:_ [_The Hims Effect: Why Healthtech Built a Clone Factory_](/blog/hims-effect-healthtech-design-monoculture) _— a teardown of design monoculture in a different vertical._

---

### UX Audit Checklist: 42 Questions to Run Before You Redesign
URL: https://www.themasterly.com/blog/ux-audit-checklist
UX · 2026-06-13

Most redesigns start with a problem the team can feel but can’t precisely locate. Conversion is low. Users aren’t activating. The product looks dated. So a brief goes out, new layouts get sketched, and months later the team discovers the new version has different problems — because nobody diagnosed the original ones.

This checklist prevents that. It’s organized around the [6-Layer [UX Audit](/glossary/ux-audit) Framework](/blog/ux-audit-guide) we use at Masterly — each layer surfaces a different category of failure, and each category connects to different business outcomes. Run the full checklist before a redesign, or use individual layers as targeted diagnostics when something specific isn’t working.

For each question, classify what you find using the **Masterly Impact Tiers**:

-   **Strength** — working well, worth explicitly preserving
-   **Friction** — usable but creating unnecessary drag on engagement or conversion
-   **Blocker** — active failure costing you users, conversions, or revenue right now
-   **Opportunity** — not broken, but a meaningful improvement is available

## Layer 1: Design Review (Q1–Q8)

Design review evaluates screens against usability principles — hierarchy, clarity, consistency, feedback. Most audits start here. Most audits also stop here, which is why they miss most of what’s actually affecting business outcomes. Use it as a foundation, not a conclusion.

| # | Question | How to check | Typical tier |
| --- | --- | --- | --- |
| Q1 | Does the homepage communicate what the product is and who it's for within 5 seconds? | Show to someone unfamiliar — ask them to describe what it does without prompting | Blocker |
| Q2 | Is there a clear visual hierarchy on each key screen? | Screenshot each key screen and squint — one element should dominate visually | Friction |
| Q3 | Are interactive elements visually distinct from non-interactive content? | Tab through the page using keyboard only — note anything ambiguous | Blocker |
| Q4 | Does the navigation reflect how users think, not how the team is organized? | Card sorting with 5 users unfamiliar with the product | Friction |
| Q5 | Are error, empty, and loading states designed? | Trigger each state manually — check for generic text or blank screens | Friction |
| Q6 | Is the typography system applied consistently across all page templates? | Compare 5 different page types side by side — heading sizes, line heights, spacing | Friction |
| Q7 | Is the color system semantically consistent? | List every use of the primary CTA color — anything that isn't a CTA is a failure | Friction |
| Q8 | Are primary actions visually stronger than surrounding promotional content? | Assess visual weight of main CTA vs nearest ad or upsell block | Blocker |

> Real audit finding: In one product, a sponsor’s promotional block had stronger visual weight than the site’s own navigation. The first thing users saw on load was an advertisement — not the content they came for.

## Layer 2: Information Architecture (Q9–Q15)

IA problems are almost never visible in individual screens. They emerge when you map the full structure: every page type, every navigation path, every dead end. The tools here are crawlers and user research, not screen review.

| # | Question | How to check | Typical tier |
| --- | --- | --- | --- |
| Q9 | Can a visitor predict where each navigation item leads before clicking? | 5-second test with new users — ask them where each nav item goes | Friction |
| Q10 | Are category and topic pages curated hubs — or just filtered lists? | Check your 3 highest-traffic category pages for editorial curation and sub-topic paths | Opportunity |
| Q11 | Does every page have a designed next step? | Read the last line of your 10 most-visited pages — what's the designed exit? | Blocker |
| Q12 | Is the footer a navigation aid or a dead end? | Check if footer offers meaningfully different paths than the main nav | Opportunity |
| Q13 | What percentage of core content is buried deeper than 3 clicks from the homepage? | Screaming Frog crawl → filter by crawl depth | Friction |
| Q14 | Are there orphaned pages with no inbound internal links? | Screaming Frog → Reports → Orphaned Pages | Friction |
| Q15 | Does the IA support the business model — do the most-visited pages connect to conversion? | Map your 10 highest-traffic pages to the nearest conversion point | Blocker |

> Real audit finding: A media platform with 100,000 monthly visitors had no structured path from article completion to a related article. Users who finished reading had one designed option: close the tab. Over 17,000 pages were buried deeper than 3 clicks from the homepage.

## Layer 3: Monetization and Conversion (Q16–Q22)

This is the layer most design teams skip — which is precisely why it contains the highest-value findings in most audits. Every item here connects directly to revenue or activation.

| # | Question | How to check | Typical tier |
| --- | --- | --- | --- |
| Q16 | Is the primary CTA visible above the fold on mobile without scrolling? | Test on a real phone — note whether the CTA is visible before any scroll | Blocker |
| Q17 | Is advertising clearly labeled and visually separated from editorial content? | Screenshot a content page — assess in 2 seconds what's ad vs editorial | Blocker |
| Q18 | Is there a designed conversion moment in the user journey? | Map the user flow — identify the exact point where an upgrade or CTA triggers | Friction |
| Q19 | Are upgrade or subscription prompts triggered after value delivery? | Walk through the trial flow — note where the first paywall or upgrade prompt appears | Friction |
| Q20 | Does the pricing or upgrade page reduce anxiety? | Check for: tier comparison, payment terms, refund policy, social proof | Friction |
| Q21 | What happens to a user who completes the first value action but doesn't convert? | Walk through trial to completion — note the next designed prompt, if any | Blocker |
| Q22 | Is there a recovery mechanism for users who abandon mid-flow? | Drop off mid-checkout or mid-signup — check for email, session persistence, or saved state | Opportunity |

> Principle: Ask users to pay before they’ve experienced value and you train them to distrust the product. The sequence that converts: first action — value delivery — upgrade prompt. Products that gate core features before first use systematically lose the users most likely to pay.

## Layer 4: Technical Performance (Q23–Q29)

A UX audit that ignores performance is diagnosing half the patient. Slow pages create user experience failures that no design improvement can compensate for — you cannot redesign your way out of a 22-second load time.

| # | Question | How to check | Typical tier |
| --- | --- | --- | --- |
| Q23 | What is the Largest Contentful Paint (LCP) on mobile? | Google PageSpeed Insights → Mobile tab. Good: <2.5s. Poor: >4s | Blocker if >4s |
| Q24 | What is the Cumulative Layout Shift (CLS) score? | PageSpeed Insights → CLS. Good: <0.1. Poor: >0.25 | Blocker if >0.25 |
| Q25 | Are images served in modern formats (WebP/AVIF) and sized correctly? | PageSpeed Insights → Opportunities → "Serve images in modern formats" | Friction |
| Q26 | Are render-blocking CSS and JavaScript files deferred? | PageSpeed Insights → "Eliminate render-blocking resources" | Friction |
| Q27 | Is full-page caching configured? | GTmetrix → Waterfall → check TTFB. Should be under 200ms | Friction |
| Q28 | Are there 5xx server errors reachable through normal navigation? | Screaming Frog → Response Codes → 5xx filter | Blocker |
| Q29 | Is mobile performance tested at realistic network conditions? | Lighthouse → Mobile mode → Slow 4G throttling | Friction |

> Real audit finding: Mobile LCP of 22.2 seconds. CLS of 0.405 — elements jumping while the page loaded, causing users to tap the wrong targets. 11,831 internal pages returning 5xx errors, reachable through ordinary navigation. No design change addresses any of these.

## Layer 5: SEO Health (Q30–Q36)

For content and SaaS products, SEO health directly affects organic traffic volume, which affects every other metric downstream. A product with strong UX and poor SEO health is invisible to the audience it’s designed for.

| # | Question | How to check | Typical tier |
| --- | --- | --- | --- |
| Q30 | Does every important page have a unique title tag and meta description? | Screaming Frog → Page Titles → filter duplicates and missing | Friction |
| Q31 | Are there duplicate pages from URL parameters, pagination, or auto-generated archives? | Google Search Console → Coverage → Excluded → Duplicate without canonical | Blocker |
| Q32 | Are there HTTP URLs or mixed-content issues on an HTTPS site? | Screaming Frog → Response Codes → Protocol filter | Blocker |
| Q33 | Is structured data implemented on pages that qualify? | Google Rich Results Test → check for Article, FAQ, Breadcrumb schema | Opportunity |
| Q34 | Do internal links use descriptive anchor text? | Screaming Frog → Bulk Export → All Inlinks → filter "click here" and "read more" | Friction |
| Q35 | Are the most important pages reachable within 3 clicks from the homepage? | Screaming Frog → crawl depth report → flag anything beyond depth 3 | Friction |
| Q36 | Is the XML sitemap current, submitted to Search Console, and free of errors? | Google Search Console → Sitemaps → check for errors or excluded URLs | Friction |

> Real audit finding: A Screaming Frog crawl at 52% completion had already discovered 326,000+ URLs — far above what the site’s content volume warranted. 25,008 mixed-content issues and 12,087 permanent redirects, each fragmenting link authority and consuming crawl budget.

## Layer 6: Analytics (Q37–Q42)

Analytics validates or challenges everything the other five layers surface. Without it, you’re working from observation and inference. With it, you’re working from evidence — and you can prioritize by actual impact, not by assumption.

| # | Question | How to check | Typical tier |
| --- | --- | --- | --- |
| Q37 | Are conversion events configured to track real business goals — not just pageviews? | GA4 → Events → verify sign-up, activation, and payment events exist | Blocker |
| Q38 | What is pages-per-session — and is it appropriate for the product type? | GA4 → Engagement → Pages & Screens → avg pages per session by user type | Friction |
| Q39 | What is the mobile-to-desktop split — does it match category benchmarks? | GA4 → Tech → Tech Overview → Device Category | Friction |
| Q40 | Are there pages with above-average bounce rates that don't warrant it by content type? | GA4 → Pages → segment bounce rate by page type | Friction |
| Q41 | Is there funnel tracking on every conversion flow? | GA4 → Explore → Funnel Exploration → check for gaps in step-level data | Blocker |
| Q42 | Can you attribute revenue or signups to specific traffic sources and landing pages? | GA4 → Acquisition → Traffic Acquisition → conversion column by source/medium | Friction |

> Real audit finding: A media platform showed 78.3% desktop / 21% mobile — an unusual split for a content site where the industry benchmark is 60–70% mobile. Mobile users weren’t returning. The likely cause: mobile performance failures suppressing repeat visits before analytics could even record them.

## How to Use Your Results

Once you’ve worked through the checklist, you have classified findings across six layers. The prioritization logic is straightforward: fix Blockers first, regardless of implementation cost. These are active failures — users are being lost, misled, or frustrated right now.

After Blockers, address high-impact Frictions starting with the ones that are cheapest to fix. Quick wins build momentum and demonstrate audit ROI before the larger structural work begins.

Structural problems — IA redesign, performance overhaul, SEO cleanup — belong in a parallel workstream, not competing with feature work. A platform with a 47/100 mobile performance score can’t absorb new features without making the underlying problem worse.

One final principle from real audit work: document your Strengths with the same rigor you apply to failures. Products that redesign without an explicit list of what’s working often accidentally remove the things quietly responsible for their best metrics. Clean reading experience, no intrusive modals, fast checkout — these are competitive advantages. Easy to miss. Easy to remove.

If you've worked through this checklist and found more Blockers and Frictions than you expected — that's the point.

A Masterly UX audit gives you a prioritized roadmap across all six layers, with findings classified by urgency and mapped to the business outcomes they affect.

[Talk to us about a UX audit →](/services/ux-audit)

Related: [How to Conduct a UX Audit (And What to Do with the Findings)](/blog/ux-audit-guide) · [The Complete Guide to SaaS Onboarding UX](/blog/saas-onboarding-ux-guide) · [Fintech Dashboard Design: Why Most Look the Same](/blog/fintech-dashboard-design-guide)

---

### Fintech Onboarding UX: What Stripe, Wise, Revolut, Robinhood, and Mercury Get Right (And Wrong)
URL: https://www.themasterly.com/blog/fintech-onboarding-ux
Fintech · 2026-05-30

## The Drop-Off Nobody Talks About

Fintech [onboarding](/glossary/onboarding) gets a lot of design attention. Every product team measures signup completion, tracks document upload rates, A/B tests button copy. The [conversion funnel](/glossary/conversion-funnel) from "land on homepage" to "account created" is usually well-instrumented and actively optimized.

The problem is that this is the wrong funnel to optimize.

The real drop-off doesn't happen at the selfie page or the address field. It happens after verification — when the user has been approved, landed inside the product, and has no idea what to do next. Robinhood's own data is the clearest evidence: 40% of users became entirely inactive immediately after their first account funding step. They got through the whole flow, funded the account, and stopped. The product treated funding as the finish line. Users treated it as an entrance they didn't know how to navigate.

This pattern is consistent across all five products we analyzed. Different strengths, different user bases — but the same structural blind spot: onboarding is designed as a compliance exercise, not a product experience.

## Three Phases That Actually Matter

Fintech onboarding isn't one flow. It's three distinct experiences, each requiring different UX thinking:

**Phase 1 — Preview:** Before a user hands over their email, they're forming a belief: is this product worth the effort of signing up? Most fintech products skip this phase entirely and open with a signup form.

**Phase 2 — Gate:** Identity verification (KYC) is legally mandatory and unavoidably friction-heavy. The design question isn't how to eliminate it — it's how to make it feel purposeful rather than punitive. The difference between a product that communicates clearly and one that just spins a loader is the difference between a user who waits and one who abandons.

**Phase 3 — Bridge:** The [activation](/glossary/activation) gap. The moment between "you're approved" and "you just did something meaningful." This is where fintech onboarding most commonly fails, and where the most valuable design work goes untouched.

This is the **Masterly Fintech Onboarding Model**: Preview → Gate → Bridge. Each product we analyzed does at least one of these well. The ones that do all three retain users.

![Masterly Fintech Onboarding Model diagram showing three phases: Preview, Gate, and Bridge](/images/blog/fintech-onboarding-ux/body-1.png)

## Stripe

**Who it's for:** Developers building payment infrastructure, and non-technical business owners and CFOs managing merchant accounts.

**Phase 1 — Preview:** Stripe skips it for consumers but gets it right for developers. API keys and a functional sandbox are available within seconds of entering an email — no business verification required to start building. For Stripe Atlas users, the pitch is concrete: 90% of founders are ready to fundraise, open a bank account, and charge customers within two business days of submitting their application.

**Phase 2 — Gate:** Highly variable — and that variability is Stripe's biggest UX problem. Standard merchant onboarding is smooth: progress bar, inline validation, localized for all supported countries, three configurable modes (hosted, embedded, API). Advanced products — Stripe Issuing, Treasury — become multi-week compliance projects. More critically, default risk settings can silently block features like ACH processing without explaining why, forcing users to find the right toggle after the fact. Trustpilot reviews consistently describe accounts working fine until the first real transaction, then a hold with no explanation.

**Phase 3 — Bridge:** Stripe's biggest advantage here is networked onboarding. Serial entrepreneurs with an existing account can port verified business details to a new account instantly. For first-time users, no equivalent shortcut exists.

[Stripe's Connect Express redesign](https://www.culturaldaily.com/how-notion-and-stripe-redesigned-their-ux-flows-as-they-scaled-and-what-growing-teams-can-take-from-it/) produced an average 5.3% lift in onboarding conversion, with one platform reporting 17%.

**Gets right:** Dual-audience design — developer speed and business-owner clarity without degrading either. **Gets wrong:** Post-KYC silent failures that surface only after a user has invested trust and started processing payments.

## Wise

**Who it's for:** Individuals and businesses moving money across borders. [Trustpilot aggregate: 4.3/5 from over 290,000 reviews](https://www.trustpilot.com/review/wise.com) — broadly positive, with a concentrated negative cluster around verification loops.

**Phase 1 — Preview:** Wise's strongest phase, and one of the best examples of value-before-auth in fintech. The homepage exchange rate calculator is functional and unauthenticated — users see the actual mid-market rate and exact fee before creating an account. [Built for Mars' teardown](https://builtformars.com/case-studies/wise) identifies this as a key conversion driver: by the time a user enters their email, they've already made a purchase decision based on real numbers, not marketing claims.

**Phase 2 — Gate:** For standard personal accounts, fast — under 10 minutes for most cases. The product shows estimated time at each step and allows save-and-resume across devices. Where it breaks down: KYC session links [expire in five minutes per Wise's own developer documentation](https://docs.wise.com/guides/developer) — short windows that interrupt users on slow networks or mid-device-switch. Regional compliance can stack multiple verification layers with no indication of what's required until mid-flow. The dominant 1-star pattern on Trustpilot: "Locked my account, asked repeatedly for the same documents I was submitting each time."

**Phase 3 — Bridge:** Once verified, the core action — initiating a transfer — is immediately accessible and well-guided. The joint account flow is a notable gap, triggering manual verification friction the primary flow avoids.

**Gets right:** Radical transparency on pricing. Time disclosure at each KYC step. Cross-device resumability. **Gets wrong:** Five-minute session link expiry, opaque rejection messages, and a support system that fails exactly when users are most anxious.

## Revolut

**Who it's for:** Mobile-first consumers in Europe wanting a multi-currency account. [Trustpilot: 4.7/5 from over 406,000 reviews](https://www.trustpilot.com/review/revolut.com) — highest of the five, with 80% five-star. The negative cluster is concentrated around post-onboarding account freezes.

**Phase 1 — Preview:** The weakest phase. Revolut leads with tier comparison — Standard vs. Plus vs. Premium vs. Metal — before the user has any basis for evaluating the differences. The product asks for a commitment decision before establishing any value.

**Phase 2 — Gate:** Where Revolut wins decisively for eligible users. By partnering with GBG for electronic identity verification, Revolut [reduced time to pass KYC from approximately 70 minutes to approximately 2 minutes](https://www.entrust.com/resources/case-studies/revolut) for eligible UK customers — a 97% reduction that delivered a 12% net increase in global onboarding completions. When eIDV passes, no document upload is ever required.

The fall-back breaks this. Users whose identity doesn't match data bureau records drop to document upload plus selfie, extending to five business days. [The selfie page generates 11% drop-off; the subscription selection page generates 13% drop-off](https://www.scribd.com/document/865551749/Revolut-PM-interview-questions) — users forced to choose a paid tier before establishing any trust in the product. That's 24% of high-intent users lost at two specific, knowable, fixable points.

**Phase 3 — Bridge:** Aggressive upsell immediately after onboarding undermines the experience Revolut just built. Before the user has done anything useful, they're pushed toward Premium tiers. Upsell works after value delivery, not before it.

**Gets right:** Best consumer KYC speed in the category. App-only signup. Multi-currency wallet usable instantly post-KYC. **Gets wrong:** Tier selection before value delivery, and "security review" freezes with no explanation — the dominant complaint in the 7% of negative Trustpilot reviews.

## Robinhood

**Who it's for:** Retail investors in the US, mobile-first and new to investing. [Over half of customers who funded accounts between 2015 and 2021 reported Robinhood was their first brokerage account](https://www.sec.gov/Archives/edgar/data/1783879/000162828021013318/robinhoods-1.htm) — that's the ICP in one sentence.

**Phase 1 — Preview:** The strongest preview phase of the five. Robinhood lets users build a watchlist and simulate a trade before SSN is required — before any sensitive data is collected at all. The three-CTA structure at entry (Register / Learn More / Try Demo) reduces decision anxiety by giving hesitant users an exploration path that doesn't feel like rejection.

**Phase 2 — Gate:** Clean and fast — [16 clicks, 11 fields](https://medium.com/@ericyi/ux-teardown-3-robinhood-79e310f7578), with Plaid handling bank linking automatically. SIPC protection ($500,000) surfaces alongside bank linkage — the right trust signal at the right moment. Where it fails: when ID verification fails — from poor photo quality, an SSN typo, or a duplicate account — the response is "try again tomorrow" with no explanation of what went wrong.

**Phase 3 — Bridge:** The most instructive example in the category, in both failure and recovery. Original failure: 40% of users became inactive immediately after first account funding. The fix: [Robinhood integrated Pinwheel's PreMatch technology](https://marketchameleon.com/articles/b/2026/4/14/robinhood-streamlines-bank-onboarding-pinwheel-prematch-doubles-conversion) to automatically detect active payroll accounts after MFA — eliminating the manual employer lookup that preceded direct deposit setup. Direct deposit conversion doubled.

**Gets right:** Best pre-auth exploration of the five. Automated payroll detection that closes the activation gap. Gamified first-trade confetti — the canonical aha moment. **Gets wrong:** Generic rejection errors, and immediate promotion of margin and options to users who've never invested before.

## Mercury

**Who it's for:** Startups and founders who need a business bank account without visiting a branch. [Trustpilot: 4.0/5 from 2,500+ reviews](https://www.trustpilot.com/review/mercury.com). NPS of 75, compared to a [banking industry average of 34](https://customergauge.com/benchmarks/blog/financial-services-nps-benchmarks).

**Phase 1 — Preview:** Mercury relies on reputation rather than in-product preview. Word of mouth from the founder community does the acquisition work. For founders outside the core ICP (US-incorporated startups), there's no equivalent of Wise's calculator or Robinhood's demo to anchor the decision.

**Phase 2 — Gate:** Mercury's most impressive design work. The application is split into two phases: basic credentials first (~5 fields), then formal business documentation. [Phase 1 data lets Mercury recover abandoned signups](https://productonboarding.com/examples/mercury-new-user-onboarding) — if a founder drops off during document collection, the contact info is already in the system. For document processing, Mercury deployed real-time parsing achieving [98% accuracy on edge cases with 5–7 second feedback cycles](https://www.extend.ai/resources/mercury-case-study). If a founder uploads a blurry image or the wrong document, they know immediately — not after 48 hours.

**Phase 3 — Bridge:** An explicit post-approval status tracker shows what Mercury is reviewing and what the founder can do in the meantime. Zero upsell pressure — no pre-checked paid tier boxes anywhere in the flow. The gap: Mercury support is M–F, 6am–5pm PT only. If KYC needs human review on a weekend, nothing moves.

**Gets right:** Two-phase structure. Real-time document validation. Transparent wait-state communication. Zero onboarding upsell. **Gets wrong:** Application denials without explanation for non-standard entities, and weekend support gaps.

## The Masterly Fintech Onboarding Model

**Preview** is where Wise and Robinhood win. Show core value before asking for anything — a fee calculator, a demo, a rate comparison. The signup that follows feels like a logical next step, not a gate.

**Gate** is where Mercury and Revolut (when eIDV works) win. KYC is unavoidable, but it can be transparent and fast. Revolut's 97% KYC time reduction is the consumer benchmark. Mercury's two-phase split with real-time document feedback is the B2B benchmark.

**Bridge** is where nobody fully wins yet. The activation gap between approval and first meaningful action is the most underdeveloped phase across the entire category. The question isn't only "how do we reduce steps to first deposit" — it's "what does the user need to understand and do in the first 10 minutes of having an active account?"

One strategic choice shapes everything else: **speed or trust signals — pick one.** Revolut's 2-minute promise inherently means lighter AML screening for some users. Mercury's 1–2 day approval window inherently means slower time to aha. Neither is wrong. Both require messaging built honestly around the tradeoff.

| Product | Preview | Gate (KYC) | Bridge (Activation) | Standout Metric |
| --- | --- | --- | --- | --- |
| Stripe | ✅ Instant sandbox for developers | ⚠️ Silent post-KYC blocks on first transaction | ✅ Networked onboarding for returning users | +5.3% conversion via Connect Express (up to +17%) |
| Wise | ✅ Unauthenticated rate calculator | ⚠️ 5-min link expiry; opaque rejection messages | ✅ Clear first-transfer action post-approval | 4.3/5 Trustpilot (290k+ reviews) |
| Revolut | ❌ Tier selection before value established | ✅ 97% KYC time reduction (70 min → 2 min via eIDV) | ❌ Upsell pressure before first value delivery | 4.7/5 Trustpilot (406k+ reviews) |
| Robinhood | ✅ Watchlist + demo trade before SSN | ⚠️ Generic "try again tomorrow" on rejection | ✅ Payroll auto-detection 2× deposit conversion | 16 clicks, 11 fields; 40% post-funding inactivity (fixed) |
| Mercury | ⚠️ Relies on reputation, no in-product hook | ✅ 5–7s real-time doc validation; two-phase split | ✅ Transparent review timeline; zero upsell | NPS 75 vs. banking industry average 34 |

![Product comparison matrix showing how Stripe, Wise, Revolut, Robinhood, and Mercury perform across Preview, Gate, and Bridge onboarding phases](/images/blog/fintech-onboarding-ux/body-2.png)

## Four Mistakes That Are Costing You Activations

### 1\. Treating KYC completion as the conversion goal

KYC approval is not activation. A user who has verified their identity but hasn't made a transfer, funded an account, or completed a transaction hasn't experienced the product's value. Robinhood's 40% post-funding inactivity exists precisely because the product treated funding as the finish line.

### 2\. Using generic rejection screens

When KYC fails, most products tell users to "try again tomorrow" with no explanation of what went wrong. The fix: tell the user the category of failure — image quality, name mismatch, document expired — and offer a one-tap retry path. This is the most commonly cited abandonment trigger across App Store reviews for Robinhood and the dominant 1-star pattern for Wise on Trustpilot.

### 3\. Upselling before delivering

Revolut's subscription selection page generates 13% drop-off — users asked to choose a paid tier before they've experienced the free one. Upsell belongs after the first value moment. Mercury's decision to keep onboarding free of upsell pressure is part of why its NPS is 75.

### 4\. Not designing the waiting period

KYC review, bank verification, and compliance checks all involve waiting. Most products communicate this with a generic "we'll email you" and go silent. Mercury's pending-review screen is the better model: tell users what step they're on, what's being reviewed, what they can do while they wait. Users who don't know what's happening assume something is wrong.

## Onboarding Design Checklist

| Question | Why It Matters |
| --- | --- |
| Can a user experience core product value before entering personal data? | Value before auth reduces signup anxiety and improves commitment quality |
| Do you run electronic identity verification before requiring document upload? | eIDV-first can reduce KYC time by 97% (Revolut benchmark); documents only as fallback |
| Is signup split into two phases — low-friction first, documents second? | Phase 1 data enables recovery of users who drop off during document collection |
| Do rejection states name the category of failure and offer a retry path? | Generic "try again" messages are the #1 KYC abandonment driver across all five products |
| Is the verification wait state designed — not just acknowledged? | Users who don't know what's happening assume something is wrong |
| What is the user's first action after KYC approval? | If there's no designed path from approved to active, the activation gap is already a retention problem |
| Is upsell deferred until after first value delivery? | Subscription pressure before first use trains users to distrust the product |

## If Your Onboarding Has an Activation Gap

The patterns across these five products converge on the same problem: most fintech onboarding has been optimized through KYC and stops there. The transition from verified to active — the Bridge phase — is where the most significant retention work still lives.

A [UX audit](/blog/ux-audit-guide) of a fintech onboarding flow typically surfaces the drop-off at a predictable moment: not the selfie page, not the address field, but the screen that appears after approval. The one that says "you're all set." It rarely is.

If your activation rate is more than 20 percentage points below your KYC completion rate, the gap is in Phase 3 — and it's almost certainly undesigned. Masterly works with [fintech companies](/client-industries/fintech) at Series A–D to audit and redesign onboarding flows, including the activation phase that most optimization efforts never reach.

[View our fintech design work](/client-industries/fintech) or [learn about our UX audit service](/services/ux-audit).

---

### What Is an Embedded Design Team? (And Why Fast-Growing Companies Are Switching to It)
URL: https://www.themasterly.com/blog/embedded-design-team-guide
Product · 2026-05-26

Most CPOs and VPs of Product hit the same wall somewhere between Series A and Series C.

You need a UX designer for onboarding. A UI designer for the new dashboard. Someone who understands [design systems](/glossary/design-system) so your Figma files don't become a liability. Maybe a motion designer for the product demo. And you need all of this on a timeline that doesn't allow for a four-month hiring process.

In-house hiring solves the long-term problem but not the immediate one. A senior product designer costs $130,000–$180,000 per year in base salary alone — before benefits, equity, recruiting fees, and the three to six months it takes a new hire to become fully productive. And one hire covers one specialization, not five.

Freelancers solve the speed problem but create a coordination problem. You end up managing three or four people across different time zones, different tools, different quality levels. The output is inconsistent and nobody owns the big picture.

Traditional agencies deliver projects. They scope, execute, and hand off. When you need changes two weeks later, you're starting a new statement of work.

The embedded design model exists to fill this gap.

## What an Embedded Design Team Actually Looks Like

The model is straightforward. You get a dedicated team scoped to your needs:

**Design Lead** — the senior designer who owns design as a function. They internalize your brand — not just the visual guidelines, but the tone, the positioning, and how it should feel to use your product. They understand how your business works: your revenue model, your sales motion, your users' real context. They know which questions to ask before a single frame gets opened. And they manage the rest of the design team — making sure every output, regardless of who produced it, is consistent in quality, style, and intent. This is not a project manager who relays feedback — it's a design partner who holds the whole picture.

**Designer(s)** — one or more designers matched to what you actually need. The reason this matters: design is not one skill. A great UX designer and a great brand designer are different people. Someone who is exceptional at motion design is rarely the same person you want running a UX audit. Someone who builds in Webflow is not the same as someone who designs a design system in Figma. The embedded model lets you access the right specialization for the right problem — without hiring five people or settling for a generalist who does everything at 60%.

**Project Manager** — the operational layer that keeps work moving. Manages timelines, runs async communication, tracks feedback loops, and makes sure nothing falls through the cracks. This is what lets your internal team stay focused on product and engineering instead of managing the design relationship.

![Embedded design team structure: Design Lead, Designer, Project Manager](/images/blog/embedded-design-team-guide/body-1.png)

## The Masterly Embedded Design Model

After working with fintech, healthtech, and AI product companies across multiple engagement models, we developed a framework that defines how embedded design creates value versus just executing tasks.

The **Masterly Embedded Design Model** has four operating principles:

**1\. Embed, don't attach.** The team works in your environment — your Figma, your Slack, your sprint cycles. They attend standups, participate in product discussions, and understand context before they produce output.

**2\. Own the craft, share the decisions.** The design team owns design quality and makes design decisions independently. They don't wait to be told what to create — they bring proposals, raise problems early, and push back on directions that will create UX debt downstream.

**3\. Match capacity to need.** The team composition changes as the product changes. Pre-launch, you might need heavy UX research and wireframing. Post-launch, you need UI polish and design system maintenance.

**4\. Measure by output, not hours.** The right metric is product outcomes: activation rate, onboarding completion, time-to-value, conversion on key flows. Not hours logged or files delivered.

## Embedded Design vs. Your Other Options

Here's how the models compare across the dimensions that matter to a CPO or VP Product.

| Dimension | In-House Hire | Freelancer | Agency (Project) | Embedded Team |
| --- | --- | --- | --- | --- |
| **Time to start** | 3–6 months | 1–2 weeks | 2–4 weeks | 1–2 weeks |
| **Cost structure** | Fixed (salary + benefits + equity) | Variable (hourly/project) | Project-based | Monthly retainer |
| **Specialization** | One person, one speciality | One person, one speciality | Team (project-scoped) | Team (matched to need) |
| **Product context** | Deep (over time) | Shallow | Moderate | Deep (ongoing) |
| **Continuity** | High (until they leave) | Low | Low (handoff model) | High |
| **Scalability** | New hire cycle each time | Add more freelancers | New project scope | Adjust team composition |
| **Management overhead** | Medium (performance, growth) | High (coordination) | Medium (briefing, reviews) | Low (PM handles it) |

The key insight from this comparison: in-house and embedded are the only two models that produce genuine product context over time. But in-house requires six or more months before you see that value, and a single hire doesn't cover the range of design needs a growing product company has.

## When Embedded Design Makes Sense

**You're between Series A and Series C.** You have product-market fit, you're scaling, and design is becoming a competitive differentiator — but you don't yet have the headcount to build a full in-house design org.

**You have multiple simultaneous design needs.** A new feature, a redesigned onboarding, a refreshed marketing site, and a design system to maintain — all at once. One in-house hire can't hold all of this.

**You need domain expertise, not generalists.** If you're building a [fintech product](/client-industries/fintech), you need designers who understand financial data visualization and trust-building patterns. If you're building an [AI product](/client-industries/ai-ml), you need designers who understand [AI interface patterns](/blog/ai-product-design-guide). Domain expertise takes years to build — you can access it immediately with the right embedded partner.

**You've tried freelancers and the coordination is killing you.** When you're managing three or four freelancers with different tools, time zones, and quality standards, you're spending more time managing than shipping.

**You have a hard deadline.** A funding round, a major launch, a board demo. This is not the time to start a hiring process or scope a project with an agency that will hand off mid-execution.

## What Embedded Design Is Not

**It's not staff augmentation.** Staff augmentation means plugging in a contractor who takes direction from your team. Embedded design means bringing in a team that owns design as a function — they make decisions, set standards, and push back.

**It's not a retainer with an agency.** A retainer with a traditional agency is a fixed number of hours per month applied to whatever you need. There's no continuity between requests, no ownership of your design system, no one who cares about the product between deliverables. Embedded design is a function, not a bucket of hours.

**It's not the right model for every situation.** If you have one simple, well-scoped task — a single landing page, a one-off illustration — a freelancer is faster and cheaper. If you already have a strong in-house designer and just need execution support, staff augmentation might be enough. Embedded design makes sense when the scope is ongoing, the needs are varied, and you need someone who owns the work — not just completes it.

## A Real Example (Anonymized)

One of our longest-running embedded engagements is with a B2B marketplace company. Their internal team handles product strategy and engineering. We handle everything that requires visual and interaction design: sales enablement materials, product UI updates, pitch assets, and on-demand design support for their go-to-market team.

The setup: a Design Lead who knows their product, brand, and business context deeply; one designer who handles execution; and a PM who manages the queue and communication. Their team sends requests. We handle prioritization and output. They review finished work.

The result: their internal team ships faster because design is never the bottleneck. Their materials are consistent because one team owns the system. And they're paying a fraction of what it would cost to hire even one senior designer in-house.

![Embedded design team vs in-house vs agency vs freelancer comparison](/images/blog/embedded-design-team-guide/body-2.png)

## How to Set Up an Embedded Engagement Correctly

**Define what "good" looks like before you start.** Not deliverables — outcomes. What does a successful first quarter look like? Faster shipping? A consistent design system? A redesigned onboarding flow with measurable lift in activation?

**Set communication norms early.** How often do you sync? Who is the single point of contact on your side? What's the response time expectation on feedback? These decisions, made in week one, determine whether the relationship runs smoothly or generates friction.

**Start with a** [**UX audit**](/blog/ux-audit-guide)**.** If you're bringing in an embedded team to improve your product, start by understanding what's actually broken. A structured audit gives the team context, identifies the highest-leverage opportunities, and creates a shared baseline.

**Give access to users, not just specs.** The best embedded design teams want to talk to your users, watch session recordings, and understand where people drop off. Design based on specifications alone produces technically correct work that doesn't solve the real problem.

## What to Look for in an Embedded Design Partner

**A dedicated Design Lead, not a rotating account team.** The person you brief on Monday should be designing on Tuesday.

**Domain experience in your vertical.** If your product handles money, medical data, or AI output, the designers need to understand the constraints, the user psychology, and the trust requirements of that domain.

**A built-in PM layer.** The design team should come with someone who handles project management and async communication. If you're spending hours a week managing the relationship, the model isn't working.

**Willingness to work in your tools.** Your Figma, your Slack, your Jira. Not a separate portal, not a proprietary handoff process.

**Transparent scope and exit terms.** You should know exactly what's included, how capacity changes, and what the process looks like if you need to scale up, scale down, or exit.

### Ready to See How It Works?

Masterly's [Team Extension service](/services/team-extension) is built on the embedded model. A dedicated Design Lead, designers matched to your specialization needs, and a Project Manager — working inside your product, on your timeline, without the hiring overhead.

We work with fintech, healthtech, and AI product companies at Series A–D. If you're scaling and design is becoming a bottleneck, [let's talk](/services/team-extension).

---

### Crypto Wallet UX Teardown: Phantom, Coinbase, Trust Wallet, Cash App, and Payy
URL: https://www.themasterly.com/blog/crypto-wallet-ux-teardown
Web3 · 2026-04-27

## The Biggest Activation Gap in Fintech

Here is the most important data point in crypto product design: Coinbase has 120 million verified users. Between 6 and 8 percent of them transact monthly.

That's not a retention problem. It's an activation problem that starts in [onboarding](/glossary/onboarding) and compounds at every subsequent step. For comparison, [CleverTap's fintech benchmark](https://clevertap.com/blog/fintech-benchmarks/) shows 95% of signed-up fintech users complete a monetary transaction within their first month. Crypto wallets are operating at roughly 1/15th that rate.

The gap is structural, not cosmetic. It has three causes: seed phrases, blockchain selection, and gas fees — three decisions that have no equivalent in traditional finance and that crypto products ask users to navigate before they've experienced any product value.

> _"This is about money, not buttons,"_

said a participant in a 2021 DIS study on crypto UX. The frustration wasn't with visual design. It was with being asked to operate as a systems engineer in order to send $50 to a friend.

This teardown analyzes five products — Phantom, Coinbase Wallet, Trust Wallet, Cash App, and Payy — to find what the best ones get right and what the rest still get wrong.

## The Home Screen: One Number, One Action

Every financial app opens with the same implicit promise: show me where I stand and what I can do. The products that fulfill this promise in under two seconds activate users. The ones that don't lose them at the door.

**Cash App gets this more right than anyone in the group.** The home screen is a single large balance number — nothing competing with it. Two actions: Add Money and Withdraw. An FDIC badge sits quietly at the bottom, doing trust work without demanding attention. A personal avatar and $Cashtag create ownership before the user has done anything. The entire screen answers the core question in one glance. iOS rating: 4.8.

**Phantom App is close.** Total USD balance is the hero, with a percentage delta in color-coded green or red. Four actions (Receive, Send, Swap, Buy) sit below — equal weight, which is the only real friction point. The @username and avatar make the wallet feel personal and owned from the first session. Dark mode default signals premium without stating it. Phantom's growth validates the approach: [15–20M monthly active users by 2025](https://sqmagazine.co.uk/phantom-wallet-statistics/), up 368% year-over-year.

**Payy takes radical simplicity further than anyone.** The entire home screen is a balance number and two buttons: Deposit and Request. One tab for Wallet, one for Activity. No navigation clutter, no competing priorities. No login, no email, no password — the wallet is generated locally on the device. It is the most opinionated home screen in the group and the clearest expression of what a payment app should do. At ~100K users it's early, but the design thesis is sound.

**Coinbase App overloads.** The home screen competes with itself: balance, buy/sell buttons, discovery content, rotating promotional banners, price tickers. It's designed for engagement, not clarity. Cash App grew to 59 million monthly transacting actives in large part because it never confused engagement with utility. Coinbase's NPS of 11 — against a fintech industry median of approximately 40 — is the downstream metric of this decision.

The pattern: every element on the home screen that isn't the balance or the primary action is friction.

![](/images/blog/crypto-wallet-ux-teardown/body-1.png)

## Onboarding: The Security Paradox

Every crypto wallet faces the same design tension: security setup must happen before the user can do anything, but security concepts are unfamiliar, the stakes feel high, and the consequences of skipping or misunderstanding are irreversible. The products that handle this well slow down just enough to explain before asking. The ones that don't produce users who either abandon or complete setup without understanding what they agreed to — which is worse.

**Trust Wallet** has the most structured onboarding of the five. Passcode creation is step-by-step, Face ID setup is sequenced logically, system permissions are timed correctly, and the completion screen has genuine energy. The problem: nothing in the flow explains why any of this matters. Users create a PIN without understanding that losing it has consequences no support team can fix. Security setup as a checkbox rather than a moment of comprehension.

**Coinbase Wallet** moves fast. Branded splash, a loading state, Face ID prompt, and you're at the home screen. The friction is low — almost too low. The seed phrase, the single most important piece of information a self-custody user will ever see, is tucked behind an optional step and easy to skip. The user who skips it and later loses device access has no recourse. Coinbase's Smart Wallet (passkey-based, no seed phrase) crossed 1 million accounts in August 2025 — a direct acknowledgment that the original flow wasn't working.

**Phantom** gets the instinct right. Splash screens before the setup flow explain "Controlled by you," "Best home for NFTs," and the security model — users see context before they see a PIN prompt. The execution has problems: the screens are text-heavy, visual hierarchy breaks down, and an unexpected "select your email" prompt mid-flow creates inconsistency in a product that's framing itself as self-custodial. But the structure — education then setup — is correct, and it shows in Phantom's activation numbers.

**Cash App** has the best momentum of the group. One action per screen, clear forward progress, progressive disclosure of complexity. It asks for the minimum required information at each step and defers everything else. The limitation: it never shows users what the app does. You complete onboarding without a clear mental model of why Cash App is different from Venmo. Cash App gets away with this because its social utility model — [retention rises 31 percentage points when a user has four or more friends on the app](https://www.howtheygrow.co/p/how-cash-app-grows) — fills in what the onboarding doesn't explain.

The pattern: security setup without explanation produces either abandonment or compliance without comprehension. Both fail. The best onboarding educates before it asks.

## The Seed Phrase: Settled Technology Debt

The seed phrase is the single most consequential UX decision in crypto — and the industry has already concluded it was wrong.

[A CHI 2025 study](https://bitcoinux.africa/blog/posts/seed-phrase-ux.html) (n=643) found only 43.4% of crypto users could correctly identify an image of a seed phrase. 58% believed they could choose and reset one like a password. 52% said a username and password was sufficient to recover a wallet. These are not edge cases — they are the median crypto user.

The financial consequence of this comprehension gap is enormous. [Chainalysis estimates 2.3–3.7 million Bitcoin are permanently lost](https://www.ledger.com/academy/crypto/how-many-bitcoin-are-lost) — roughly $250B+ at 2024–2025 prices — largely due to forgotten or mismanaged keys. The user behavior pattern is consistent: people store seed phrases the way they store passwords. Screenshots, cloud backups, Notes apps. The wallet explicitly warned against screenshots. P1 did it anyway because screenshots is how you save important information.

The industry's response to this data has been decisive. In May 2024, Phantom acquired Bitski for embedded-wallet onboarding. In June 2024, Coinbase shipped Smart Wallet — passkey-based, no seed phrase — which hit 1 million accounts by August 2025, with 270,000 created on August 16 alone. In June 2025, Stripe acquired Privy, the embedded-wallet infrastructure provider. In August 2025, MetaMask — the wallet that invented seed-phrase onboarding — shipped Google and Apple social login.

> _"We never believed that mainstream users would start to care about private keys, seed phrases, and all these complex topics,"_

said Argent co-founder Julien Niset.

For any product team doing a teardown today: a wallet still leading with "write down these 12 words" is shipping a pattern the industry abandoned four years ago.

![](/images/blog/crypto-wallet-ux-teardown/body-2.png)

## The "Which Blockchain?" Problem

Payy's deposit flow asks the user three questions in sequence: Which Crypto Exchange? Which Blockchain? Which Token? Each question is followed by a list of options with no explanation of what choosing one over another means for fees, speed, or whether the transaction will arrive.

This is the crypto UX problem in its purest form. Users are being asked to make infrastructure decisions — the equivalent of a Venmo user being asked to choose between ACH, Fedwire, and RTP before sending $20. The correct answer for 95% of users is the same in every case. There is no reason to expose the choice.

[65% of new Web3 signups abandon onboarding when confronted with gas fee requirements](https://www.nadcablabs.com/blog/web3-onboarding-conversion), and removing gas friction lifts completion 40–80% according to Nadcab Labs' 2026 analysis. Vitalik Buterin framed this as existential:

> _"Ethereum fails because each transaction costs $3.75 ($82.48 if we have another bull run), and every product aiming for the mass market inevitably forgets about the chain and adopts centralized workarounds for everything."_

The technical complexity isn't going away. But it doesn't need to be visible to users. [Daimo's field research in Istanbul and Beijing](https://www.daimo.com/blog/instant) captured the gap perfectly — a Turkish crypto teller asked,

> _"How did I pay the fee? I didn't have ETH?"_

Each chain's token represented a distinct entity to that user, not a venue. When chain selection was hidden and defaults chosen automatically, the same user transacted without confusion.

The products moving in the right direction abstract three layers simultaneously: keys (passkeys over seed phrases), gas (paymasters that absorb fees), and chains (intents that route automatically). Coinbase Smart Wallet's trajectory — passkey-based, gasless, 8 chains at launch — is the reference implementation. Circle's CCTP now moves $500M+ in USDC across chains daily via burn-and-mint, eliminating the wrapped-token confusion that produced endless wrong-network losses.

For CPOs: visible chain selection is a failure mode, not a feature. The network is infrastructure. Users should never see it.

## Identity and Trust Signals

A wallet is a financial identity. The products that make it feel like one from the first session earn more sustained usage than the ones that don't.

**Phantom's @username and avatar** make the wallet personal immediately. The design cue is simple — give the wallet a name the user chose and a face they recognize — but the effect is ownership. A wallet that feels like mine is one I return to. A wallet that feels like a software container is one I might abandon the first time something doesn't work.

**Cash App's $Cashtag** is the same principle taken further. It's a financial identity that's shareable, memorable, and tied to a specific person. When someone sends money to $username, the transaction feels like a social gesture, not a database operation. This is why Cash App's retention rises with social graph depth — the product is building financial identity, not just payment infrastructure.

**Coinbase Wallet's "Address 1"** is the anti-pattern. A 42-character hex string that no user will ever remember or share voluntarily. It signals that the wallet was designed for a user who understands what a public key is — not for someone trying to receive their first USDC.

On trust signals: **Cash App's FDIC badge** sits at the bottom of the home screen, quiet and persistent. It doesn't demand attention. It answers a background question users carry into every financial app — _is this real? is my money safe?_ — without making the product feel insecure for needing to answer it.

Crypto products face a harder trust problem than fintech. [Morning Consult data shows banks are trusted to protect from fraud by a 6-to-1 margin over the next closest industry — with banks at 50% versus crypto at 2%](https://morningconsult.com/2025/11/american-bankers-association-report/). The FTX collapse inverted the celebrity-endorsement calculus permanently: large-name crypto endorsements now carry a discount, not a premium. The design implication is that trust in crypto must be earned through product behavior — transparency of fees, clarity of custody model, verifiability of reserves — not signaled through badges.

**Trust Wallet** leads the group on formal trust credentials: the first wallet to achieve ISO/IEC 27001:2022 and ISO/IEC 27701:2019 certification. With 220M+ downloads, 100+ supported blockchains, and $191M+ blocked from scam addresses by its security scanner, it has the institutional credibility surface that self-custody crypto has historically lacked.

## Empty States as First Impressions

Every new wallet starts at $0.00. The empty state is the first active experience a user has after completing onboarding — and most wallets treat it as nothing.

**Coinbase Wallet's** "Add crypto to get started" is functional. It answers the next-step question clearly, even if impersonally.

**Phantom's** $0.00 with no guidance is a dead end. The user who just completed setup, wrote down their seed phrase, enabled Face ID, and arrived at the home screen sees a number that tells them nothing about what to do next. For a first-time crypto user, this is the moment they close the app and don't come back.

**Cash App's** empty state sets the feature promise. The balance is zero but the product already communicates what it does and why it matters. The empty state is treated as onboarding content, not as an absence of content.

**Payy's** empty state is the most minimal and the most consistent with the product's thesis. Zero balance, two buttons. The buttons are the product. Nothing more is needed.

The pattern: the empty state is not negative space. It's the last onboarding screen — the moment that determines whether the user takes the first action or leaves. Design it as if it's the most important screen in the product, because for activation, it is.

## The Masterly Wallet UX Framework

Six principles derived from the patterns across all five products. They apply to any financial product asking users to trust it with real money — crypto wallet, neobank, payment app, or fintech onboarding flow.

| Principle | The question | What breaks | What works |
| --- | --- | --- | --- |
| Balance first | Does the home screen answer "how much do I have?" in under 2 seconds? | Competing content, discovery-first layout | One dominant number, clear visual hierarchy |
| One action owns the screen | Is there a single primary action that's visually dominant? | 4–6 equal-weight buttons | Add/Withdraw, Deposit/Request, Buy |
| Explain before asking | Do users understand why security matters before setup? | PIN creation with no context | Education screens before setup flow |
| Abstract complexity | Are chain/token/gas decisions hidden behind defaults? | "Which Blockchain?" on every deposit | Smart defaults, advanced settings for experts |
| Make it personal | Does the product feel like MY wallet from the first session? | "Address 1", generic avatar | @username, avatar, named identity |
| Design for $0 | Does the empty state guide toward the first action? | $0.00 with no prompt | Clear next step, feature promise |

The 10× activation gap between fintech and crypto is not a technology problem. The wallets with better UX metrics — Cash App, Phantom, Payy — didn't get there by shipping better blockchain infrastructure. They got there by understanding that users don't trust protocols. They trust products.

We help fintech and Web3 teams close the gap between what their product does and what users are willing to do with it.

[Talk to us about your product →](/client-industries/fintech)

Related: [Fintech Design in 2026: Why Most Apps Look the Same](/blog/fintech-design-guide) · [AI Product Design: How to Build Interfaces Users Actually Trust](/blog/ai-product-design-guide) · [How to Conduct a UX Audit](/blog/ux-audit-guide)

---

### AI Product Design: How to Build Interfaces Users Actually Trust
URL: https://www.themasterly.com/blog/ai-product-design-guide
Product · 2026-04-23

There is a widening gap at the center of every AI product right now. [According to Stack Overflow's 2025 developer survey](https://stackoverflow.co/teams/resources/2025-stack-overflow-developer-survey-for-leaders/ai-adoption/), 84% of developers use or plan to use AI tools — usage is rising every year. In the same survey, only 29% trust AI outputs to be accurate. That's down from 40% in 2024. And [KPMG's 2025 global study across 47 countries](https://kpmg.com/xx/en/our-insights/ai-and-technology/trust-attitudes-and-use-of-ai.html) found that while 66% of people use AI regularly, only 46% are willing to trust it. Usage and trust are moving in opposite directions.

This is not a model problem. The models are improving rapidly. It is a design problem — and the most expensive version of it is a product that users try once, hit a bad answer with no recovery path, and abandon permanently. Trust in AI is asymmetric: many positive interactions to build it, one bad answer in a high-stakes flow to collapse it.

[Gartner estimates that 30% of generative AI projects will be abandoned after proof-of-concept](https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025), citing poor data quality, inadequate risk controls, and unclear business value. The design teams working on those products didn't fail because their features were technically weak. They failed because the interface wasn't designed for the reality of probabilistic output.

## The Failure Gallery: What Destroyed Trust in Real Products

The clearest way to understand AI UX is to study where it went wrong in production. The failures below are not edge cases — they are now the reference cases for what not to do.

### Air Canada's chatbot invented a policy it had no authority to create.

In [_Moffatt v. Air Canada_ (2024 BCCRT 149)](https://www.canlii.org/en/bc/bccrt/doc/2024/2024bccrt149/2024bccrt149.html), Air Canada's AI chatbot told a grieving customer that a non-existent retroactive bereavement fare discount was available. The BC Civil Resolution Tribunal ruled against Air Canada and ordered it to pay C$812. Tribunal Member Christopher Rivers wrote what should be posted on every AI product team's wall:

> "It should be obvious to Air Canada that it is responsible for all the information on its website. It makes no difference whether the information comes from a static page or a chatbot."

The design failure was a single missing constraint: the chatbot had no grounding in actual policy documents and no fallback that said "I'm not certain — contact support."

### Klarna replaced 700 agents with AI, then reversed course publicly.

In February 2024, Klarna announced its AI assistant was doing the equivalent work of 700 full-time agents. Headcount dropped from 5,527 to 3,422. In [May 2025, CEO Sebastian Siemiatkowski reversed course on Bloomberg](https://www.bloomberg.com/news/articles/2025-05-08/klarna-turns-from-ai-to-real-person-customer-service):

> "From a brand perspective, a company perspective, I just think it's so critical that you are clear to your customer that there will always be a human if you want. As cost unfortunately seems to have been a too predominant evaluation factor when organizing this, what you end up having is lower quality."

The design failure was deploying autopilot without a human escalation path at scale, treating cost reduction as the design brief rather than user outcome.

### Apple Intelligence's error state was invisible.

The product's AI summarized news headlines — and got them badly wrong. Summaries falsely reported that a high-profile suspect had shot himself, that a world leader had been arrested, and that a celebrity athlete had come out as gay. [Apple paused news summarization on January 16, 2025](https://www.theregister.com/2025/01/17/apple_intelligence_summaries_disabled/) following a formal BBC complaint. The critical design failure was the error state: a small glyph marked AI-summarized content, but it was too subtle to protect publishers' reputations or signal to readers that verification was needed.

### Cursor's undisclosed AI support agent created a legal and PR incident.

When a race-condition bug caused unexpected subscription cancellations, [an AI support agent named "Sam" — with no disclosure that it was AI — told developers that a non-existent "one device per subscription" policy had always existed](https://www.theregister.com/2025/04/18/cursor_ai_support_bot_lies/). Developer cancellations went public on Hacker News. CEO Michael Truell issued a formal apology. Cursor now labels AI responses explicitly. The design failure: deploying an AI agent with no identity disclosure and no mechanism to say

> "I don't know the current policy — let me connect you to a human."

There is a compounding dynamic worth naming. As AI compresses workflows that previously required multiple human reviewers into a single-operator task, the **"Reviewer Trusts the Research Layer"** phenomenon emerges: the professional assumes the AI's high-fidelity, well-formatted output has already been validated. [The Deloitte government report incident](https://fortune.com/2025/10/07/deloitte-ai-australia-government-report-hallucinations-technology-290000-refund/) is the clearest example — a $290K engagement delivered a 237-page document with fabricated court citations and a hallucinated Federal Court judgment. The internal review process was optimized for human error, not for high-confidence synthetic inaccuracy.

The pattern across all these cases is the same: **confident wrongness at a high-stakes moment, with no recovery path.** Research by Dietvorst, Simmons & Massey confirms this is structural — people lose confidence in AI forecasters faster than in human forecasters after a single mistake, even when the AI demonstrably outperforms. The interface compounds this when it presents every output with the same confident tone, regardless of the model's actual certainty.

## The Four Principles: Show, Signal, Defer, Recover

The Masterly AI Interface Framework organizes AI UX decisions into four principles, each addressing a different layer of the trust problem.

**Show** — make reasoning visible.

**Signal** — communicate uncertainty honestly.

**Defer** — know when to involve a human.

**Recover** — design for when the AI gets it wrong.

### Show: Make Reasoning Visible

Users trust what they can verify. AI output presented without reasoning forces users to either accept it uncritically or reject it entirely — neither of which is the behavior you want in a product that competes on reliability.

**Perplexity** is the clearest production example of explainability done well. Every answer shows numbered inline citations placed immediately after the sentence they support. Above each response, a sources panel displays 5–10 cards with favicon, publication, title, and snippet. Crucially, Perplexity will decline to generate an answer when retrieval surfaces no reputable sources — refusal as a trust signal, not a failure state. The interface is saying: "I won't guess. Here's what I found."

**Linear's Triage Intelligence** uses a different model — natural language attribution rather than citations. A hover on an AI assignment suggestion shows:

> "This person was the assignee on previous issues related to performance problems in the mobile app launch flow."

Linear's own framing:

> "If you are going to act on AI-generated suggestions, you need to see where they came from and believe in their accuracy. The UI makes that distinction clear, so you always know what came from the system and what came from your team."

**Granola** pushes timestamp attribution to its logical limit. Every AI-added bullet renders in gray (user-typed content renders in black) and hyperlinks directly to the exact second in the meeting transcript where the information appeared. The authorship distinction is visual and immediately verifiable. Gong does the same for deal intelligence — every AI-generated warning links to the call clip that drove it.

**GitHub Copilot** takes a different approach entirely: it doesn't explain suggestions in prose. It reduces mystery through context-awareness. The suggestion appears in-line with the code you're already writing, dimmed as ghost text. The implicit reasoning is

> "this came from your codebase, your patterns, your context."

The trust signal is familiarity, not citation. It works because rejection is free (one keystroke) and the low commitment cost means users don't need certainty before trying.

In fintech, a particularly powerful form of explainability is the **counterfactual**: instead of just explaining why a loan was declined, the interface shows what would need to change to get a different outcome —

> "If your income were $500 higher, this loan would be approved."

This shifts the output from a verdict into actionable information, which is the difference between explainability as compliance and explainability as product value.

The principle applies across product types. If your AI classifies a support ticket as high priority, show the signals that drove it. If your AI flags a transaction as suspicious, show the pattern that matched. Reasoning doesn't need to be a technical explanation — it needs to be enough signal for a user to say "yes, that makes sense" or "no, that's wrong, let me fix it."

![](/images/blog/ai-product-design-guide/body-1.png)

### Signal: Communicate Uncertainty Honestly

Not all AI output is equally reliable. The problem is that most interfaces present it as if it were. A label, a recommendation, a summary, a classification — they all look identical on screen, regardless of the model's actual confidence behind them.

[MIT research found that AI models use 34% more confident language when hallucinating than when correct](https://news.mit.edu/2026/better-method-identifying-overconfident-large-language-models-0319). The most dangerous product decision is showing miscalibrated confidence — it is worse than showing none.

**Gong's AI Deal Predictor** is the clearest example of getting this right. It explicitly states that the score is a percentile rank, not a probability: a deal scored 80 has

> "a better chance of closing than 80% of your other open deals"

— not

> "an 80% chance of closing."

This single clarification prevents an entire class of misinterpretation that would otherwise cause salespeople to over-rely on the score in the wrong situations.

**Grammarly** uses visual weight as confidence encoding. High-confidence grammar errors get prominent red underlines. Stylistic suggestions get softer blue, purple, or green — a different color tier that communicates

> "this is optional judgment, not a definite error."

Users calibrate naturally without reading any explanation.

**Ramp's Accounting Agent** adds an icon-and-color hierarchy. Icons signal source (person = human, bolt = rule, AI icon = AI-coded). Colors signal confidence tier — yellow for medium-low with hover details explaining why. Crucially, the AI never overrides values already set by an employee, admin, or rule. There is a clear, visible hierarchy of trust built into the product's visual language.

**Stripe Radar** deprecated its single raw fraud score in favor of category-specific models — a fraudulent-dispute score, an early-fraud-warning score, a bot score — each with its own threshold and categorical label (_normal, elevated, highest_). The explicit acknowledgment that a single confidence number is a blunt instrument is itself a trust signal.

The pattern that works across all of these: **calibrated confidence, not inflated certainty**. Labels like "likely," "needs review," "low confidence," or a confidence-based routing path that escalates uncertain cases to humans rather than presenting everything with equal authority. The goal, as Google PAIR frames it, is not maximum trust — it is _accurate_ trust.

### Defer: Know When to Involve a Human

Andrej Karpathy's framing from YC AI Startup School in 2025 now describes how the best B2B AI products are built:

> "Less AGI hype and flashy demos that don't work. More partial autonomy, custom GUIs and autonomy sliders."

The insight is that the right level of automation is not a fixed product decision — it is a product surface that should be designed, configured, and surfaced to users.

**Cursor's four modes** _(Tab inline completion → ⌘K inline edit → ⌘L chat → ⌘I Agent)_ is the canonical implementation. Each mode represents a different point on the autonomy slider. Agent mode streams a live activity log of every file read, write, and command executed — making the AI's actions transparent and stoppable at any point. Automatic checkpoints snapshot state before each action and surface one-click restore on every prior message. The kill-switch is a feature, not a failsafe.

**Intercom Fin** shows the same principle at the support level. The product is involved in 99% of conversations but resolves 51–65% end-to-end. The remainder escalates with full context — conversation history, customer record, resolution attempt — so the human agent doesn't start from zero. The escalation path is designed, not an accident. Adding a well-designed escalation path lifts best deployments from the ~60–70% resolution ceiling that pure autopilot hits before satisfaction collapses.

A powerful pattern for any agentic or multi-step AI action is the **"Action Plan"**: before executing, the AI shows the steps it intends to take and waits for confirmation. This turns a one-shot command into a collaborative refinement. Cursor's Agent mode does this by streaming the plan before writing code. The pattern is particularly important for irreversible actions — sending an email, updating a shared record, executing a payment — where the cost of a misunderstanding is asymmetrically high.

The general rules for when to defer:

Use human review when the output is **hard to reverse** (sent emails, published content, executed payments), **externally visible** (customer-facing messages, public records), or **carries legal or compliance consequence** (healthcare decisions, financial advice, contract language). The approval gate before irreversible action is not friction. It is the product being honest about the stakes.

**Confidence-based escalation** is the operational implementation: above a high-confidence threshold, auto-execute; in the middle range, show but require confirmation; below a low-confidence floor, route to human review or decline to generate. Stripe Radar blocks highest-risk transactions by default. All 13+ FDA-cleared AI stroke detection systems alert physicians but require physician confirmation before treatment — regulatory design that forced a good HITL pattern.

The Klarna CEO's reversal is the data point worth remembering. Pure autopilot without escalation is an optimization for one metric (cost per ticket) at the expense of the metric that actually compounds: user trust.

![](/images/blog/ai-product-design-guide/body-2.png)

### Recover: Design for When AI Gets It Wrong

Every AI product will produce wrong output. The question is not whether — it is whether the interface is designed to handle it without destroying the relationship.

**Good AI error recovery has three parts.** First, a legible failure state: the interface tells users what went wrong in terms they can act on. Not "something went wrong" — but "we couldn't find an answer in your workspace for this query. Try rephrasing, or expand to general knowledge." Notion AI Q&A uses exactly this pattern: a specific failure message followed by an offer to expand scope.

Second, a correction path: users can tell the system it was wrong, provide better context, or override the output. This is where most products fail. They present AI output as a read-only result rather than a starting point. A summary field that can't be edited, a classification that can't be disputed, a recommendation with no "this is wrong" mechanism — these tell users the system doesn't expect to be wrong, which makes the inevitable mistake feel worse. Diff previews with Accept/Reject UI (Cursor's multi-file review, Copilot's Tab/Esc, Notion's suggested edits) encode this correctly: every AI output is a proposal until the user approves it.

Third, a feedback signal: corrections should improve future outputs or at minimum be acknowledged. The ability to modify output beats any confidence display for reducing algorithm aversion — Dietvorst, Simmons & Massey's 2018 research found that even allowing users to slightly modify algorithmic forecasts dramatically reduces abandonment, even when users don't actually change anything.

**The audit trail** matters especially in regulated industries. Healthcare, finance, and legal products need to show what the AI recommended, when, based on what input, and what the human did with it. This is not overhead — it is the feature that makes AI usable in those contexts at all. Harvey, the legal AI, publishes a hallucination rate of approximately 0.2% on internal benchmarks and provides a full paper trail of reasoning steps and citations for every output. That paper trail is not a liability disclosure — it is the product's core trust signal.

## Onboarding: Teach AI Without a Manual

The four principles above govern what happens during use. There's a prior question that determines whether users ever get there: what happens before the first interaction.

The worst AI onboarding is a product tour that explains what the AI is. The best AI onboarding shows users one useful job, in the real context where the feature appears, on their own content.

[Notion's launch retrospective](https://www.notion.com/blog/lessons-we-learned-from-launching-notion-ai) confirms this: the team discovered that users needed to see the feature working on their own documents and databases — not on a demo. The disconnect between "impressive in a demo" and "useful in my actual workflow" is where most AI feature activation drops off. They also found users preferred "Improve Writing" over content generation, which was the opposite of initial assumptions — a reminder that AI onboarding should be shaped by observed behavior, not product intuition.

The specific patterns that work across the products we've studied:

**Empty-state suggestion cards** with workspace-aware prompts (Notion Q&A shows rotating examples tied to the user's recent pages), one click to insert.

**Input-label change** as the cheapest onboarding mechanism — Cursor's Composer placeholder changes from "ask me code questions" to "Tell me what to build..." when Agent mode is toggled. The input field itself teaches the new capability.

**Opt-in activation paired with plain-language disclosure** consistently outperforms opt-out default. Arc Max, Superhuman, and Grammarly Business all require explicit activation — and user trust is measurably higher than products that default AI on.

**Interactive sandboxes** before deployment (Intercom Fin's preview-against-your-content flow before going live) sets accurate expectations before a single customer interaction.

The most important thing to communicate early is what the AI _cannot_ do. Notion Q&A's documentation lists explicit constraints: "Doesn't search through databases (yet)... Can't reach into private pages you don't have access to... Doesn't have access to wider knowledge." Capability boundaries are onboarding content, not fine print.

One counter-intuitive finding from a Prototypr.ai experiment: inverting onboarding from "explain the system" to "show an AI output first" lifted Day-1 retention by 53%. When value precedes explanation, friction drops and activation rises.

## The Masterly AI Interface Framework

Four questions that map to the four principles — and reveal where a given product is leaving trust on the table.

| Principle | The question | Weak signal | Strong signal |
| --- | --- | --- | --- |
| Show | Can users see why the AI said what it said? | Output appears with no reasoning or source | Inline citations, attribution tooltip, or explicit reasoning visible |
| Signal | Does the interface communicate uncertainty honestly? | All outputs look equally confident | Calibrated labels, confidence tiers, or "needs review" flags |
| Defer | Does the system know when to involve a human? | AI takes irreversible actions automatically | Approval gates, escalation thresholds, configurable autonomy level |
| Recover | Can users correct the AI and move forward? | Output is read-only, no feedback mechanism | Edit, reject, and feedback affordances on every AI output |

The stakes of getting this wrong are measurable. One documented case shows AI categorization tool adoption collapsing from 89% to 11% within three days — simply because the tool added confidence scores and reasoning after initially shipping without them. Users didn't distrust the AI because it was wrong. They distrusted it because it couldn't tell them how confident it was.

A product that scores "strong signal" on all four dimensions is one where users can calibrate how much to trust the AI, verify its reasoning, correct it when it's wrong, and understand what it's doing — which is the foundation for sustained, expanding usage rather than initial curiosity followed by abandonment.

The Klarna CEO's reversal quote is the right framing for the whole framework:

> "I just think it's so critical that you are clear to your customer that there will always be a human if you want."

The companies that learn that earlier will ship the AI products the next decade is built on.

AI products fail not because the technology is wrong but because the interface isn't designed for the reality of probabilistic output. That requires a different design posture: uncertainty made visible, reasoning made legible, humans kept in the loop where stakes demand it, and recovery paths built for the failure case, not just the happy path.

[94% of B2B buyers now use LLMs during their research phase](https://corporatevisions.com/blog/b2b-buying-behavior-statistics-trends/). The interface of your AI product is increasingly the first thing a prospective customer evaluates — not the model behind it. Building that interface well is not a UX problem. It is a growth problem.

We help product teams design AI interfaces that users actually trust — and keep using after the first mistake.

[Talk to us about your AI product →](/client-industries/ai-ml)

Related: [Do You Actually Need a Design System?](/blog/design-system-decision-guide) · [Fintech Design in 2026: Why Most Apps Look the Same](/blog/fintech-design-guide) · [How to Conduct a UX Audit](/blog/ux-audit-guide)

---

### Do You Actually Need a Design System? A Decision Guide for Product Teams
URL: https://www.themasterly.com/blog/design-system-decision-guide
Design Systems · 2026-04-21

Most product teams ask the wrong question. They ask "should we build a [design system](/glossary/design-system)?" when the answer is almost always yes — eventually. The question that matters is _when_, and getting it wrong in either direction is expensive.

[According to research by Storybook and Brad Frost](https://storybook.js.org/blog/why-most-design-systems-implode/), only 40% of design systems are considered successful by their own teams. The failures cluster into two predictable patterns: teams that built too early, optimizing UI infrastructure for a product that pivoted six months later. And teams that waited too long, inheriting years of inconsistency debt that no one had the runway to fix.

This is a timing problem more than a design problem. And like most timing problems, it looks obvious in retrospect and genuinely difficult in the moment.

## What a Design System Actually Is (And What It Isn't)

Before the decision, a definition — because this is one of the most consistently misunderstood terms in product.

A **[component library](/glossary/component-library)** is an artifact: the actual buttons, inputs, cards, and layouts, in code or in Figma. It's the thing you can point to.

A **design system** is everything around it: the [design tokens](/glossary/design-token) that define your visual language, the documentation that explains decisions, the governance that keeps it consistent, and the shared mental model between design and engineering. Brad Frost's definition is worth quoting precisely: a design system is

> _"a living, funded product with a roadmap and backlog serving an ecosystem."_

Not a [style guide](/glossary/style-guide). Not a Figma file. A product that serves other products.

Most teams that say they're building a design system are actually building a component library. That's fine — a component library is often the right thing to build. But treating it as a complete design system creates a gap between expectation and reality that leads directly to adoption failure later.

## The Real Question: Explicit vs. Implicit

Every product already has a design system. The question is whether it's explicit or implicit.

A two-person startup that chose Tailwind defaults and shadcn components has made systemic decisions about spacing, color, and typography. Those decisions exist — they're just undocumented, inconsistent, and living in individual engineers' heads. The investment question is when to make those decisions explicit, shared, and defended.

Pre-PMF, UI is experimental. You will rewrite it. Investing in infrastructure for UI that doesn't exist yet is the definition of premature optimization, and experienced design leads consistently describe it the same way:

> _"We paused product work to finish the system, delayed launches, and ended up as an organizational bottleneck."_

Post-PMF, UI is an asset. It represents real design decisions that deserve infrastructure. The inconsistency debt that accumulates when you wait too long is harder to see until it's everywhere — five button styles, three spacing scales, UI decisions copied from the last thing an engineer saw rather than from any intentional standard.

## Six Triggers That Tell You It's Time

Stage and headcount are rough proxies. The real signals are behavioral. Experienced design leads consistently point to the same triggers — these matter more than funding round or team size:

### The rule of three

The first time you build a UI pattern, just build it. The second time, copy it. The third time, extract it into a shared component. This rule scales: the third time designers debate "which shade of gray for borders," it's time for a tokens file. The third product surface that needs coordinated UI (app, marketing site, mobile) is when shared language stops being optional.

### Your third frontend engineer joins

Before that, code review handles consistency informally. After that, conventions become tribal knowledge that doesn't transfer during onboarding. If a new engineer takes more than a day to understand "how we do UI here" — the system is already overdue.

### Inconsistency that users or sales notice

When a customer says "your onboarding looks different from your dashboard," or a sales rep struggles to demo a product that looks unfinished — that's the moment. It's not a visual problem at this point. It's a credibility problem.

### The first designer hire beyond the founding designer

Two designers working without shared standards will immediately diverge. Every week without a shared library is a week of diverging decisions that someone will eventually reconcile.

### You're preparing for a product launch or fundraise

Both require a product that looks intentional. A design system doesn't need to be complete for this — it needs to be directionally consistent.

### The moment tribal knowledge stops transferring

When new hires can't find where decisions live, or when the answer to "why does this work this way" is "ask \[specific person\]" — the system is already failing silently.

Notably absent from this list: "we raised a Series A" or "we hired a designer." Money and headcount enable investment but don't themselves justify it.

## Stage-by-Stage: What to Build When

| Stage | Team size | Invest in | Skip |
| --- | --- | --- | --- |
| Pre-seed / ideation | 1–3 people | Tailwind config, shadcn/ui as-is | Custom anything |
| Seed / MVP | 3–10 people | Design tokens file, 5–10 reusable components, shared Figma library | Governance, docs site, contribution model |
| Post-PMF / Series A | 10–30, 1–3 designers | Named component library, token pipeline, Storybook, light docs | Dedicated DS team, formal council |
| Scaling / Series B+ | 30+, 3+ designers | Dedicated owner, contribution process, accessibility standards, versioning | Enterprise-scale governance |
| Series C+ | 100+ | Full governance, multi-brand theming, adoption metrics | — |

![](/images/blog/design-system-decision-guide/body-1.png)

The critical insight: the table describes what to make explicit at each stage, not what exists. The tokens, the components, and the decisions already exist at every stage. The investment is in making them visible and shared.

## Build vs. Buy in 2026

This used to be a harder question. In 2026, for most web product teams, the answer is almost always: **extend, don't build from scratch.**

The modern lean stack looks like this: [shadcn/ui](https://ui.shadcn.com/) (or Radix UI, Mantine, or Chakra, depending on your aesthetic and framework) for the component layer — accessible, composable React components that you own and can modify. [Tailwind CSS](https://tailwindcss.com/) with a custom `tailwind.config.js` that encodes brand tokens as the single source of truth for color, spacing, and typography. A mirrored Figma Variables file that references identical values, so designers and engineers share one language.

According to Supernova's [State of Design Tokens 2024 report](https://www.supernova.io/state-of-design-tokens), 69.8% of design teams have already adopted Figma Variables — making tokens, not components, the true foundation of a modern design system. The teams winning in 2026 are the ones that established this token foundation early and everything else follows from it.

What this stack gives you: a system that can be stood up in a day, carries a product from pre-seed through Series A without meaningful refactoring, and — critically — produces better output from AI code generation tools. Vercel's v0, Cursor, and other AI codegen tools default to shadcn + Tailwind. A team with this stack gets faster AI-assisted development as a side effect of having a design system. This is the first genuinely new argument for earlier design system investment in a decade: a token file and component library is now AI scaffolding, not just design infrastructure.

What to skip at this stage: a documentation site, a dedicated design system designer, custom-built components that duplicate what Radix already ships, Storybook coverage for every variant. Those are artifacts of maturity, not foundations.

## If You're Vibe Coding, You Need This More Than Anyone

There's a new reason to care about design systems — and it's the most compelling one in years.

AI coding tools have made it possible for a two-person team to build, ship, and iterate a product at a pace that would have required five engineers two years ago. Tools like Cursor, Claude, Bolt, Lovable, and Vercel's v0 can generate working UI from a prompt in seconds. This is real, and it's changing how products are built.

But here's the problem nobody talks about when they demo vibe coding: **AI generates inconsistent UI by default.**

Ask AI to build a modal — it picks colors. Ask it to build a button — it picks different colors. Ask it to build a form — different spacing. Different font size. Different border radius. Each component is fine in isolation. Together, they look like five different products assembled in a weekend.

![](/images/blog/design-system-decision-guide/body-2.png)

This happens because AI has no constraint. It's generating from pattern, not from your product's visual language. It doesn't know that your primary color is `#5B4AE8`, not `#6B48FF`. It doesn't know you use 4px border radius, not 8px. It doesn't know your type scale. So it guesses — and it guesses differently each time.

**A design system is the constraint layer that makes AI output consistent.**

When Cursor or Claude has access to your shadcn components, your Tailwind config with defined brand tokens, and your component documentation, the generated UI actually looks like your product. The AI isn't guessing anymore — it's working within a system. It knows your colors because they're in `tailwind.config.js`. It knows your button because it's a named component with defined variants. It knows your spacing because the scale is explicit.

Teams that have figured this out treat their design system as infrastructure for AI, not for designers. The token file is a prompt. The component library is a constraint set. The naming conventions are context. Everything that makes a design system valuable for human engineers makes it equally valuable — arguably more valuable — for AI engineers.

The practical implication: if your team is using AI to build any part of your product UI, the minimum viable design system is no longer optional. A `tailwind.config.js` with your brand tokens is the difference between AI that produces on-brand output and AI that produces "close enough but not quite right" output that someone has to manually fix after every generation cycle.

The 2026 stack (shadcn + Tailwind + Figma Variables) was already the right answer for human teams. It's now also the right answer for AI-assisted teams — which, at this point, is nearly everyone.

## Why Most Design Systems Fail: The Adoption Problem

The 60% failure rate isn't a design problem. It's an adoption problem.

The most common failure pattern: a senior designer joins, spends four months building a comprehensive Figma component library, and ships it. Engineering never adopts it, because the product pivoted twice during the build and because nobody asked engineering what they needed. The system is technically complete and functionally abandoned.

The governance lesson from every mature system — Shopify Polaris, Atlassian Design System, IBM Carbon, GitHub Primer — is that successful systems are contribution-friendly from day one, even if the formal contribution process doesn't exist until later. Brad Frost's framing is precise: the design system team should provide **ingredients, not finished meals**. Product teams should be able to build their own components using system primitives, with the design system team curating which recipes graduate into the shared library over time.

Systems that fail are almost always gate-kept by a small central team that product teams either wait on (frustration), fork (fragmentation), or bypass entirely (invisibility). All three outcomes destroy the consistency the system was supposed to deliver.

Measurement matters more than most teams realize. Pinterest built an internal tool called [FigStats](https://www.figma.com/blog/how-pinterests-design-systems-team-measures-adoption/) that scans every Figma file nightly and computes a component adoption percentage. They open-sourced it because without adoption metrics, design system budgets are among the first cut in downturns — which happened extensively during 2023–2024. If you can't show component reuse rates and token coverage, you can't defend the investment.

## The ROI Question (For the CPO)

Design system ROI doesn't show up on a single sprint. It shows up in four places over time.

### Velocity

The most consistent ROI claim from teams with mature systems: new feature UI takes hours, not days. Engineers stop making spacing and color decisions from scratch. Designers stop specifying components that already exist.

### Consistency

Every inconsistency in a product is a decision that will be revisited. Five button styles means five debates, five QA cycles, five places to update when the brand changes. A design system trades a one-time investment for ongoing reduction of that overhead.

### Onboarding

When design conventions are documented and accessible, new hires become productive faster. The "how do we do X here" question has an answer that doesn't require the founding designer.

### AI leverage

A team using Cursor, Claude, or v0 without a design system gets inconsistent UI that someone has to manually clean up after every generation cycle. A team with a token file and component library gets on-brand output by default. The design system becomes the constraint layer that makes AI work correctly — not just faster, but consistently.

The clearest signal that a design system is working: the conversation about "should we build a new component" shifts from "let me create this from scratch" to "is there already a component for this?" That shift usually happens within 3–6 months of a system reaching critical mass.

## Masterly Design System Readiness Framework

Four questions that determine whether your team is ready to invest — and at what level.

| Dimension | The question | Pre-investment signal | Investment signal |
| --- | --- | --- | --- |
| Signal | Are the right triggers present? | First or second pattern repeat, single designer | Rule of three active, 3rd engineer joined, inconsistency visible to users |
| Scope | What level of system fits your stage? | Token file + shared Figma library | Named component library + docs + light governance |
| Stack | Build from scratch or extend? | Tailwind + shadcn as-is, no customization | Custom token layer on open-source foundation |
| Stewardship | Who owns and maintains it? | Everyone and nobody (OK pre-PMF) | Named owner, contribution model, adoption metrics |

A team that scores "investment signal" on all four dimensions has already waited too long. The goal is to move from implicit to explicit on each dimension _before_ the signal becomes a fire.

The deepest insight from a decade of design system post-mortems applies here: **the system is not the artifact — it is the agreement.** A two-page README describing "we use these six colors and these four font sizes" is a more valuable design system than a 300-component Figma library that no one opens. Teams that remember this tend to succeed. The 60% that end up in the failure column tend to have forgotten it.

If your team is spending more time debating UI decisions than shipping features — or if your product looks different across every surface — the problem is usually not execution. It's the absence of a shared agreement.

We help product teams build design systems that engineering actually adopts: lean enough to ship fast, structured enough to scale.

[Talk to us about your design system →](/services/design-system)

Related: [How to Conduct a UX Audit](/blog/ux-audit-guide) · [Fintech Design in 2026: Why Most Apps Look the Same](/blog/fintech-design-guide) · [The Complete Guide to SaaS Onboarding UX](/blog/saas-onboarding-ux-guide)

---

### How to Conduct a UX Audit (And What to Do with the Findings)
URL: https://www.themasterly.com/blog/ux-audit-guide
UX · 2026-04-20

Most UX audits fail before they start — not because the team lacks skill, but because the scope is too narrow. A design team reviews a few screens, marks some contrast issues and unclear button labels, and hands back a PDF of annotated screenshots. The client nods, fixes two things, and six months later wonders why conversion still hasn't moved.

The problem: they got a design review, not an audit.

A real [UX audit](/glossary/ux-audit) is a diagnostic. It looks at the product the way a doctor looks at a patient — not just the surface symptoms, but the underlying systems. Design is one layer. Information architecture is another. So is technical performance. So is how well the product actually supports the business model it's supposed to serve.

This article explains how we structure UX audits at Masterly, with examples drawn from a real engagement: a high-traffic pop-culture media website with over 100,000 monthly visitors, thousands of articles, and a monetization model built around display advertising and a subscription tier.

## What a UX Audit Is (And What It Isn't)

A UX audit is a structured evaluation of a digital product that identifies friction, usability failures, and design inconsistencies — and connects them to outcomes the business cares about.

The word "audit" matters. An audit produces findings, not opinions. Every observation should be traceable to a user behavior, a heuristic principle, or a measurable impact. "The navigation looks cluttered" is an opinion. "The navigation combines six content types and three format types in a single row with no visual hierarchy, making it impossible for a user to predict where they'll land" is a finding.

A UX audit is also not a redesign. It's not a recommendation to rebuild everything. A good audit tells you what's broken, what's sub-optimal, what's actually working, and in what order to address it. The output should enable confident decisions — not more debate about whether to change something.

## When You Need a UX Audit

The clearest signal is a gap between traffic and outcomes. If users are arriving and leaving without converting, subscribing, or engaging, something in the experience is creating friction or confusion that analytics alone can't explain.

| Symptom | What it usually means | Most relevant audit layer |
| --- | --- | --- |
| High traffic, low conversion | Friction in the critical path — CTA, onboarding, or pricing flow | Design Review + Monetization |
| Good desktop metrics, poor mobile | Performance or layout issues on mobile specifically | Technical Performance + Design Review |
| Traffic dropping without obvious cause | Indexability problems, crawl issues, or Google quality signals | SEO Health |
| Users complete onboarding but don't return | Weak activation loop or no clear "next action" after setup | IA + Design Review |
| New team inheriting an existing product | No documented baseline — need to understand what works before touching anything | All 6 layers |
| Pre-redesign | Redesigning without a baseline means repeating the same mistakes | All 6 layers |
| Monetization underperforming despite traffic | Ad placement, subscription CTA, or upsell moment design | Monetization |

### Before a redesign.

Launching a redesign without understanding why the current product is underperforming is expensive. An audit gives you a baseline — what to preserve, what to fix, and what to rethink entirely.

### After a product has grown beyond its original design.

Features get added. New templates get built. Teams change. The original design logic degrades. What started as a clean system becomes a patchwork of inconsistencies that slows users down without any single person having intentionally broken it.

### When a new stakeholder needs to understand the product quickly.

A new CPO, a new design lead, or a new agency coming onto an existing product benefits enormously from a rigorous audit before making any changes.

### When monetization is underperforming.

This is underrated. Design directly affects ad viewability, subscription conversion, and the effectiveness of upsell moments. A UX audit that covers monetization logic is often the fastest path to meaningful revenue improvement.

## The 6-Layer Audit Framework

A comprehensive audit covers six distinct layers. Each can be run independently depending on scope, but they compound: performance issues affect ad revenue, IA issues affect SEO, design inconsistencies affect trust. The full picture is always more actionable than any single layer alone.

| Layer | What it covers | Key questions answered |
| --- | --- | --- |
| 1\. Design Review | Heuristic evaluation, visual hierarchy, consistency, UI patterns | What's creating friction screen by screen? What's working and must be preserved? |
| 2\. Information Architecture | Sitemap, navigation logic, content hierarchy, user flows | Can users find what they came for? What happens after they finish a key action? |
| 3\. Monetization & Conversion | Ad placement, subscription CTAs, upsell moments, pricing page design | Is the product structured to convert? Are revenue moments competing with trust? |
| 4\. Technical Performance | Core Web Vitals, PageSpeed, render-blocking assets, mobile load | Is the experience fast enough to be usable? What's causing performance degradation? |
| 5\. SEO Health | Indexability, URL structure, crawl budget, on-page signals, structured data | What can Google access and rank? Where is crawl budget being wasted? |
| 6\. Analytics | Traffic sources, device split, bounce rate, funnel drop-offs | What does actual user behavior confirm or contradict from the other layers? |

![Horizontal flow diagram. 6 numbered blocks in a row, connected by arrows: 1. Design Review → 2. Information Architecture → 3. Monetization → 4. Technical Performance → 5. SEO Health → 6. Analytics](/images/blog/ux-audit-guide/body-1.png)

The 6-Layer Framework

### Layer 1: Design Review

This is the [heuristic evaluation](https://www.nngroup.com/articles/ten-usability-heuristics/) — the most familiar part of a UX audit, and the one most often done in isolation.

We work screen by screen: home, category, article, author, search results, checkout or subscription flow, footer. For each screen, every element gets classified into one of four tiers — what we call the **Masterly Impact Tiers**:

**Strength** — something that's working and worth preserving. Documenting what's working is as important as documenting what isn't. It prevents teams from accidentally redesigning away things that are actually effective.

**Friction** — usable but suboptimal. These issues create friction or confusion that erodes engagement over time.

**Blocker** — a clear usability failure. Users are being actively misled, blocked, or confused.

**Opportunity** — a design improvement that doesn't fix a current problem but would noticeably increase the value of the experience if implemented.

![](/images/blog/ux-audit-guide/body-2.png)

Masterly Impact Tiers

In the media platform audit referenced here, design review surfaced a consistent pattern: low visual hierarchy everywhere. Navigation mixed content types (Reviews, Movie News, TV News) with domain categories (Comic Books, Wrestling, Music) in a single row, with no logic a user could internalize. Article cards had four elements — headline, date, author, excerpt, rating — all at similar weight and size, so nothing pulled the eye. The "POST COMMENT" button was visually lighter than the "SIGN UP FOR PARAMOUNT+" promotional block directly below it, making an ad look more like the primary action than the actual interaction the user came to take.

None of these are catastrophic errors. All of them compound. A user who can't quickly orient themselves reads less, clicks less, and leaves sooner.

The design review also surfaces what's working. In this case: no pop-ups, no autoplay video, no aggressive interstitials. Reading articles was clean. That's a genuine competitive advantage for an ad-supported platform, and worth naming explicitly so no future redesign accidentally introduces the things the current product wisely avoided.

### Layer 2: Information Architecture

Information architecture determines whether users can find what they came for and discover what they didn't know they wanted. Most IA problems aren't visible in individual screens — they emerge when you map the full structure.

The audit framework maps the current sitemap: every page type, how users navigate between them, what happens when they finish an article, and what the site's structure communicates about content priorities.

Common IA failure modes in content-heavy products:

-   Navigation that mixes formats and topics in the same row, making the hierarchy impossible to read
-   Category pages that behave identically to archives — an article list is not a hub
-   Footer that functions as a dead end rather than a navigation aid
-   Author pages with no identity signals — just a list of articles with a placeholder avatar
-   No clear path from article completion to next article, next topic, or subscription

In the media platform audit, the site had 17,000+ pages buried deeper than three clicks from the homepage, and 12,000+ permanent redirects fragmenting crawl paths. The structure had grown organically over years without a governing IA logic, resulting in what we characterized as "a big blog with many lists" rather than an entertainment hub. Topic hubs — dedicated pages for Marvel, Star Wars, Horror, Anime — didn't exist. When a user arrived at a wrestling article, there was no structured path into more wrestling content. They either clicked a related post at random or left.

The IA redesign recommendation centered on a hub-and-spoke model: clear top-level entry points (News, Reviews, Topics, Specials), dedicated franchise and genre hubs with filtered content, and defined article templates that always included a "More from this topic" module and a clear "Up next" link. Not revolutionary. Entirely achievable. Measurably better for both users and ad impressions.

### Layer 3: Monetization & Conversion

This layer is the one most design teams skip, which is why it's often where the biggest opportunities live.

For ad-supported products, monetization review looks at: where ads are placed, how they're labeled, how they compete with editorial content for visual attention, and whether the ad layout is optimized for the devices users actually use.

In the media platform audit, the primary sponsor's banner appeared above the navigation bar — so the first thing users saw on both desktop and mobile was an ad, not the site's own brand or content. The same sponsor appeared in multiple positions on the same page without clear "Ad" or "Sponsored" labeling, blurring the line between editorial and commercial content. On mobile, desktop-sized banner units were simply scaled down rather than redesigned for the smaller context.

Each of these is a trust issue before it's a revenue issue. Users who feel a site is primarily an ad delivery mechanism — rather than a content platform that happens to carry ads — disengage faster and return less often. Lower return rate means lower total impressions, which means lower ad revenue. The UX problem and the business problem are the same problem.

Monetization recommendations for this client covered four immediate fixes (define clear ad zones, rebalance the first screen so editorial content is visible on load, label ads clearly, design mobile-first ad components) alongside longer-term opportunities (subscription tier with ad removal, curated "fandom paths" at end of articles, topic hubs as high-value contextual ad surfaces, release calendar pages as always-on ad inventory).

For SaaS and subscription products, this layer instead covers conversion flow, onboarding completion rate, upgrade path clarity, and the design of pricing pages and CTAs.

### Layer 4: Technical Performance & Core Web Vitals

A UX audit that ignores performance is incomplete. Slow pages create a user experience problem independently of any design decision. They also directly limit what's possible — a page that scores 47/100 on mobile PageSpeed cannot safely carry additional ad slots or feature richness without degrading further.

The performance layer benchmarks [Core Web Vitals](https://web.dev/articles/vitals) (LCP, CLS, TBT) on both mobile and desktop, identifies root causes, and maps them to specific fixes.

In the media platform audit, mobile performance scored 47/100 on [PageSpeed Insights](https://pagespeed.web.dev/) — significantly below Google's "Good" threshold. The LCP (Largest Contentful Paint) was 22.2 seconds on mobile, meaning users stared at a partially loaded screen for over 20 seconds before seeing real content. Cumulative Layout Shift (0.405) meant buttons and headlines jumped while the page loaded, causing mis-taps and reading position loss. [GTmetrix](https://gtmetrix.com/) gave the site a D grade (55% performance, 78% structure).

![](/images/blog/ux-audit-guide/body-3.png)

Performance Snapshot

Root causes: 29,000+ broken images increasing rendering instability; 42,000+ unminified CSS and JS files increasing payload; inconsistent caching with no object caching configured; render-blocking CSS and JS delaying first paint; oversized media with no compression or lazy loading.

These aren't design problems. But they directly affect design outcomes — ad viewability, engagement depth, bounce rate, and Google's quality signals for organic ranking. A design team that doesn't surface these issues is delivering an incomplete audit.

The performance roadmap prioritized three workstreams in sequence: caching setup (Redis for WordPress, full-page caching), image and media optimization (WebP/AVIF, lazy loading, responsive sizes), and frontend cleanup (deferred non-critical JS, CDN for static assets).

### Layer 5: SEO Health

For content platforms, SEO is an existential concern — organic search is typically the dominant traffic channel. For product companies, it still matters for service pages, case studies, and blog content that supports inbound.

The SEO layer of a UX audit covers: indexability (what Google can and can't access), URL health (duplicates, redirects, broken pages), on-page signals (title tags, meta descriptions, H1s, schema), and crawl efficiency (whether Google's crawl budget is being spent on pages that matter).

The media platform audit revealed critical SEO fragility. A [Screaming Frog](https://www.screamingfrog.co.uk/seo-spider/) crawl — only 52% complete — had already discovered 326,000+ URLs. For a content site, this is far above normal and indicates index bloat: auto-generated archives, infinite pagination loops, and parameter variations creating thousands of near-identical pages that dilute crawl budget and fragment authority.

Specific critical issues: 21,719 mixed-content URLs (HTTP references inside HTTPS pages); 11,831 internal 5xx server errors; 9,191 HTTP URLs lowering canonical consistency; 881 pagination errors creating infinite crawl loops; inconsistent structured data across article and review templates limiting rich result eligibility.

![](/images/blog/ux-audit-guide/body-4.png)

Technical Debt Snapshot

SEO rating: Critical. Immediate action required.

The SEO health layer connects directly to IA. A fragmented URL structure with 12,000+ permanent redirects and 17,000+ pages deeper than three clicks is both an IA problem and an SEO problem. Fixing IA improves SEO. Fixing SEO reinforces the value of IA investment. This is why the layers compound.

### Layer 6: Analytics & User Data

The analytics layer grounds the audit in actual behavior rather than inferred intent. It answers: who is actually using this product, on what devices, arriving from what sources, and what are they doing (or not doing) once they arrive?

For the media platform, analytics revealed a 78.3% desktop / 21% mobile split — unusually low mobile share for a content platform. Industry benchmarks for media and entertainment typically run 60–70% mobile. Low mobile share indicates that mobile UX friction, performance issues, or intrusive ad layouts are suppressing mobile engagement. The users are coming — Google Search sends mobile traffic — but they're bouncing at a higher rate. This quantifies what the design review and performance audit described qualitatively.

Analytics also validates hypotheses from other layers. If heuristic review identifies a weak article-to-article navigation system, you expect to see low pages-per-session. If the audit identifies no clear subscription upsell moment, you expect to see low subscription conversion from organic traffic. Analytics either confirms or challenges what the other layers suggest.

## What a Good Audit Output Looks Like

A good audit output has three properties:

**It's layered by urgency, not by screen.** A 47-page deck organized by page type is hard to act on. A roadmap organized by priority — what to fix in the next two weeks, what to plan for Q2, what to monitor over time — tells the team what to do on Monday.

**It names the business impact, not just the design problem.** "The comment form input fields are cramped" is a design observation. "The cramped comment form creates friction at the point of highest engagement intent — users who have read a full article and want to respond — reducing community participation and repeat visit motivation" is a finding with business context.

**It documents what's working.** A good audit is not a hit list. It identifies what to preserve, what to protect in the redesign, and what competitive advantages the product already has. In the media platform audit, clean reading experience and no intrusive ad formats were genuine positives worth explicitly noting — because they're easy to accidentally eliminate in a redesign focused on "improving" the experience.

## What to Do with the Findings

The most common audit failure mode isn't a bad audit. It's a good audit that sits in a Google Drive folder and influences nothing.

Findings need an owner and a deadline before they leave the audit presentation. The prioritization framework is simple: fix high-urgency issues that have low implementation cost first — these are quick wins that build momentum and trust. Then sequence medium-urgency improvements into the next design sprint. Treat low-urgency items and suggestions as a backlog to revisit quarterly.

For structural problems (IA redesign, performance overhaul, SEO clean-up), create a parallel workstream with its own timeline and resourcing. These don't compete with feature work — they enable it. A platform with 47/100 mobile performance can't safely add features without making the problem worse.

The audit output should end with a clear statement of expected impact: what changes when these recommendations are implemented, expressed in terms the business cares about. More pages per session. Higher ad viewability. Stronger Core Web Vitals scores. Lower bounce rate on mobile. Subscription conversion from organic traffic. These aren't guarantees — they're the logical outcomes of solving the specific problems the audit identified.

If your product has traffic but not the outcomes you expect — users who arrive but don't convert, subscribe, or come back — a UX audit is the fastest way to find out why.

We run audits across design, IA, performance, and SEO, and deliver a prioritized roadmap your team can act on the week it lands.

[Talk to us about a UX audit →](/services/ux-audit)

Related: [The Complete Guide to SaaS Onboarding UX](/blog/saas-onboarding-ux-guide) · [The Hims Effect: Why Healthtech Built a Clone Factory](/blog/hims-effect-healthtech-design-monoculture)

---

### The Hims Effect: Why Healthtech Built a Clone Factory (And What It's Costing You)
URL: https://www.themasterly.com/blog/hims-effect-healthtech-design-monoculture
Product · 2026-04-15

## Open Five Tabs. See One Website.

Here's a test. Open these URLs simultaneously:

-   [hims.com](https://www.hims.com/)
-   [felixforyou.ca](https://www.felixforyou.ca/)
-   [gobioverse.com](https://www.gobioverse.com/)
-   [ro.co](https://ro.co/)
-   [tryeden.com](https://www.tryeden.com/)

Give yourself 10 seconds per site, then close all tabs. Now try to describe which was which.

You probably can't. Not because your memory is bad — because the sites look nearly identical.

Same hero: a confident lifestyle photo of someone who clearly uses the product. Same layout: two or three large feature cards on top, a row of smaller category tiles below. Same copy tone: short, declarative, benefit-led. Same product treatment: the pill or vial isolated against a soft colored background like it's a luxury object. Same CTA: "Get started" or "Start now," rounded pill button, sitting quietly at the bottom of the hero.

This isn't coincidence. This is what happens when every founder in a vertical says the same four words to their designer:

> **"Make it like Hims."**

## How the Clone Factory Works

The process is almost ritualistic at this point.

A healthtech founder — let's call him Adam — has a telemedicine platform. Six verticals: weight loss, hair loss, skincare, labs, mental health, sexual health. He's spent money on a designer. The designer delivered something. Adam hates it. He opens his laptop in a discovery call and shares his screen. He navigates to hims.com.

"I want something like this," he says. "Clean. Minimal. You know — like Hims."

The designer nods, opens Figma, and starts reproducing: the warm amber, the serif-meets-sans-serif pairing, the product cards with the slightly rounded corners. They're not thinking about Adam's business. They're copying a reference.

Adam gets a deliverable that looks like a slightly worse version of Hims. He's not happy but he can't articulate why. The designer defends the work. They part ways. The cycle repeats.

This is happening at scale. Walk through any healthtech pitch deck and you'll find a "design inspiration" slide that leads directly back to Hims. Hims has become the design specification for an entire industry.

## What Hims Actually Did

Let's be precise about what made Hims' design work — because this is where every copy gets it wrong.

Hims didn't design a pretty website and then build a business around it. They built a brand narrative first, and the design was the output of that narrative.

![Hims.com — above the fold.](/images/blog/hims-effect-healthtech-design-monoculture/body-1.png)

The Hims narrative is: _men's health is normal, not shameful, and you can handle it yourself, on your terms, discreetly._ Everything in the UI expresses that narrative. The warm tones say "approachable, not clinical." The lifestyle photography says "this is your life, not a medical condition." The minimal copy says "we respect your intelligence, we're not going to over-explain." The hidden-in-plain-sight CTA says "no pressure, you come to us."

Every pixel is in service of a positioning decision.

Now here's the part that matters: Hims also spends somewhere between $15 million and $60 million per month on paid advertising. That number is not a typo. By the time a user lands on hims.com, they've already seen the brand dozens of times across Instagram, YouTube, and connected TV. They know what Hims is. The website doesn't need to explain the company — it just needs to close.

That's why the copy is minimal. That's why the CTAs are quiet. That's why there's almost no educational content above the fold. Hims doesn't need to sell itself to a cold audience because it almost never has a cold audience.

But scroll past the fold and the homepage shifts visual modes entirely — per category, per product, per emotional context.

![hims.com — Weight loss section.](/images/blog/hims-effect-healthtech-design-monoculture/body-2.png)

![Hims.com — GLP-1 section.](/images/blog/hims-effect-healthtech-design-monoculture/body-3.png)

![Hims.com — Testosterone section.](/images/blog/hims-effect-healthtech-design-monoculture/body-4.png)

![Hims.com — Labs section. Same homepage, four different visual environments.](/images/blog/hims-effect-healthtech-design-monoculture/body-5.png)

![hims.com — Labs section.](/images/blog/hims-effect-healthtech-design-monoculture/body-6.png)

![hims.com - footer section](/images/blog/hims-effect-healthtech-design-monoculture/body-7.png)

Same homepage. Five different visual environments. This is a [design system](/glossary/design-system) built from a brand strategy — not a template. The competitors copy the first screen and call it done.

When you copy the Hims UI without the Hims advertising engine, you copy the endpoint of a funnel and attach it to the beginning of a journey. It doesn't convert. It confuses.

## Brand by Brand: What They Copied and What They Missed

### Felix (felixforyou.ca)

![felixforyou.ca — homepage.](/images/blog/hims-effect-healthtech-design-monoculture/body-8.png)

![felixforyou.ca — Longevity.](/images/blog/hims-effect-healthtech-design-monoculture/body-9.png)

![felixforyou.ca — Weight Loss.](/images/blog/hims-effect-healthtech-design-monoculture/body-10.png)

![felixforyou.ca — navigation.](/images/blog/hims-effect-healthtech-design-monoculture/body-11.png)

**What they copied:** The clean white background, the product category grid, the restrained navigation, the mix of lifestyle photography and isolated product shots.

**What they missed:** Felix is a Canadian brand serving a market with different insurance dynamics, different cultural norms around discussing health, and a French-language requirement for parts of their audience. Their UI says "premium American DTC brand." Their audience is a 38-year-old in Toronto navigating provincial healthcare. The visual language creates a subtle mismatch that erodes trust at exactly the moment they need it most — at the decision point.

**The cost:** The "FREE VISIT" badge slapped onto cards feels like a discount sticker on a luxury product. It's the brand fighting itself. That tension wouldn't exist if the design started from Felix's actual positioning, not Hims'.

### Bioverse (gobioverse.com)

![gobioverse.com — homepage.](/images/blog/hims-effect-healthtech-design-monoculture/body-12.png)

![gobioverse.com — NAD+.](/images/blog/hims-effect-healthtech-design-monoculture/body-13.png)

![gobioverse.com — Weight Loss.](/images/blog/hims-effect-healthtech-design-monoculture/body-14.png)

![gobioverse.com — Longevity.](/images/blog/hims-effect-healthtech-design-monoculture/body-15.png)

**What they copied:** The warm yellow-cream palette is so close to Hims' amber that you'd need a color picker to tell them apart. Full-bleed lifestyle hero, same button style, same structural hierarchy.

**What they missed:** Bioverse's positioning is around longevity and optimization — peptides, NAD+, compounds that require more education than "lose weight your way." Their target user needs to understand what they're taking and why. The Hims template — with its minimal copy and assumption of brand awareness — leaves Bioverse's core value proposition invisible above the fold.

**The cost:** A user landing on Bioverse cold has no idea they're in the longevity/biohacking space until they scroll. The hero could belong to any wellness brand. That's a critical failure for a product category that lives or dies by differentiation.

### Ro (ro.co)

![ro.co — homepage.](/images/blog/hims-effect-healthtech-design-monoculture/body-16.png)

![ro.co — GLP-1 products.](/images/blog/hims-effect-healthtech-design-monoculture/body-17.png)

![ro.co — sexual health.](/images/blog/hims-effect-healthtech-design-monoculture/body-18.png)

![ro.co — treatments.](/images/blog/hims-effect-healthtech-design-monoculture/body-19.png)

![ro.co — features.](/images/blog/hims-effect-healthtech-design-monoculture/body-20.png)

**What they copied:** The two-column hero card layout, the product-as-luxury-object photography (the Ozempic pill shot is pure Hims energy), the muted blue-grey system as their departure from Hims' warmth.

**What they missed:** Ro has a more clinical, insurance-adjacent positioning than Hims. They mention FDA approval, real providers, and insurance integration in their trust bar. But their hero visual language says "cool DTC brand," not "medically credible platform." There's a contradiction between the copy (building trust through clinical legitimacy) and the design (borrowing cool from a competitor known for making healthcare feel casual).

**The cost:** Ro is trying to win a trust game with a design vocabulary borrowed from a brand that deliberately de-medicalized its aesthetic. The user who wants FDA credibility and the user who wants the Hims vibe are often different people.

### Eden (tryeden.com)

![tryeden.com — homepage.](/images/blog/hims-effect-healthtech-design-monoculture/body-21.png)

![tryeden.com — GLP-1.](/images/blog/hims-effect-healthtech-design-monoculture/body-22.png)

![tryeden.com — NAD+.](/images/blog/hims-effect-healthtech-design-monoculture/body-23.png)

![tryeden.com — products.](/images/blog/hims-effect-healthtech-design-monoculture/body-24.png)

![tryeden.com — features.](/images/blog/hims-effect-healthtech-design-monoculture/body-25.png)

**What they copied:** The three-column colored card grid is functionally identical to Hims' category tiles. Colored backgrounds per category, product photography centered in the card, the same typographic hierarchy inside each tile.

**What they missed:** Eden's product is more complex — GLP-1 compounds, hormone therapy, NAD+ injections. These require trust, education, and a clear explanation of how the process works. The visual system borrowed from Hims doesn't give the brand enough room to communicate clinical credibility. The category cards look like a menu at a nice restaurant. Some of these products are injectable compounds that require a doctor's approval.

**The cost:** The aesthetic creates a perceived simplicity that may actually increase user anxiety for higher-stakes treatments. "This looks too easy" is a real friction point in healthcare UX.

## The Pattern Across All Five

Every brand made the same error: they treated Hims' UI as a genre, the way someone might look at a hip restaurant and say "give me that vibe." But Hims' UI is not a genre. It's the visual expression of a specific business model, a specific audience maturity, a specific advertising strategy, and a specific brand narrative.

When you strip the UI from its context and paste it onto a different context, you get a brand that looks like it knows who it is — but doesn't.

## The Real Problem: You're Competing With Your Inspiration

There's a deeper strategic issue that nobody talks about.

When five brands in the same vertical adopt the same visual language, they force users into comparison shopping mode. If Ro, Eden, Bioverse, and Felix all look like Hims, the user subconsciously asks: "Which one is the real thing?" The answer, almost always, is Hims.

You have spent money on design to make users think about your competitor.

Differentiation is not just a branding exercise — it's a conversion lever. A user who can immediately feel that a brand is built for them, in their context, for their problem, converts at a higher rate than a user who's comparing interchangeable options. The healthtech brands that have successfully broken from the Hims template — Function Health, for example, with its data-driven, almost dashboard-like aesthetic — have done so by starting from a genuinely different positioning, not just choosing a different accent color.

The question is never "what does the best brand in my space look like?" It's "what does my specific user need to feel in the first five seconds to trust me enough to answer a medical questionnaire?"

## Why Founders Keep Doing This

It would be easy to blame designers here. But the clone factory starts with the client brief.

**1\. Cognitive shortcut under pressure.**  
Building a healthtech company is hard. Regulatory compliance, physician networks, pharmacy logistics, acquisition costs. The website can feel like the easiest problem to solve. "Just make it look like the market leader" feels like a low-risk decision. It's not — it's a high-risk decision that looks safe.

**2\. The reference communicates quality, not direction.**  
When a founder says "I want something like Hims," they usually mean: "I want something that feels premium, trustworthy, and clean." Those are legitimate design requirements. But Hims is the example, not the brief. A good designer needs to extract the requirement and build a solution that expresses those qualities through the lens of the actual brand.

**3\. Design and strategy are disconnected.**  
Most healthtech startups haven't done a proper brand strategy before they commission a website. Without a clear positioning document, the Hims reference becomes the de facto strategy. The design ends up expressing Hims' positioning, not the brand's.

## What Actually Differentiates in Healthtech UI

**They design from the user's emotional state, not the competitor's aesthetic.**  
A user coming to a mental health platform is in a different headspace than someone looking for hair loss treatment. The UI should feel different because the emotional context is different.

**They use visual language to establish clinical credibility where it matters.**  
Clean doesn't mean medical. A platform that requires a physician to approve your prescription should not look identical to a platform that ships supplements.

### They treat the hero as education, not decoration
Hims can run a hero with six words because its users already know what Hims is. A brand without $15M/month in ads needs its hero to establish what the platform does, who it's for, and why it's trustworthy — in that order, without a wall of text.

**They build a visual system around their verticals, not borrowed from someone else's.**  
The visual differentiation between a weight loss product and a mental health product should come from the brand's own design language, not from color-coding inside a template.

## The Brief That Would Actually Work

Before you open Figma, answer four questions:

1.  **Who is your user and what are they feeling when they land on your site?**  
    Fear? Hope? Embarrassment? Relief? The design needs to meet them there.  
    
2.  **What is the one thing you need a new user to believe in the first five seconds?**  
    "This is safe." "This is for people like me." "This is actually different." Design for that belief.  
    
3.  **What is your actual competitive advantage?**  
    If it's clinical rigor, your UI should feel more rigorous than Hims. If it's cultural fit, your UI should visually signal that from the first frame.  
    
4.  **What does your funnel look like, and what does the user know before they arrive?**  
    If you're running cold-traffic ads, your hero needs to work harder than Hims'.  
    

The answers to these questions are your design brief. Hims is an inspiration, not an answer.

## Key Findings

**1.** Hims' UI works because of what happens _before_ users see it — $15–60M/month in ads creates brand familiarity that makes minimal design functional. Without that funnel, minimal design is just underexplaining.

**2.** Copying a competitor's UI is copying the output of their strategy, not the strategy itself. Different products, different markets, different user psychology — none of which are expressed in the clones' designs.

**3.** Visual monoculture in a vertical actively benefits the market leader. When multiple brands look like Hims, users default to Hims. The clones are doing brand awareness work for their competitor.

**4.** The clone pattern starts with the client brief, not the designer. "Make it like Hims" is not a brief. It's a cognitive shortcut that skips the hard work of positioning.

**5.** Differentiation in healthtech UI is not about aesthetic novelty — it's about visual language that accurately reflects your clinical positioning, your user's emotional state, and your trust-building strategy.

## Common Mistakes

### **Mistake 1: Using the same reference as your direct competitors.**

Felix and Ro both showed their designers Hims. They now look like each other and like Hims. Neither wins.

### **Mistake 2: Copying the minimalism without earning it.**

Hims earned the right to use six words in its hero. You haven't. Your hero needs to do real conversion work.

### **Mistake 3: Treating "clean" as a visual style rather than a UX property.**

Clean is not a color palette. Clean means: low cognitive load, obvious next action, nothing fighting for attention. You can achieve clean without looking like Hims.

### **Mistake 4: Ignoring cultural and market context.**

The Hims aesthetic was built for the American men's wellness market. A platform for Saudi Arabia, Canada, or a mental health vertical has different trust signals and different user expectations. Transplanting it creates a mismatch users feel even if they can't articulate it.

### **Mistake 5: Commissioning design before completing brand strategy.**

"I want something like Hims, but for \[my product\]" guarantees a clone. "My user is X, they feel Y when they arrive, and they need to believe Z before they fill out our intake form" produces a real design.

| Brand | What They Copied | What They Missed | The Cost |
| --- | --- | --- | --- |
| Felix | White bg, product grid, photography style | Canadian market, provincial healthcare, bilingual audience | "FREE VISIT" badge on luxury aesthetic = brand contradiction |
| Bioverse | Warm amber palette, lifestyle hero, minimal copy | Longevity/biohacking needs education, not brand assumption | Value proposition invisible above the fold |
| Ro | 2-column card layout, product-as-luxury photography | Clinical/insurance positioning vs. casual DTC visual language | FDA copy + Hims aesthetics = cognitive dissonance |
| Eden | 3-column colored card grid, product tile hierarchy | Injectable compounds need credibility signals, not menu UX | "This looks too easy" friction for high-stakes treatments |

Analysis based on visual audit of Hims, Felix, Bioverse, Ro, and Eden conducted March 2026. All brands were reviewed on their primary homepage at the time of analysis.

---

### Progression Systems That Build Daily Habits (Not Just Gamification)
URL: https://www.themasterly.com/blog/progression-systems-that-build-daily-habits
Product · 2026-04-15

## The Problem With Copying Duolingo's Progression System

Here's what usually happens: a founder sees Duolingo's success and thinks "we need XP, levels, and streaks."

A few sprints later, the app has:

-   Points for completing actions
-   Levels that unlock at certain thresholds
-   Streak counters showing consecutive days
-   Badges for milestones

But users don't engage. Streaks break and people don't come back. The progression system feels bolted on, not integral.

**The issue isn't that progression systems don't work—it's that Duolingo's specific pattern doesn't fit every product.**

Duolingo's multi-layered gamification works because language learning is about measurable skill gain. More XP genuinely means more fluency. Streaks create beneficial pressure because daily practice improves [retention](/glossary/retention).

But for meditation apps? Self-care products? Habit trackers focused on emotional well-being?

Aggressive progression creates anxiety. Users feel pressure to "perform" instead of just showing up. Breaking a streak feels like failure, which is the opposite of what self-care should feel like.

Great progression systems make users feel forward movement without creating the wrong kind of pressure. The best systems answer: "Am I making progress?" in a way that fits what the product actually helps users achieve.

We analyzed five mobile apps with different approaches to progression. Each serves a different user motivation. Each makes different trade-offs. None is universally "best" - but understanding why each pattern works helps you choose the right one for your product.

## Pattern #1: Duolingo — Multi-Layered Gamification

![Duolingo app progression system interface displaying experience points, 47-day streak counter, level 12 indicator, and active daily quest panel with multiple gamification layers](/images/blog/progression-systems-that-build-daily-habits/body-1.png)

**What it is:** XP + streaks + levels + quests + badges all working together

### How It Works

Duolingo doesn't rely on one progression mechanic—it layers several:

**XP (Experience Points):** Earned after every lesson, immediate feedback that effort counted  
**Streaks:** Consecutive days tracked prominently, shown in multiple places  
**Levels:** Threshold-based progression (Level 5 → Level 6), creates long-term goals  
**Daily Quests:** Short-term objectives that reset daily, gives reason to return  
**Badges/Achievements:** Milestone celebrations for specific accomplishments  
**Leaderboards:** Social comparison (optional but present)

### Key characteristics:

-   Clear wins after every action (you always know when you completed something)
-   Streaks visible and motivating (day counts shown clearly and often)
-   Frequent positive feedback (celebrations, sounds, animations)
-   Goals broken into small steps (never feels overwhelming)
-   Visual character builds emotional connection (mascot reacts to progress)
-   Multiple progress signals reinforce forward movement

### Why This Progression System Works

### Instant closure after every session
You finish a lesson, see XP gained, level bar fills slightly, streak extends by one day. Every action has visible consequences. There's no ambiguity about whether you made progress.

### Short-term and long-term goals layered together
Daily quests give you something to achieve today. Levels give you something to work toward this week. Streaks give you something to maintain this month. The layering keeps engagement high across different timeframes.

### Competitive framing matches the product
Language learning benefits from "doing more" and "getting better." XP naturally maps to actual skill gain. More lessons = more vocabulary. Higher levels = real fluency improvement.

### Small celebrations keep it rewarding
Every level-up triggers animation. Every streak milestone (7 days, 30 days) gets acknowledged. Frequent wins prevent the grind from feeling tedious.

### When To Use This Progression Pattern

✅ **Use multi-layered gamification when:**

-   Your product teaches a measurable skill (language, coding, music)
-   "More practice" genuinely equals "better performance"
-   Users are motivated by achievement and visible improvement
-   Competitive framing feels appropriate (not self-care or wellness)
-   You can commit to creating new quests, badges, and content regularly

❌ **Don't use when:**

-   Your product is about relaxation, calm, or emotional well-being
-   "More" doesn't equal "better" (meditation quality > meditation quantity)
-   Streaks would create anxiety instead of motivation
-   Users come to escape pressure, not chase achievements

### Trade-offs

### What you gain:
High engagement (multiple hooks to return), clear sense of improvement, natural upsell opportunities (streak freezes, XP boosts), strong habit formation

### What you sacrifice:
Risk of burnout (too much pressure), complexity (need to balance all systems), ongoing content creation (quests/challenges require updates), not appropriate for calm/wellness contexts

## Pattern #2: Headspace — Minimal Time Tracking

![Headspace meditation app progress screen displaying 15 minutes practiced today, 8-day streak counter, and minimal UI design for calm tracking](/images/blog/progression-systems-that-build-daily-habits/body-2.png)

**What it is:** Minutes practiced + streak count, nothing else

### How It Works

Headspace tracks exactly two things:

-   **Minutes practiced today** (and this week, this month)
-   **Streak** (consecutive days, shown but not emphasized heavily)

That's it. No XP. No levels. No badges. No quests.

### Key characteristics:

-   Clear daily feedback (users immediately see today's minutes and streak)
-   Personal progress view (users can see patterns over time, not just single sessions)
-   Consistency over performance (showing minutes reinforces "showing up" rather than "doing more")
-   Calm visual design (progress indicators feel supportive, not flashy)

### Why This Progression System Works

### Simplicity matches the product purpose
Headspace is about meditation and mental calm. Adding levels, XP, and competitive elements would conflict with that. The progression system stays minimal so it doesn't distract from the core experience.

### Time tracking validates effort without pressure
Seeing "15 minutes today" confirms your practice mattered, even if it was short. There's no judgment about whether 15 minutes is "good enough"—it just is.

### Streaks encourage consistency without punishment
The streak is visible, but breaking it doesn't trigger loss messaging or dramatic consequences. It's a gentle nudge to return, not a source of anxiety.

### Progress over time, not per session
Users can view total minutes this week or month, which shows patterns without making any single session feel critical. Missing one day doesn't erase your overall progress.

### When To Use This Progression Pattern

✅ **Use minimal time tracking when:**

-   Your core value is simplicity or calm
-   "Showing up" matters more than "doing more"
-   Users value low-pressure environments
-   Your product helps with focus, meditation, or emotional regulation
-   Complexity would distract from the experience

❌ **Don't use when:**

-   Users want visible achievement and milestones
-   Your product benefits from competitive motivation
-   You need multiple engagement hooks to drive retention
-   Users expect gamification (e.g., learning apps, fitness apps)

### Trade-offs

### What you gain:
Stays true to product purpose (calm, focus), reduces cognitive load, no risk of progression system overshadowing core value, users appreciate restraint

### What you sacrifice:
Fewer engagement touchpoints, limited monetization hooks (can't sell XP boosts or level unlocks), not for users who want visible achievement, less viral/shareable moments.

## Pattern #3: Insight Timer — Calendar + Stats (Judgment-Free)

![Insight Timer meditation app calendar interface with practice days marked, weekly time statistics, and neutral visualization design for pattern recognition](/images/blog/progression-systems-that-build-daily-habits/body-6.png)

**What it is:** Time-based tracking + calendar view + neutral charts

### How It Works

Insight Timer focuses on pattern recognition without comparison:

**Calendar view:** Shows which days you practiced (visual consistency tracking)  
**Time stats:** Minutes practiced this week, this month, this year  
**Streak display:** Consecutive days shown, but not heavily emphasized  
**Charts:** Neutral visualizations of practice frequency over time

### Key characteristics:

-   Clear streak visibility (users see consecutive days immediately)
-   Time-based progress (minutes feel real, even for short sessions)
-   Visual history (calendar helps users notice consistency)
-   Consistency framing ("small moments add up," not "do more or better")
-   Stats without judgment (neutral charts, no comparison, no failure language)
-   Visual calm (minimal, quiet screens match mental health context)

### Why This Progression System Works

### Calendar makes patterns visible
Seeing your practice days on a calendar creates awareness. You notice "I practiced 4 out of 7 days this week" without the app telling you whether that's good or bad. The insight is yours.

### Time tracking without performance pressure
Minutes practiced ≠ "minutes improved" or "minutes perfected." It's just a count. Ten minutes is ten minutes. This removes the anxiety about whether your practice was "good enough."

### Neutral framing reduces shame
There's no "you failed" or "you're behind." If you miss days, the calendar just shows blank spaces. The app doesn't punish you—it just reflects reality.

### Long-term view encourages patience
You can see months of practice history. This reinforces that meditation is a long journey, not a daily performance test.

### When To Use This Progression Pattern

✅ **Use calendar + stats when:**

-   Users benefit from seeing patterns over time
-   Self-awareness is part of the value proposition
-   You want to avoid comparison or competition
-   Your product focuses on mental health, wellness, or personal growth
-   Neutrality supports the experience (no pressure, no judgment)

❌ **Don't use when:**

-   Users want clear milestones and celebrations
-   Calendar tracking feels like "homework"
-   Your product needs more active engagement hooks
-   Immediate feedback matters more than long-term patterns

### Trade-offs

### What you gain:
Pattern recognition without pressure, judgment-free tracking, supports self-awareness, long-term orientation, fits mental health context perfectly

### What you sacrifice:
Less exciting (no celebrations or milestone moments), fewer viral moments (nothing to screenshot and share), not for users motivated by achievement, requires user to interpret their own data

## Pattern #4: Finch — Character-Driven Milestones

![Finch self-care app milestone celebration screen with bird companion character evolution animation, Day 7 achievement badge, and supportive message display](/images/blog/progression-systems-that-build-daily-habits/body-4.png)

**What it is:** Days tracked + character evolution + milestone celebrations

### How It Works

Finch ties progression to your relationship with a virtual bird companion:

**Daily presence tracking:** Consecutive days you showed up  
**Milestone moments:** Special screens at Day 3, Day 7, Day 14, Day 30, etc.  
**Character evolution:** The bird grows and unlocks new interactions over time  
**Visual environment changes:** Your bird's home evolves as you continue practicing  
**Multiple progress signals:** Day count + visual changes + unlocked items + supportive messages

### Key characteristics:

-   Daily progress visible (you see you did something today, even small steps)
-   Streaks feel encouraging (missing a day doesn't reset everything harshly)
-   Milestones feel emotional (about self-care, not winning or being better)
-   Character grows with you (actions help the character evolve)
-   Big moments celebrated (level-ups and streaks get animations and full-screen moments)
-   Progress shows up everywhere (day count, visuals, unlocks, messages)

### Why This Progression System Works

### Care framing changes how progress feels
You're not "earning XP" - you're "helping your bird grow." The emotional frame shifts from achievement to nurturing. Progress feels meaningful because it's about the relationship, not the numbers.

### Milestones create memorable moments
At Day 7, a full-screen animation appears. Your bird does something special. You unlock a new interaction. These moments punctuate the experience, making certain days feel important without creating daily pressure.

### Character evolution makes progress visible
As days accumulate, your bird changes. New expressions unlock. The environment becomes more detailed. Progress isn't just a number - it's something you can see and feel.

### Multiple signals prevent boredom
You're not just watching a streak number go up. You're seeing visual changes, unlocking items, getting messages from your bird. The variety keeps it fresh.

### When To Use This Progression Pattern

✅ **Use character-driven milestones when:**

-   Your product has a companion, character, or avatar mechanic
-   Emotional connection supports your core value (self-care, habit-building)
-   Users benefit from nurturing responsibility (not competitive achievement)
-   Milestones can be celebrated meaningfully (not just arbitrary numbers)
-   Your audience responds to care framing over achievement framing

❌ **Don't use when:**

-   No character or companion exists in your product
-   Users expect utilitarian, professional experiences (B2B tools)
-   Achievement motivation is more appropriate than care motivation
-   You can't commit to creating milestone content (animations, messages, unlocks)

### Trade-offs

### What you gain:
Emotional connection (progress feels personally meaningful), multiple engagement layers, memorable milestone moments, sustainable long-term (doesn't require escalating complexity), fits self-care context naturally

### What you sacrifice:
Requires character to exist in product, not for achievement-oriented users, milestone content requires design/dev work, less competitive appeal

## Pattern #5: Forest — Visual Consequence System

![Forest productivity app interface displaying healthy growing tree from completed focus session alongside withered gray tree from interrupted session showing visual consequence system](/images/blog/progression-systems-that-build-daily-habits/body-5.png)

**What it is:** Each session grows a tree, early exit kills the tree

### How It Works

Forest uses visual consequences to drive accountability:

### Start a session → A tree begins growing
### Stay focused → Tree grows to completion
### Leave early → Tree dies (withered, gray)
### Accumulated forest → All completed sessions visible together

### Key characteristics:

-   Clear cause → effect (you focus → tree grows, immediate and understandable)
-   One visible goal per session (each session grows one thing - simple, achievable)
-   Progress tied to time spent, not speed (staying present matters more than rushing)
-   Visual growth over numbers (seeing a plant grow feels more meaningful than earning points)
-   Accumulated world state (every session adds to the same forest - long-term, personal)
-   Failure has consequence but not punishment (leaving early = tree doesn't grow, no shame)

### Why This Progression System Works

### Consequence creates commitment
Knowing that leaving the app will kill your tree creates just enough accountability to keep you focused. It's not a harsh punishment - it's a visual consequence that mirrors your behavior.

### Visual feedback is immediate and clear
You don't need to interpret stats or check a dashboard. You can see your tree growing. You can see your forest expanding. The feedback is direct and satisfying.

### Cumulative world-building creates ownership
Over time, your forest becomes a visual representation of all the work you've done. It's yours. You built it. This creates attachment and makes you less likely to abandon the app.

### No performance pressure
A 10-minute session and a 60-minute session both grow a tree. There's no judgment about whether your session was "long enough" or "productive enough." You just get a tree.

### When To Use This Progression Pattern

✅ **Use visual consequence systems when:**

-   Your product is about focus, productivity, or time management
-   Accountability drives behavior (users want external motivation)
-   Visual feedback reinforces the action (seeing results matters)
-   Consequences feel appropriate (not self-care or emotional support)
-   Cumulative world-building fits your product (users benefit from seeing accumulated effort)

❌ **Don't use when:**

-   Your product is about relaxation or emotional well-being (consequences create stress)
-   Failure consequences would feel punishing (meditation, therapy, self-care apps)
-   Users need flexibility to stop without "penalty"
-   Visual feedback would distract from the core experience

### Trade-offs

### What you gain:
Strong accountability (consequence creates commitment), immediate visual feedback, cumulative world reflects effort, simple to understand, works well for productivity contexts

### What you sacrifice:
Consequences can create anxiety (not appropriate for wellness), less flexibility (users may feel trapped), guilt if trees die (negative emotion), requires visual design investment

| Pattern | Primary Metric | Emotional Tone | Complexity | Best For | Example Apps |
| --- | --- | --- | --- | --- | --- |
| Multi-Layered Gamification | XP + Streaks + Levels + Quests | Playful, competitive | High (many systems) | Skill-building products | Duolingo, Codecademy |
| Minimal Time Tracking | Minutes + Streaks | Calm, neutral | Low (minimal UI) | Focus/meditation products | Headspace, Calm |
| Calendar + Stats | Minutes + Calendar View | Calm, reflective | Medium (stats + visual history) | Pattern recognition products | Insight Timer, Reflectly |
| Character-Driven Milestones | Days + Character Evolution | Warm, caring | Medium (character + environment) | Emotional support products | Finch, Replika |
| Visual Consequence System | Trees Grown + Time | Focused, accountable | Low (simple feedback) | Productivity/focus products | Forest, Flora |

## The Progression System Decision Framework

Choosing the right progression pattern depends on what actually motivates your users and what your product helps them achieve.

### Step 1: What Is Your Core Value?

**Ask:** What does your product help users do?

-   **Build measurable skills** (language, coding, music) → Multi-Layered Gamification
-   **Focus or meditate** (calm, presence) → Minimal Time Tracking
-   **Recognize patterns** (mood, habits, reflection) → Calendar + Stats
-   **Support emotional well-being** (self-care, mental health) → Character-Driven Milestones
-   **Stay productive** (time management, deep work) → Visual Consequence System

### Step 2: What Motivates Your Users?

**Ask:** Why do users return?

-   **Achievement** (I want to level up, improve, win) → Multi-Layered Gamification
-   **Self-care** (I want to feel calmer, more present) → Minimal Time Tracking or Calendar + Stats
-   **Emotional connection** (I want to nurture something) → Character-Driven Milestones
-   **Accountability** (I need external motivation to stay focused) → Visual Consequence System

### Step 3: What Emotional Tone Fits Your Product?

**Ask:** How should users feel about their progress?

-   **Excited, challenged** → Multi-Layered Gamification
-   **Calm, supported** → Minimal Time Tracking
-   **Aware, reflective** → Calendar + Stats
-   **Cared for, connected** → Character-Driven Milestones
-   **Accountable, committed** → Visual Consequence System

### Step 4: Check System-Product Alignment

### Ask these questions:

-   Does this progression system reinforce what my product actually helps users achieve?
-   Will tracking this metric make users feel good or anxious?
-   Does the emotional tone match my product's purpose?
-   Can I sustain this system long-term (content, features, updates)?

If any answer is "no," reconsider the pattern.

## Common Mistakes With Progression Systems

### ❌ Mistake #1: Copying Duolingo Into Wellness Apps

### Why it fails:
Duolingo's multi-layered gamification works because language learning benefits from competitive pressure and measurable improvement. But meditation apps? Self-care products? Adding XP, levels, and aggressive streaks creates anxiety - the opposite of what users need.

### Example of the problem:
A meditation app adds daily XP and levels. Users start meditating to "hit their XP goal" instead of meditating because they need calm. When they miss a day and their streak breaks, they feel like they failed at self-care.

### Instead:
Use Minimal Time Tracking or Calendar + Stats. Show users their consistency without making them feel pressured to perform.

### ❌ Mistake #2: Too Many Progress Signals (Overwhelming Users)

### Why it fails:
XP + levels + streaks + badges + quests + leaderboards = cognitive overload. Users don't know what to focus on. Progress feels scattered instead of clear.

### Example of the problem:
A habit tracker shows: daily points, weekly points, total points, streak count, level, badges, and monthly challenges. Users feel confused about what actually matters.

### Instead:
Choose 1-2 primary metrics that clearly map to your core value. If you're a meditation app, show minutes and streaks - that's it. Everything else is noise.

### ❌ Mistake #3: Punishing Missed Days (Breaking Trust in Self-Care Apps)

### Why it fails:
Harsh streak resets or loss messaging makes users feel like they failed. In self-care contexts, this creates shame and guilt - emotions that push people away from the app.

### Example of the problem:
A journaling app resets your streak to zero if you miss one day. You had a 47-day streak. Now it's gone. You feel like you lost all your progress, even though you journaled 47 out of 48 days.

### Instead:

  
Use gentle streak systems. Show total days practiced (not just consecutive). Or use "streak freezes" that let users protect their streak during life events. Focus on overall consistency, not perfection.

### ❌ Mistake #4: No Milestone Celebrations (Progress Feels Invisible)

### Why it fails:
Users accumulate days, minutes, or XP, but nothing ever acknowledges their effort. Progress becomes invisible. There's no emotional payoff for showing up consistently.

### Example of the problem:
A habit tracker counts your streak: 7 days, 14 days, 30 days, 100 days. But nothing happens. No animation, no message, no unlock. It just keeps counting. Users don't feel celebrated.

### Instead:
Celebrate key milestones. Day 7, Day 30, Day 100—these should trigger something meaningful. An animation. A supportive message. An unlock. Something that says "This matters. You did it."

### ❌ Mistake #5: Abstract Metrics That Don't Map to Real Value

### Why it fails:
Users earn points or levels, but they don't understand how those metrics connect to actual improvement or benefit.

### Example of the problem:
A wellness app gives "wellness points" for completing actions. But users don't know what wellness points mean. Do 500 points mean I'm healthier? Is 1,000 better than 500? The metric feels arbitrary.

### Instead:
Use metrics that have real meaning. Minutes practiced. Days showed up. Skills learned. These are concrete and understandable. Users know what they mean without explanation.

## Key Findings From Our Analysis

After analyzing these five apps, clear patterns emerged:

**Finding #1: Wellness apps succeed by tracking consistency, not performance.**  
Headspace and Insight Timer track minutes and days - not "quality" or "improvement." This removes pressure and supports the mental health context.

**Finding #2: Streaks work, but tone matters (pressure vs. encouragement).**  
Duolingo uses streaks to create beneficial pressure ("Don't break your streak!"). Finch uses streaks to encourage ("You're doing great - keep it up!"). Same mechanic, completely different emotional impact.

**Finding #3: Visual progress (character, forest) beats abstract points for emotional products.**  
Finch's character evolution and Forest's tree growth create emotional connection. Points feel cold and transactional by comparison.

**Finding #4: Short-term + long-term goals create sustainable engagement.**  
Duolingo layers daily quests (short) with levels (medium) and streaks (long). This prevents engagement from dropping after one goal is achieved.

**Finding #5: Emotional framing (achievement vs. care vs. accountability) changes how the same mechanic feels.**

  
A streak counter can feel:

-   Competitive (Duolingo: "Beat your friends!")
-   Supportive (Finch: "You showed up for yourself")
-   Accountable (Forest: "Stay focused or the tree dies")

The mechanic is the same. The emotional context changes everything.

## Implementation Checklist

If you're adding or redesigning a progression system, use this checklist:

### Before You Build

-   Identify what your product helps users achieve (skill? calm? focus? emotional support?)
-   Identify what motivates your users (achievement? self-care? accountability?)
-   Choose progression pattern that matches both product value and user motivation
-   Define 1-2 primary metrics (don't overwhelm with too many)

### During Design

-   Design celebration moments for key milestones (Day 7, Day 30, etc.)
-   Choose emotional tone (competitive? supportive? neutral?)
-   Decide: streaks or total days? (or both?)
-   Plan what happens when users miss days (harsh reset or gentle acknowledgment?)

### Before Launch

-   Test: Does this system make users feel good or anxious?
-   Test: Can users explain what the metrics mean?
-   Verify: Does the system reinforce core value or distract from it?
-   Set success metrics (retention, session frequency, milestone completion)

### After Launch

-   Monitor: Which milestones get celebrated? Which feel ignored?
-   Track: Does progression usage correlate with retention?
-   Listen: Do users mention feeling pressured or supported?
-   Iterate: Adjust tone, frequency, or visibility based on feedback

## What We Learned

The best progression systems don't feel like achievement ladders. They feel like natural reflections of the value users are already getting from your product.

### Three principles emerged across all five patterns:

1.  **Match system to motivation** — Achievement-driven products use competitive progression. Self-care products use supportive progression. Productivity products use accountable progression. The system should amplify what already motivates users.
2.  **Consistency > performance for wellness** — Wellness apps succeed by celebrating "showing up" not "doing more." Minutes practiced > minutes improved. Days present > days perfect.
3.  **Emotional tone changes everything** — A streak counter can create pressure, support, or accountability depending on messaging. The mechanic matters less than the framing.

There's no universal "best" progression system. But there is a best system _for your product_—and it's the one that makes users feel good about the progress they're already making.

## Research Methodology

We analyzed five mobile apps over three weeks:

-   Downloaded and actively used each app (10+ sessions per app)
-   Documented progression flows in Figma (onboarding, daily use, milestones)
-   Identified emotional tone and user response to different mechanics
-   Tested how missing days, completing milestones, and long-term use felt

### Apps analyzed:

-   [Duolingo](https://www.duolingo.com/) (iOS/Android) — Language learning
-   [Headspace](https://www.headspace.com/) (iOS/Android) — Meditation and mindfulness
-   [Insight Timer](https://insighttimer.com/) (iOS/Android) — Meditation and sleep
-   [Finch](https://finchcare.com/) (iOS/Android) — Self-care companion app
-   [Forest](https://www.forestapp.cc/) (iOS/Android) — Focus and productivity

---

### 5 Reward Shop Patterns That Keep Users Coming Back
URL: https://www.themasterly.com/blog/5-reward-shop-patterns-that-keep-users-coming-back
Product · 2026-03-21

## The Problem With Most In-App Shops

Here's what usually happens: a product team decides they need "more engagement." Someone suggests adding a shop. A few sprints later, users can buy items with coins earned through gameplay.

The shop feels disconnected. Items seem random. Users accumulate currency but don't know what to spend it on. Purchases don't change how the app feels or works.

The issue isn't the shop itself - it's that the shop wasn't designed to serve the core loop.

Great reward shops aren't revenue features bolted on for monetization. They're [retention](/glossary/retention) mechanics that make users feel progress, build habits, and create commitment. The best shops answer a clear question: "Why does this exist, and how does it make my experience better?"

We analyzed five mobile apps with different approaches to reward shops. Each serves a different retention model. Each makes different trade-offs. None is universally "best" - but understanding why each pattern works helps you choose the right one for your product.

## Pattern #1: Pokemon Go - The Utility Shop

![Pokemon Go reward shop interface with pokeballs, incense, lucky eggs, and raid passes organized by utility and clear pricing](/images/blog/5-reward-shop-patterns-that-keep-users-coming-back/body-1.jpg)

What it is: Items amplify what users already do (walking, catching, exploring)

### How It Works

Pokemon Go's shop doesn't feel separate from the game - it's integrated into the world itself. You're not "shopping" in the traditional sense; you're acquiring tools that make your existing actions more effective.

### Key characteristics:

-   Every item has clear utility (extra inventory space, better catch rates, extended lure duration)
-   Items relate directly to core actions users already perform (walking, catching Pokemon)
-   Purchases feel like progress enablers, not shortcuts
-   Shop is accessible from multiple contexts (inventory screen, map view, during catching)

### Why This Reward Shop Pattern Works

### Clear purpose for every item
When you look at a Pokeball bundle, you know exactly what it does and why you might need it. You've already been catching Pokemon - you understand the value. Nothing feels random or decorative.

### Purchases relate to real actions
You don't buy abstract "boost packs." You buy incense (attracts Pokemon while walking), lucky eggs (doubles XP for 30 minutes), or raid passes (lets you participate in group battles). Each item maps to something you're already doing or want to do more of.

### The shop feels alive and engaging
Bright visuals, clear icons, and movement make browsing feel like part of the game world - not a boring list of items. The presentation matches the energy of the core experience.

### Long-term orientation
Items help you enjoy the game more over time, not win faster today. Bag upgrades, Pokemon storage, incubators - these purchases support long-term play, which increases switching costs.

### When To Use This Reward Shop Pattern

✅ Use utility shops when:

-   Your core loop involves repeated actions (steps, sessions, completions) that can be enhanced
-   Items create clear functional advantages without feeling like pay-to-win
-   Users understand the value before purchasing (they've experienced the problem the item solves)
-   The product has inherent progression (levels, achievements, collections)

❌ Don't use when:

-   Your product is consumption-based (reading, listening) where "more" doesn't equal better experience
-   Core loop is about relaxation or simplicity (adding tools creates unwanted complexity)
-   You can't clearly articulate what each item does and why users would want it

### Trade-offs

### What you gain:
High perceived value (items solve real problems), natural upsell opportunities (users hit limits organically), strong connection between shop and retention

### What you sacrifice:
Risk of pay-to-win perception if balance is wrong, complexity (need to design items that matter but don't break fairness), ongoing balance work as game evolves

## Pattern #2: Fortnite - The Experience Shop

![Fortnite item shop interface displaying featured character skins with daily rotation countdown and full character preview animations](/images/blog/5-reward-shop-patterns-that-keep-users-coming-back/body-2.jpg)

What it is: Pure cosmetics + daily rotation create anticipation without functional advantage

### How It Works

Fortnite's shop sells exactly zero functional items. Every purchase is cosmetic - character skins, emotes, gliders, pickaxes. You don't get better at the game. You don't progress faster. You just look different.

Yet the shop drives massive revenue and daily engagement. How?

Key characteristics:

-   Zero utility - everything is pure self-expression
-   Daily rotation creates FOMO and anticipation
-   Preview before purchase (see character in motion, test emotes)
-   Clear separation of sections (Daily, Featured, Upcoming)
-   Items are time-limited but may return (scarcity without permanent loss)

### Why This Reward Shop Pattern Works

Browsing feels like exploration, not shopping  
Users scroll, preview, and discover items almost like exploring content. The shop has personality and feels alive. Daily rotation means there's always a reason to check back.

Daily rotation creates anticipation  
"What's new today?" becomes part of the routine. Items change every 24 hours, so checking the shop is a low-friction daily habit. You're not shopping—you're discovering what appeared.

Preview eliminates purchase regret  
You can see your character wearing the skin, doing the emote, using the glider. The preview is generous. By the time you buy, you've already experienced it visually.

Social display value  
In a competitive multiplayer game, cosmetics signal status, taste, and dedication. Rare skins from old seasons become conversation starters. Self-expression has social currency.

### When To Use This Reward Shop Pattern

✅ Use experience shops when:

-   Your product has social or display components where identity expression matters
-   Users spend significant time in the interface where cosmetics are visible
-   You can create high-quality visual assets (skins, themes, customization)
-   Community exists where people share/discuss rare or exclusive items

❌ Don't use when:

-   Users are utility-focused and don't care about appearance or personalization
-   Product context is private (no one sees your choices)
-   Visual customization distracts from core value (meditation, focus apps)
-   You can't commit to regular content creation (rotation requires constant new items)

### Trade-offs

### What you gain:
No pay-to-win concerns (cosmetic-only), infinite design space (not constrained by game balance), community engagement (people collect and share rare items), daily check-in habit

### What you sacrifice:
Must create high-quality visual assets constantly, not all users value cosmetics, harder to justify purchases if people don't care about appearance, rotation pressure (need new content regularly)

## Pattern #3: Finch — The Care Shop

![Finch self-care app shop interface with bird character outfits, furniture items, and instant visual preview of items on companion](/images/blog/5-reward-shop-patterns-that-keep-users-coming-back/body-3.webp)

What it is: Items represent caring for your companion, not grinding rewards

### How It Works

Finch is a self-care app with a virtual bird companion. The shop sells items to customize your bird and its environment. But it doesn't feel transactional - it feels like caring for a pet.

Key characteristics:

-   Items are for your character, not for you (outfits, accessories, furniture)
-   Simple categories (Outfits, Furniture, Decorations, Garden)
-   Instant feedback - you immediately see the item on your bird or in its space
-   Purchases feel like gifts, not upgrades
-   Character connection - buying feels like nurturing

### Why This Reward Shop Pattern Works

Buying items feels like caring for your character  
You're not optimizing stats or gaining power. You're dressing your bird, decorating its home, giving it things to enjoy. The emotional frame is care, not transaction.

Simple categories reduce decision fatigue  
Outfits, furniture, garden items - easy to browse. The shop doesn't overwhelm with complexity. Finding things feels fast and familiar.

Instant feedback after purchase  
When you buy a scarf, your bird immediately wears it. You see the result right away. The feedback loop is tight and satisfying.

Character connection strengthens over time  
The more you customize your bird, the more it feels like _yours_. Customization isn't just aesthetics - it's emotional investment. You're less likely to abandon an app when you've built a relationship with its character.

No pressure to be perfect  
You can change items anytime. Move furniture freely. Try different outfits. It stays playful and low-stakes, which keeps it aligned with the self-care context.

### When To Use This Reward Shop Pattern

✅ Use care shops when:

-   Your product has a character or companion mechanic (virtual pet, avatar, guide)
-   The experience focuses on emotional well-being or personal growth
-   Users benefit from feeling nurturing responsibility (not competitive achievement)
-   Core loop is about showing up regularly, not performing perfectly

❌ Don't use when:

-   No character or companion exists in the product
-   Users expect direct functional benefits from purchases
-   Product positioning is utilitarian or professional (B2B tools, productivity)
-   You need variety and exploration (care shops work best staying minimal)

### Trade-offs

### What you gain:
Emotional connection (purchases feel meaningful), low cognitive load (simple choices), sustainable long-term (doesn't require escalating complexity), fits self-care context naturally

### What you sacrifice:
Less monetization surface area (fewer items to sell), not for achievement-oriented users, requires character to already exist in product, limited variety compared to other patterns

## Pattern #4: Duolingo - The Minimal Shop

![Duolingo minimal shop interface with streak freeze power-up, bonus hearts, and Duo owl mascot customization items](/images/blog/5-reward-shop-patterns-that-keep-users-coming-back/body-4.jpg)

What it is: Small power-ups that remove friction without changing core loop

### How It Works

Duolingo has a shop, but it's almost invisible. Most users barely interact with it. The items are small, functional, and focused: streak freezes, bonus XP boosts, and cosmetic outfits for the mascot.

Key characteristics:

-   Very few items (5-7 total, not hundreds)
-   Focus on removing friction (streak freeze prevents losing your count if you miss a day)
-   Small boosts, not game-changers (double XP for one lesson)
-   Mascot customization is pure fun, not core engagement
-   Shop is not the retention driver - progression is

### Why This Reward Shop Pattern Works

Shop supports retention without being the retention  
Duolingo's retention comes from streaks, levels, and learning progress. The shop exists to support that - not replace it. A streak freeze reduces anxiety about losing progress. That's the job.

Power-ups are small and non-intrusive  
Double XP doesn't make you learn faster or skip lessons. It just accelerates the gamification layer slightly. The core learning experience stays the same.

Cosmetic items are playful, not essential  
Dressing up the owl mascot is cute, but it's not the point. It's a small delight, not a monetization focus. This keeps the shop from feeling pushy.

Minimal choice reduces decision fatigue  
With only a handful of items, there's no browsing complexity. You see what's there, decide quickly, and return to learning.

### When To Use This Reward Shop Pattern

✅ Use minimal shops when:

-   Your retention driver is elsewhere (progression, streaks, skill-building)
-   Shop should support experience without becoming the experience
-   Users value simplicity and focus (don't want shopping distraction)
-   A few high-value items solve real friction points

❌ Don't use when:

-   Shop needs to be a major engagement driver
-   You want to explore monetization depth
-   Users expect variety and discovery in rewards
-   Core product doesn't have strong retention mechanics already

### Trade-offs

### What you gain:
Stays true to product purpose (learning, not shopping), reduces complexity, no risk of shop overshadowing core experience, users appreciate restraint

### What you sacrifice:
Limited monetization potential, fewer engagement touchpoints, not for users who want collection depth, less room for expansion

## Pattern #5: Sims Mobile - The Environmental Shop

![Sims Mobile shop interface with furniture categories, room-based organization, and free placement grid for home customization](/images/blog/5-reward-shop-patterns-that-keep-users-coming-back/body-5.jpg)

What it is: Category-based item browsing to build personal spaces that reflect time investment

### How It Works

Sims Mobile lets you decorate homes. The shop contains furniture, windows, flooring, bathroom fixtures - hundreds of items organized by room and function. You freely place items, creating layouts that feel personal.

Key characteristics:

-   Items grouped by category and room (furniture, windows, bathroom, nursery, kitchen)
-   Free placement with subtle snapping (guidance without forcing)
-   Inventory and shop connected (if missing items, go straight to shop)
-   Undo/change freely (move, replace, remove - no commitment pressure)
-   Direct shop access from edit mode

### Why This Reward Shop Pattern Works

Item categories are easy to understand  
Furniture, windows, bathroom items - organized like a real store. Finding things feels natural. Large inventories become navigable through clear grouping.

Free placement with guidance  
You can move items anywhere, but subtle snapping helps things look neat. Flexibility without chaos. The system guides but doesn't restrict.

Inventory and shop connected  
If you're decorating and realize you need more furniture, you can jump directly to the shop without breaking flow. The shopping experience integrates into creation.

Undo/change encourages experimentation  
No purchase feels permanent. Try a couch, don't like it? Move it. Replace it. Remove it. Low stakes keep it playful and safe to explore.

### When To Use This Reward Shop Pattern

✅ Use environmental shops when:

-   Users build, design, or create personal spaces
-   Product involves spatial customization (homes, islands, workspaces)
-   Items have clear categories and purposes
-   Freedom of placement adds value (not just selecting from templates)

❌ Don't use when:

-   No spatial or environmental component exists
-   Complexity overwhelms the core experience
-   Users want simplicity, not customization depth
-   Product context is transient (users don't spend time in the space)

### Trade-offs

### What you gain:
Deep personalization, high time investment (switching costs), creative expression, long-term engagement (always more to build/change)

### What you sacrifice:
Requires large item library, complexity in UI (category navigation), not for users seeking simplicity, needs free placement mechanics (technical cost)

| Pattern | Best For | Complexity | Retention Driver | Monetization Potential | Example Apps |
| --- | --- | --- | --- | --- | --- |
| **Utility Shop** | Action-heavy apps with progression | Medium | Functional value (items help you do more) | High | Pokemon Go, Clash of Clans |
| **Experience Shop** | Social/display apps | Low | Daily rotation (anticipation + FOMO) | Very High | Fortnite, Fall Guys |
| **Care Shop** | Emotional support apps | Low | Character attachment | Medium | Finch, Tamagotchi-style |
| **Minimal Shop** | Skill-building, focus apps | Very Low | Supports core retention (not the driver) | Low | Duolingo, Headspace |
| **Environmental Shop** | Creative/building apps | High | Personal space creation | Medium-High | Sims Mobile, Animal Crossing |

## The Reward Shop Decision Framework

Choosing the right shop pattern depends on your product's core retention model. Here's how to decide:

### Step 1: Identify Your Core Loop

Ask: What action do users repeat that drives value?

-   Repeated actions (steps, sessions, catches) → Consider Utility Shop
-   Skill-building (learning, practice) → Consider Minimal Shop
-   Social interaction (multiplayer, sharing) → Consider Experience Shop
-   Emotional support (self-care, habit-building) → Consider Care Shop
-   Creative expression (building, designing) → Consider Environmental Shop

### Step 2: Understand User Motivation

Ask: Why do users return?

-   External motivation (competition, status) → Experience Shop
-   Internal motivation (self-improvement, calm) → Care or Minimal Shop
-   Functional benefit (get better results) → Utility Shop
-   Creative satisfaction (building something personal) → Environmental Shop

### Step 3: Match Complexity to Product Stage

Early product (MVP, finding PMF):  
Start minimal. Add Utility or Care Shop only if it directly serves retention. Avoid complexity.

Growing product (proven retention, scaling):  
Layer Experience or Environmental Shop if user base supports it. Invest in content creation pipeline.

Mature product (established, optimizing):  
Experiment with hybrid models. Test rotation mechanics, seasonal items, limited editions.

### Step 4: Check Alignment

Ask these questions:

-   Does this shop reinforce my core loop, or distract from it?
-   Can I clearly explain why each item exists?
-   Will users understand the value before buying?
-   Does this fit the emotional context of my product?

If any answer is "no," reconsider the pattern.

## Common Mistakes With Reward Shops (What NOT To Do)

### ❌ Mistake #1: Copying Patterns Without Context

Why it fails:  
Duolingo's minimal shop works because retention comes from streaks and learning. Fortnite's cosmetic shop works because the game is competitive and social. Copying Fortnite's rotation into a meditation app creates FOMO anxiety - the opposite of what users need.

Instead:  
Match pattern to product purpose. If your app is about calm, don't add daily-changing pressure.

### ❌ Mistake #2: Adding Shops for "Engagement" Without Purpose

Why it fails:  
Users accumulate currency but don't know why. Items feel random. The shop becomes a feature no one uses because it doesn't serve a clear need.

Instead:  
Start with retention mechanics (progression, collection, customization). Only add a shop if it strengthens those mechanics.

### ❌ Mistake #3: Over-Gamifying Wellness Apps

Why it fails:  
Points, badges, and shops can make self-care feel transactional. Users come to apps like Headspace or Calm to escape gamified pressure - adding aggressive shop mechanics conflicts with that.

Instead:  
Use Care or Minimal patterns. Keep shops gentle, optional, and emotionally supportive.

### ❌ Mistake #4: No Preview Before Purchase

Why it fails:  
Users buy items, regret them, feel frustrated. Trust in the shop decreases. Fewer future purchases.

Instead:  
Show exactly what users get. Let them preview cosmetics on characters, see items in context, understand utility clearly.

### ❌ Mistake #5: Permanent Choices Without Undo

Why it fails:  
Users hesitate to buy because they fear regret. Decision paralysis. Lower conversion.

Instead:  
Let users move, replace, or remove items freely. Keep choices low-stakes and playful.

## Key Findings From Our Analysis

After analyzing these five apps, several clear patterns emerged:

Finding #1: Shops work best when items amplify existing behavior, not introduce new loops.  
Pokemon Go items enhance walking/catching. Fortnite skins enhance self-expression. Finch items enhance character care. The shop serves what users already do.

Finding #2: Preview before purchase dramatically reduces regret.  
Apps that show items in context (Fortnite character preview, Finch bird wearing outfit, Sims furniture placed in room) convert better and generate fewer refund requests.

Finding #3: Emotional framing matters more than item function.  
Finch's shop sells the same types of items as Sims (decorations, outfits), but the care framing makes purchases feel nurturing instead of transactional.

Finding #4: Daily rotation creates habits without functional pressure.  
Fortnite's rotating shop drives daily check-ins without making players feel behind if they miss a day. The rotation is content discovery, not loss aversion.

Finding #5: Minimal shops outperform complex shops in focus products.  
Duolingo keeps the shop tiny because shopping would distract from learning. Restraint = better retention for their use case.

## Implementation Checklist

If you're adding or redesigning a shop, use this checklist:

### Before You Build

-   Identify your core retention driver (what makes users return?)
-   Choose shop pattern that reinforces that driver
-   List 5-10 items with clear purpose (why does each exist?)
-   Decide: utility, cosmetic, care, or hybrid?

### During Design

-   Create clear item categories (easy browsing)
-   Design preview system (users see before buying)
-   Plan currency economy (how do users earn? how much do items cost?)
-   Decide: permanent or rotating inventory?

### Before Launch

-   Test: Can users explain why items exist?
-   Test: Do purchases feel valuable or regrettable?
-   Verify: Does shop support retention or distract from it?
-   Set success metrics (purchases, retention, engagement)

### After Launch

-   Monitor: Which items get bought? Which get ignored?
-   Track: Does shop usage correlate with retention?
-   Iterate: Remove items that don't serve purpose
-   Expand: Add items that users request

## What We Learned

The best reward shops don't feel like shops at all. They feel like natural extensions of the core experience—whether that's catching Pokemon, expressing yourself in Fortnite, caring for your Finch, learning in Duolingo, or building in Sims.

Three principles emerged across all five patterns:

1.  Purpose over variety - Every item should answer "why does this exist?" Fewer meaningful items beat many random ones.  
      
    
2.  Preview eliminates regret - Let users see, try, or understand items before buying. Transparency builds trust.  
      
    
3.  Match pattern to motivation - Utility for action-heavy products. Experience for social products. Care for emotional products. Minimal for focus products. Environmental for creative products.  
      
    

There's no universal "best" shop pattern. But there is a best pattern _for your product_ - and it's the one that makes your core retention loop stronger, not more complex.

## Research Methodology

We analyzed five mobile apps over three weeks:

-   Downloaded and actively used each app (10+ sessions per app)
-   Documented shop flows in Figma (complete user journeys from discovery to purchase)
-   Identified core patterns across different product categories
-   Tested purchase flows to understand preview, feedback, and post-purchase experience

Apps analyzed:

-   [Pokemon Go](https://pokemongolive.com/) (iOS/Android) — Location-based AR game
-   [Fortnite](https://www.fortnite.com/) (iOS/Android) — Battle Royale multiplayer
-   [Finch](https://finchcare.com/) (iOS/Android) — Self-care companion app
-   [Duolingo](https://www.duolingo.com/) (iOS/Android) — Language learning
-   [Sims Mobile](https://www.ea.com/games/the-sims/the-sims-mobile) (iOS/Android) — Life simulation

## References & Tools

Apps Analyzed:

-   [Pokemon Go (iOS)](https://apps.apple.com/app/pokemon-go/id1094591345)
-   [Fortnite (iOS)](https://apps.apple.com/app/fortnite/id1261357853)
-   [Finch (iOS)](https://apps.apple.com/app/finch-self-care-pet/id1449855263)
-   [Duolingo (iOS)](https://apps.apple.com/app/duolingo/id570060128)
-   [Sims Mobile (iOS)](https://apps.apple.com/app/the-sims-mobile/id1115162954)

## Need Help Implementing These Patterns?

Designing retention mechanics requires understanding your users, product stage, and core value proposition. Simply copying patterns rarely works—but adapting them to your specific context does.

We help AI and wellness startups design mobile experiences that drive retention through research-driven UX.

Our approach:

-   Analyze your product and user behavior
-   Identify which retention patterns fit your context
-   Design and test shop mechanics that strengthen core loops
-   Measure impact on engagement and retention

[View Our Work](/success-stories) | [Book a Free Audit](#book)

---

### Masterly Featured in Dribbble Select: Best Shots of the Year
URL: https://www.themasterly.com/blog/masterly-featured-in-dribbble-select-best-shots-of-the-year
News · 2026-03-03

We're excited to share that Masterly has been featured in Dribbble's annual "Best Shots of the Year" editorial and included in the newly launched Dribbble Select UX/UI Design Agency directory.

Dribbble Select is a specialized space for discovering agencies that consistently deliver on complex, large-scale projects. That's the kind of work we're built for — [Alterscope](/cases/alterscope-fintech-saas-platform-redesign-masterly-case-study), [Dentinostic](/cases/healthcare-startup-branding-mobile-app-and-website-design-that-helped-raise-eu650k), fintech platforms, SaaS tools where the problem space is messy, the stakes are real, and the design has to work hard.

Being recognized for that feels right. This is what we show up to do every day.

You can now find Masterly on [Dribbble](https://dribbble.com/Masterlydigital) and in the [Dribbble Select UX/UI Design Agency directory.](https://dribbble.com/ux-ui-design-agency)

## Glossary

### A/B Testing (Process & Methods)
URL: https://www.themasterly.com/glossary/ab-testing

Comparing two versions of a design by showing each to a slice of live traffic and measuring which drives the target metric better.

An A/B test splits live users between a control (A) and one or more variants (B), then measures which produces more of the behavior you care about — signups, purchases, upgrades. Because the comparison happens on real traffic at the same time, it isolates the effect of the change from seasonality and noise.

A/B testing is the engine of [conversion rate optimization](/glossary/conversion-rate-optimization) and [growth design](/glossary/growth-design). Its main traps are calling results before reaching statistical significance and testing changes too small to matter — discipline about sample size and hypothesis quality is what separates signal from superstition.

## In practice

In a B2B SaaS product, an A/B test might pit the current three-step signup against a variant that defers email verification until after the first project is created. Half of new visitors see each version; after two weeks, the variant shows an 11% lift in completed onboarding with no rise in spam accounts — so it ships to everyone. The discipline is in what didn't happen: nobody argued from taste, and the change was judged on the metric it was designed to move.

### Activation (Growth & Metrics)
URL: https://www.themasterly.com/glossary/activation

The point at which a new user first experiences the core value of a product — the 'aha moment' that predicts whether they'll stick around.

Activation is the moment a new user gets the point — sends the first message, sees the first report, completes the first transaction. Teams define it as a concrete milestone ("invited a teammate within 24 hours") because users who reach it retain far better than those who don't.

It is the hinge between acquisition and [retention](/glossary/retention): traffic is wasted if people never activate. That makes [onboarding](/glossary/onboarding) design — removing every obstacle between signup and first value — one of the highest-leverage surfaces in the whole product.

## In practice

A team suspects onboarding is fine because signups complete it. Defining activation changes the picture: the milestone is set to “created a first report within three days” — the behavior that separates retained accounts from churned ones in the cohort data. Only 31% of signups get there. Onboarding is redesigned around that single action (sample data, one CTA, everything else deferred), the number climbs to 47%, and week-four retention follows it up almost mechanically.

### Brand Identity (Business & Engagement)
URL: https://www.themasterly.com/glossary/brand-identity

The complete system of visual and verbal elements — logo, color, type, voice — that expresses what a company is and sets it apart.

Brand identity is the tangible, designed expression of a brand: the logo, color palette, typography, imagery style, and tone of voice that together make a company recognizable and communicate its character. It is how strategy becomes something people can see, read, and feel.

A coherent identity builds trust and differentiation — especially critical for early-stage startups competing against incumbents. It is typically documented in a [style guide](/glossary/style-guide) and then carried consistently into the product through [visual design](/glossary/visual-design) and the [design system](/glossary/design-system).

## In practice

A fintech startup walks into enterprise sales calls with a product that works and a brand that whispers “side project”: inconsistent logo files, five shades of blue, slideware that fights the website. An identity system — logo, palette, type, voice, templates — changes the meetings before it changes anything else: the deck, the site, and the product's empty states finally tell one story. Buyers can't articulate why the company suddenly feels fundable; that's the identity doing its job.

### Churn (Growth & Metrics)
URL: https://www.themasterly.com/glossary/churn

The rate at which users or customers stop using a product or cancel over a given period — the inverse of retention.

Churn is the percentage of users or revenue lost in a period — the leak in the bucket. It comes in flavors: user churn (people leaving), revenue churn (dollars lost), and voluntary versus involuntary (failed payments). Each points to a different fix, so measuring the right one matters.

High churn quietly caps growth: if new users pour out as fast as they come in, acquisition spend is wasted. Because churn is the mirror image of [retention](/glossary/retention), the levers are the same — better [onboarding](/glossary/onboarding), faster [activation](/glossary/activation), and delivering value people don't want to give up.

## In practice

A startup panics at 6% monthly churn and starts planning win-back campaigns. Segmenting first changes the plan: 40% of losses are involuntary — failed card payments, not decisions. Dunning emails, card-retry logic, and a grace period claw back most of that slice within a quarter, the cheapest retention work the team ever shipped. The remaining voluntary churn concentrates in accounts that never activated a second user — a design problem, not a billing one.

### Component Library (Deliverables & Artifacts)
URL: https://www.themasterly.com/glossary/component-library

A collection of reusable, pre-built UI elements — buttons, inputs, cards, modals — shared across a product to speed up and standardize design.

A component library is the reusable-parts inventory of a product: every button, form field, menu, and card built once and used everywhere. It exists in both the design tool (for designers) and the codebase (for engineers), ideally kept in lockstep so a component looks and behaves the same in Figma and in production.

It is the most tangible piece of a [design system](/glossary/design-system) — the system also carries [tokens](/glossary/design-token), guidelines, and governance. On its own, a component library already pays off by eliminating redraw-from-scratch work and the subtle inconsistencies that creep in when every screen reinvents the same elements.

## In practice

An audit of a three-year-old SaaS product finds fourteen button variants, five modals, and three different date pickers — each a past deadline's shortcut. Consolidating into a documented library of four buttons, one modal, and one picker takes a quarter of gradual migration. The payoff shows up quietly: a new designer ships their first production screen in days, and “which button do we use?” disappears from reviews entirely.

### Conversion Funnel (Growth & Metrics)
URL: https://www.themasterly.com/glossary/conversion-funnel

The staged path users take toward a goal — visit, sign up, activate, pay — where measuring drop-off at each step reveals where to improve.

A conversion funnel models a goal as a sequence of stages — say, landing → signup → activation → purchase — and measures how many users survive each transition. The shape of the funnel shows exactly where people fall away, turning a vague "we need more customers" into a specific "we lose 60% at signup."

Funnels are the diagnostic layer under [CRO](/glossary/conversion-rate-optimization) and [growth design](/glossary/growth-design). The biggest leverage is usually the leakiest step with the most traffic above it — fixing that beats optimizing a stage almost no one reaches.

## In practice

Instrumented for the first time, a SaaS funnel reads: 100% land, 34% start signup, 21% finish it, 12% activate, 6% pay. The shock is the signup finish rate — email verification loses 13 points, worse than any other stage. The team defers verification to after first value and the whole funnel re-shapes downstream. Without the stage-by-stage numbers, the team would have kept polishing the landing page — the stage that was performing fine.

### Conversion Rate Optimization (CRO) (Growth & Metrics)
URL: https://www.themasterly.com/glossary/conversion-rate-optimization

The systematic practice of increasing the share of users who take a desired action, through testing and iterative improvement of the experience.

CRO is the discipline of raising the percentage of visitors who do the thing you want — sign up, buy, book, upgrade. It works by finding the friction and drop-off in a [funnel](/glossary/conversion-funnel), forming hypotheses about why, and validating fixes with [A/B tests](/glossary/ab-testing) rather than guesses.

It is where design meets the bottom line. Small, compounding wins on a high-traffic step — a clearer value proposition, a shorter form, a better-timed prompt — can move revenue more than a big redesign. CRO is the tactical core of [growth design](/glossary/growth-design).

## In practice

A SaaS company wants more trials and reaches for a bigger ad budget. A CRO pass looks at the existing funnel first and finds the pricing page converting at half the benchmark — visitors can't tell which plan fits, and the FAQ answers questions nobody asks. Two tested changes — a “which plan is for you” selector and rewritten tier descriptions — lift pricing-page conversion by a third. Same traffic, more trials, zero added spend: the leak was cheaper to fix than the funnel was to refill.

### Customer Journey Map (Deliverables & Artifacts)
URL: https://www.themasterly.com/glossary/customer-journey-map

A visualization of the full experience a customer has with a product or brand over time, stage by stage, including actions, emotions, and pain points.

A journey map lays out the end-to-end experience of a [persona](/glossary/user-persona) across stages — awareness, onboarding, first value, everyday use, renewal — capturing what they do, think, and feel at each one, plus the pain points and moments of truth along the way.

Unlike a [user flow](/glossary/user-flow), which maps a single task in a product, a journey map spans channels and time, including the non-digital and emotional parts of the experience. It is the core artifact of [service design](/glossary/service-design) and a reliable way to spot where the biggest experience gaps — and opportunities — actually sit.

## In practice

A healthtech team maps the journey from ad click to first appointment: website, signup, identity check, approval email, booking, clinic visit. Laid on a wall with real data per stage, one gap glows — 38% of approved patients never book. The approval email celebrates (“you're in!”) but buries the booking link, and no reminder follows. The fix spans email copy, a follow-up sequence, and a booking shortcut in the app: three teams, one map, one number moved.

### Design Debt (Business & Engagement)
URL: https://www.themasterly.com/glossary/design-debt

The accumulated cost of inconsistent, outdated, or shortcut design decisions that make a product harder to use and slower to evolve.

Design debt is the interface equivalent of technical debt: every rushed screen, one-off component, and skipped pattern adds up into an inconsistent, confusing product that is progressively harder to change. It usually accrues quietly, one deadline at a time, until the whole thing feels dated and unwieldy.

The interest shows up as slower shipping, jarring inconsistencies, and rising user friction. Paying it down means consolidating patterns — often into a [design system](/glossary/design-system) — after a [UX audit](/glossary/ux-audit) maps where the debt is concentrated. Left unaddressed, it eventually forces a costly full [redesign](/services/product-redesign).

## In practice

Design debt rarely announces itself. A SaaS team ships a custom date picker for one feature under deadline; two quarters later there are four date pickers, three button styles, and a settings page nobody wants to touch. Each shortcut was locally rational — together they mean every new feature starts with “which pattern do we copy?” and every redesign estimate doubles. The real cost usually surfaces during a [UX audit](/glossary/ux-audit), when the inconsistencies are counted in one place for the first time.

### Design Retainer (Business & Engagement)
URL: https://www.themasterly.com/glossary/design-retainer

An ongoing engagement where a client reserves a set amount of design capacity each month, rather than paying per fixed-scope project.

A design retainer reserves a recurring block of a team's capacity — a certain number of hours or a defined output — for a flat monthly fee. It trades the rigid boundaries of project work for flexibility: priorities can shift week to week as the product's needs change.

Retainers fit ongoing, evolving work far better than fixed-scope contracts, which is why they underpin the [embedded team](/glossary/embedded-design-team) and [team extension](/services/team-extension) models. They also smooth cost and guarantee availability — the design partner is there when a fast-moving startup needs them, not queued behind a new statement of work.

## In practice

A startup reserves a monthly block of design capacity. In January it goes to the onboarding redesign; in February, a fundraise pivots everything to the pitch deck and data-room materials; March splits between marketing pages and design-system cleanup. No new scoping call, no change orders — priorities shift inside the reserved capacity. For a company whose needs change weekly, that flexibility is the product; the hours are just the unit.

### Design Sprint (Process & Methods)
URL: https://www.themasterly.com/glossary/design-sprint

A time-boxed process — classically five days — that runs a big product question from idea to a tested prototype with real users.

A design sprint compresses months of debate into a structured week: understand the problem, sketch solutions, decide on one, build a realistic [prototype](/glossary/prototyping), and test it with five users on the final day. It was popularized by Google Ventures as a way to answer high-stakes questions fast.

The output is not a finished product but a validated (or invalidated) direction, backed by real reactions rather than opinions. Sprints work best for genuinely open questions — a new product, a risky redesign — where the cost of guessing wrong is high.

## In practice

A founder wants to build a marketplace add-on; engineering estimates a quarter. Instead, the team runs a five-day sprint: Monday maps the problem, Tuesday sketches, Wednesday picks a direction, Thursday builds a realistic prototype, Friday five target customers try it. Result: buyers love it, but suppliers — the side the business depends on — see no reason to participate. The add-on dies on Friday afternoon, and the quarter goes to something customers actually validated.

### Design System (Deliverables & Artifacts)
URL: https://www.themasterly.com/glossary/design-system

A single source of truth for a product's UI — reusable components, tokens, patterns, and guidelines that keep design consistent and fast.

A design system is more than a UI kit: it bundles reusable [components](/glossary/component-library), [design tokens](/glossary/design-token), usage rules, and often the coded implementation into one governed source of truth. Designers and engineers both draw from it, which is what keeps a growing product visually and behaviorally consistent.

Its payoff is compounding speed. Once the system exists, new screens assemble from ready parts instead of being drawn from scratch, and a change to a token — a color, a spacing value — propagates everywhere at once. The cost is real maintenance, so systems earn their keep on products large enough to suffer from drift.

## In practice

A 30-person SaaS company ships in three surfaces — web app, marketing site, mobile. Before a design system: the same “primary button” exists in seven shades, and a simple settings screen takes a week because everything is redrawn. After: new screens assemble from documented components in a day, engineers stop guessing paddings, and a rebrand becomes a [token](/glossary/design-token) swap instead of a quarter-long repaint. The catch: someone must own it, or it drifts back into chaos within months.

### Design Thinking (Process & Methods)
URL: https://www.themasterly.com/glossary/design-thinking

A human-centered problem-solving framework that moves through empathize, define, ideate, prototype, and test to reach validated solutions.

Design thinking is a repeatable approach to ambiguous problems, usually framed in five modes: empathize (understand the user), define (frame the real problem), ideate (generate options), prototype (make it tangible), and test (learn from real people). The modes are non-linear — teams loop back constantly.

Its value is discipline against assumption. By forcing teams to talk to users and test cheap prototypes before committing to a build, it de-risks big bets. A [design sprint](/glossary/design-sprint) is one popular, time-boxed way to run the whole loop in a week.

## In practice

A SaaS team argues for weeks about which retention feature to build. Run as a design-thinking loop instead: a week of churned-customer interviews (empathize) reframes the problem — users don't leave for missing features, they leave because month two delivers no new value (define). The team sketches options (ideate), builds a clickable [prototype](/glossary/prototyping) of a monthly insights digest, and tests it with eight customers in days. The debate ends because evidence replaced opinion.

### Design Token (Deliverables & Artifacts)
URL: https://www.themasterly.com/glossary/design-token

A named, reusable variable for a design decision — a color, spacing, or type value — that keeps design and code in sync from one source.

A design token stores a single design decision as a named variable — `color.primary`, `space.4`, `radius.lg` — rather than a hard-coded value scattered across files. Because both the design tool and the codebase reference the same token, a change in one place updates everywhere consistently.

Tokens are the atoms of a [design system](/glossary/design-system): components are built from them, and theming (light/dark, white-label brands) becomes a matter of swapping token values rather than rewriting components. They are what makes large-scale visual consistency maintainable instead of heroic.

## In practice

A company rebrands from blue to violet. Without tokens, that's a months-long hunt through hardcoded hex values across two apps and a marketing site. With tokens, `color.primary` changes once and propagates everywhere the token is referenced — the rebrand ships in days, and dark mode later becomes a second set of token values rather than a parallel codebase. Same story for spacing and type: one decision, one variable, every surface consistent.

### Embedded Design Team (Business & Engagement)
URL: https://www.themasterly.com/glossary/embedded-design-team

An external design team that integrates directly into a company's workflow and rituals, operating like in-house staff without the hiring overhead.

An embedded design team works inside a client's process — same standups, same tools, same roadmap — rather than taking projects over the wall. It gives a startup senior, multi-disciplinary design capacity that ramps in days, without the months and risk of hiring a full in-house team.

The model suits companies that need design continuously but can't yet justify (or fill) permanent roles. Unlike a one-off project, an embedded team builds lasting context about the product and users, so the work compounds. It is closely related to [team extension](/services/team-extension) and usually runs on a [design retainer](/glossary/design-retainer).

## In practice

A Series A startup needs senior product design but can't hire fast enough. An embedded team joins instead: within a week, two designers are in the client's standups, Slack, and Figma, pulling tickets from the same roadmap as everyone else. There's no agency theater — no weekly status decks, no big handover. Three months in, the founders describe them as “our design team” without irony; the difference from employees is a contract, not a workflow.

### Growth Design (Design Disciplines)
URL: https://www.themasterly.com/glossary/growth-design

Design practiced as a growth lever — every flow, screen, and experiment aimed explicitly at activation, conversion, and retention metrics.

Growth design treats the interface as a system for moving numbers. Instead of shipping a redesign and hoping, growth designers form hypotheses, run [A/B tests](/glossary/ab-testing), and iterate on the specific steps where users drop off — onboarding, checkout, upgrade, re-engagement.

It sits at the intersection of product design and growth marketing. The work looks like ordinary UX, but the framing is different: success is defined up front as a measurable change in [activation](/glossary/activation), [conversion](/glossary/conversion-rate-optimization), or [retention](/glossary/retention), and the design is judged against it.

## In practice

A typical growth-design engagement starts with a funnel, not a screen. Say trial signups are healthy but paid conversion is stuck at 4%: a growth designer maps where trial users stall, finds that most never invite a teammate — the behavior that predicts conversion — then redesigns the empty states and first-run flow around that single action, and ships it as an [A/B test](/glossary/ab-testing) rather than a redesign. Over a quarter, that loop — hypothesis, ship, measure — compounds into gains a one-off redesign rarely delivers.

### Heuristic Evaluation (Process & Methods)
URL: https://www.themasterly.com/glossary/heuristic-evaluation

An expert review of an interface against established usability principles (heuristics) to find problems without recruiting users.

In a heuristic evaluation, one or more specialists inspect a product against a known set of rules — most famously Nielsen's ten heuristics, covering things like system status visibility, error prevention, and consistency. Each violation is logged and rated by severity.

It is fast and cheap because it needs no participants, which makes it a natural first pass in a [UX audit](/glossary/ux-audit). Its blind spot is that experts are not your users; heuristics catch known-bad patterns but miss the surprises that only [usability testing](/glossary/usability-testing) with real people reveals. The two methods are complementary, not interchangeable.

## In practice

Two reviewers independently walk a SaaS app against Nielsen's ten heuristics and log violations: no visible system status during a 20-second import, destructive actions without confirmation, error messages written for engineers. Merged and severity-ranked, the list holds 23 issues — six critical. Cost: two days, zero participant recruiting. The team fixes the criticals before spending a cent on [usability testing](/glossary/usability-testing), which then surfaces the problems experts couldn't predict.

### Information Architecture (Process & Methods)
URL: https://www.themasterly.com/glossary/information-architecture

The structural design of a product's content and navigation — how information is organized, labeled, and grouped so people can find it.

Information architecture (IA) is the organizing logic beneath a product: the categories, the navigation, the labels, and the relationships between pages. Good IA matches the user's mental model, so people find what they need without thinking about the structure at all.

IA is expressed in artifacts like [sitemaps](/glossary/sitemap) and navigation schemes, and it is validated with methods like card sorting and tree testing. When IA is wrong, no amount of visual polish saves it — users simply cannot find things, and search becomes a crutch for a broken structure.

## In practice

A SaaS product's settings sprawl across five menus; support keeps answering “where do I change billing?” An IA pass runs a card sort with twelve customers — users group things by task (“money stuff,” “my team,” “notifications”), not by the org chart the current nav mirrors. Restructured around those groupings and validated with a tree test, the new nav cuts settings-related tickets and, tellingly, in-app search usage — people stop needing the escape hatch.

### Interaction Design (Design Disciplines)
URL: https://www.themasterly.com/glossary/interaction-design

Designing the moment-to-moment behavior of an interface — how it responds to input, transitions between states, and gives feedback.

Interaction design (often shortened to IxD) is about behavior over time: what happens when you tap, drag, hover, submit, or wait. It defines states (default, loading, error, empty, success), transitions between them, and the micro-feedback that tells a user their action registered.

Good interaction design is mostly invisible — it removes doubt. When a button visibly reacts, a form explains its error inline, or a list animates a new item into place, that is interaction design making the product feel responsive and trustworthy.

## In practice

Consider a dashboard's “save” moment. Weak interaction design: the user clicks, nothing visibly happens for two seconds, they click again, two records save. Strong interaction design: the button switches to a spinner instantly, the row updates optimistically, and a failure rolls back with an inline explanation and a retry. Same feature, same visuals — completely different trust level. Interaction design is that layer of states, feedback, and timing that makes software feel reliable.

### Mockup (Deliverables & Artifacts)
URL: https://www.themasterly.com/glossary/mockup

A high-fidelity, static representation of a screen showing the final visual design — real colors, type, and content — but without interactivity.

A mockup is what a screen will actually look like: full [visual design](/glossary/visual-design) applied — real type, color, imagery, and content — but static, with nothing clickable. It is the fidelity step between a gray [wireframe](/glossary/wireframing) and an interactive [prototype](/glossary/prototyping).

Mockups are what stakeholders usually mean by "the design," and they are ideal for sign-off on look and feel. To test behavior and flow, though, they need to be linked into a prototype — a mockup alone can't reveal whether a sequence of screens actually works.

## In practice

Before building, a designer produces pixel-final mockups of the new billing page: real plan names, real prices, the exact table that will ship. Stakeholders approve look and tone; legal catches a compliance line that must appear near the price. None of that feedback needed interactivity — it needed realism. The mockups then become the spec for engineering and the frames for a clickable [prototype](/glossary/prototyping) if the flow itself needs testing.

### Motion Design (Design Disciplines)
URL: https://www.themasterly.com/glossary/motion-design

The use of animation and transitions in an interface to guide attention, explain change, and give a product a sense of life and quality.

Motion design applies animation with intent: a menu that slides in to show where it came from, a number that counts up to draw the eye, a loader that keeps a wait feeling short. Purposeful motion explains *what changed* and *why*, reducing the cognitive cost of a moving interface.

The line between delight and distraction is thin. Effective motion is fast, consistent, and respects reduced-motion preferences — it supports the [interaction](/glossary/interaction-design) rather than showing off. Overused, animation slows people down and cheapens the product.

## In practice

A list reorders after a user archives an item. Without motion, the row vanishes and users scan the screen wondering what happened. With a 200ms slide-and-collapse, the eye follows the change and no explanation is needed. That's the test for product motion: it should answer “what just changed?” faster than words. The craft details — durations under ~300ms, consistent easing, and honoring the user's reduced-motion setting — separate motion that helps from motion that shows off.

### MVP (Minimum Viable Product) (Deliverables & Artifacts)
URL: https://www.themasterly.com/glossary/mvp

The smallest version of a product that delivers real value to early users, built to learn from the market with the least effort.

An MVP is the leanest product that still solves a real problem for real users — enough to ship, learn, and iterate, but no more. Its purpose is to test the riskiest assumptions of a business with the least time and money, before committing to a full build.

The word that trips teams up is *viable*: an MVP must actually deliver value, not just be small. A cramped, broken first version teaches you that people dislike a bad product, not whether they want the real one. Getting the MVP scope right is the first step toward [product-market fit](/glossary/product-market-fit).

## In practice

A founder plans six months of build: integrations, roles, dashboards. An MVP pass cuts it to the one workflow the target user is hired for — import data, get the weekly report — shipped in six weeks to ten design partners. The learning arrives immediately: retention is fine, but every buyer asks the same pricing question, and two “must-have” integrations go unmentioned. The next quarter is planned on evidence instead of the original guess.

### North Star Metric (Growth & Metrics)
URL: https://www.themasterly.com/glossary/north-star-metric

The single metric that best captures the core value a product delivers, used to align a whole team's decisions around one number.

A North Star metric is the one number a company agrees best reflects the value it delivers to customers — nights booked, messages sent, weekly active teams. It is chosen so that moving it means the business and its users win together, and it becomes the shared reference for prioritization.

The discipline is in the choice. A good North Star is a leading indicator of value and revenue, not a vanity number; it resists gaming and connects to real user behavior. Around it, teams define input metrics — [activation](/glossary/activation), [retention](/glossary/retention) — that they can actually influence week to week.

## In practice

A startup tracks signups as its headline number — and ships a quarter of features that lift signups while revenue stays flat. Switching the North Star to “weekly active teams” changes decisions immediately: a viral-but-shallow referral idea loses priority to a collaboration feature that makes teams sticky, and each squad takes an input metric (activation, invite rate, report frequency) it can actually move. The number on the dashboard finally means the business is growing, not just the top of the funnel.

### Onboarding (Growth & Metrics)
URL: https://www.themasterly.com/glossary/onboarding

The designed experience that guides a new user from first launch to their first real success with a product.

Onboarding is everything between "just signed up" and "got real value": the setup steps, empty states, prompts, and guidance that carry a new user to their [activation](/glossary/activation) moment as quickly as possible. It is the first — and often the harshest — impression a product makes.

The best onboarding removes work rather than adding tutorials: sensible defaults, pre-filled data, and a single obvious next step beat a carousel of tips. Because it sits directly on the path to [retention](/glossary/retention), onboarding is one of the most valuable flows to design and continuously test.

## In practice

A SaaS product greets new users with a six-step tour and an empty dashboard. The redesign inverts it: signup drops the user into a pre-filled sample project with one highlighted action — “run your first report.” The tour is gone; contextual hints appear only where users historically stall. Time-to-first-report falls from days to minutes, and [activation](/glossary/activation) climbs accordingly. The lesson generalizes: onboarding that removes work beats onboarding that explains work.

### Product Design (Design Disciplines)
URL: https://www.themasterly.com/glossary/product-design

End-to-end design ownership of a digital product — from user research and strategy through UX, UI, and shipping — tied to business outcomes.

Product design is the broadest of the design disciplines: a product designer owns the problem from end to end, blending research, [UX](/glossary/ux-design), [UI](/glossary/ui-design), and a working understanding of the business and the tech constraints. The output is not just screens — it is a decision about what to build and why.

Unlike a pure visual role, product designers are measured on outcomes: activation, conversion, retention. They live close to product managers and engineers, and the best of them treat design as a lever on the company's metrics rather than a decoration on top of the roadmap.

## In practice

In a Series A SaaS team, a product designer might own “reduce time-to-first-report” for the quarter: they interview five customers, map the current flow, spot that setup requires data the user doesn't have on day one, propose a sample-data mode, prototype it, test it, and ship it with engineering — then watch the activation dashboard, not the Dribbble likes. The role spans research to shipped outcome, which is exactly what separates it from a purely visual brief.

### Product-Market Fit (Business & Engagement)
URL: https://www.themasterly.com/glossary/product-market-fit

The stage at which a product satisfies a strong market demand so well that usage, retention, and word-of-mouth grow on their own.

Product-market fit (PMF) is the point where a product clearly serves a real, sizable demand — users adopt it, keep using it, and tell others, so growth starts to feel like it's being pulled rather than pushed. Before PMF, effort leaks away; after it, the problem shifts to scaling.

PMF is felt more than precisely measured, but the signals are concrete: strong [retention](/glossary/retention) curves, organic referral, and users who would be genuinely disappointed to lose the product. Reaching it is the real goal of an [MVP](/glossary/mvp) — everything before it is a search for the fit.

## In practice

Two startups both claim PMF. The first shows a retention curve that flattens at a healthy level, a growing share of signups from word of mouth, and users who answer “very disappointed” when asked about losing the product. The second shows a big launch spike, paid traffic, and cohort curves that decay to zero. Same revenue this month — completely different companies. The signals, not the sentiment, are what an investor (or a founder being honest) reads.

### Prototyping (Process & Methods)
URL: https://www.themasterly.com/glossary/prototyping

Building an interactive, clickable model of a product so a flow can be experienced and tested before it is engineered.

A prototype simulates how a product behaves — screens linked together so a person can click through a real task — without the cost of building it for real. Fidelity ranges from rough tapping-through-wireframes to near-production mockups with working transitions.

The purpose is to learn early. A prototype turns a debate into a test: put it in front of users, watch them attempt the flow, and fix the problems while they are still cheap. It is the bridge between [wireframing](/glossary/wireframing) and engineering, and the raw material for [usability testing](/glossary/usability-testing).

## In practice

Before committing a sprint to a new pricing flow, a designer links twelve mockups into a clickable prototype and puts it in front of five prospects with a task: “pick the plan that fits your team.” Two can't find annual billing; one reads the middle tier as “per company” when it's per seat. The fixes cost a day in Figma. The same lessons learned in production would have cost an engineering sprint plus a support-ticket wave — the prototype paid for itself before launch.

### Retention (Growth & Metrics)
URL: https://www.themasterly.com/glossary/retention

The measure of how many users keep coming back to a product over time — the clearest signal of whether it delivers lasting value.

Retention tracks whether users return — day over day, week over week, month over month. It is the truest test of value: acquisition and [activation](/glossary/activation) get people in the door, but only a product worth coming back to holds them. A flat or rising retention curve is the strongest evidence of [product-market fit](/glossary/product-market-fit).

Retention and [churn](/glossary/churn) are two sides of one coin. Because the cost of keeping a user is far below the cost of acquiring a new one, small improvements to retention compound into outsized effects on growth and unit economics.

## In practice

A team plots weekly cohort curves for the first time. The shape tells the story: curves drop steeply for three weeks, then flatten around 35% — users who survive a month tend to stay. Digging into what the survivors share reveals one habit: they set up a recurring report in week one. That correlation redirects the roadmap — instead of new acquisition features, the quarter goes to making recurring reports the default path, and the flat part of the curve rises cohort by cohort.

### Service Design (Design Disciplines)
URL: https://www.themasterly.com/glossary/service-design

Designing the entire experience of a service across every touchpoint and channel — digital and human — not just a single screen or app.

Service design zooms out from a single interface to the whole journey a person takes with an organization — the app, the emails, the support call, the onboarding packet, the in-person moment. It maps how those touchpoints connect and where the experience breaks between them.

It is especially relevant when a product spans channels: a fintech that combines an app, a card, and a call center, or a healthtech that links a patient app to a clinic. A [customer journey map](/glossary/customer-journey-map) is the service designer's core tool.

## In practice

A healthtech startup has a polished app but loses patients between “approved” and “first appointment.” Service design maps the whole journey — app, email, clinic front desk, insurance call — and finds the drop: approval emails arrive from an unrecognized sender and the booking link expires in 48 hours. No screen redesign fixes that; the fix spans email sending, link policy, and a front-desk script. Mapping cross-channel handoffs is exactly the work a single-product lens misses.

### Sitemap (Deliverables & Artifacts)
URL: https://www.themasterly.com/glossary/sitemap

A diagram of all the pages in a website or app and how they relate hierarchically — the blueprint of its structure and navigation.

A sitemap lays out every page of a site or app and the parent-child relationships between them, usually as a tree. It is the concrete expression of [information architecture](/glossary/information-architecture) — the shared map a team agrees on before designing individual screens.

There are two flavors worth distinguishing: a *design* sitemap for planning structure, and an *XML sitemap* that lists URLs for search engines to crawl. Both matter — one keeps humans oriented, the other helps a site get discovered — but they are different artifacts serving different audiences.

## In practice

Before a marketing-site redesign, the team inventories 43 pages accumulated over three years and draws the current sitemap. Half the pages get no traffic; several compete for the same query. The redesign ships with 18 pages in a hierarchy that mirrors how buyers search — services, industries, proof, resources — plus an XML sitemap so crawlers index the new structure fast. The diagram took an afternoon and prevented the classic mistake: redesigning page-by-page with no plan for the whole.

### Style Guide (Deliverables & Artifacts)
URL: https://www.themasterly.com/glossary/style-guide

A reference document defining a brand or product's visual rules — colors, typography, logo usage, spacing, and tone — for consistent application.

A style guide codifies the visual and verbal rules of a brand or product: the exact color values, type scale, logo clear-space, imagery style, and often the tone of voice. It exists so that anyone — a new designer, a marketer, an agency — can produce on-brand work without guessing.

A style guide is narrower than a [design system](/glossary/design-system): it documents *rules and assets* but not the interactive, coded components. It is often the first artifact to come out of a [brand identity](/glossary/brand-identity) project and the reference every later deliverable checks against.

## In practice

After a rebrand, a startup ships a style guide: exact color values, the type scale, logo clear-space, photography direction, and voice examples with do/don't pairs. A month later the effect is visible in the wild — the sales deck, three landing pages built by a contractor, and the product's empty states all read as one company. Before the guide, every new asset was a small reinvention; after, on-brand became the default instead of an act of heroism.

### UI Design (Design Disciplines)
URL: https://www.themasterly.com/glossary/ui-design

The craft of the visual and interactive surface of a product — layout, type, color, spacing, and components users see and touch.

UI (user interface) design is the visible layer of a product: the buttons, forms, cards, typography, and color that a person actually looks at and interacts with. It turns the structure defined in [UX design](/glossary/ux-design) into a concrete, polished, on-brand surface.

Modern UI work is component-driven. Rather than designing screens one at a time, designers build reusable elements — inputs, menus, modals — inside a [design system](/glossary/design-system), so the interface stays consistent and ships faster as the product grows.

## In practice

Two versions of the same dashboard can share an identical structure and produce different outcomes purely through UI: one uses consistent spacing, a clear type hierarchy, and a single accent color for primary actions; the other buries the main button among five equally loud elements. Users describe the first as “simpler” even though nothing structural changed. In day-to-day product work, UI design mostly means assembling screens from a [component library](/glossary/component-library) and making hierarchy decisions — what should be seen first, second, and not at all.

### Usability Testing (Process & Methods)
URL: https://www.themasterly.com/glossary/usability-testing

Watching real users attempt real tasks in a product or prototype to find where they struggle, hesitate, or fail.

Usability testing is deceptively simple: give a representative user a realistic task, then watch — mostly in silence — where they get stuck. Five participants typically surface the majority of serious problems, which is why it is one of the highest-leverage research methods available.

It works on anything clickable, from a paper sketch to a live product. Pairing it with a [heuristic evaluation](/glossary/heuristic-evaluation) — an expert review against known usability principles — catches both the problems users hit and the ones they quietly tolerate.

## In practice

Five participants, one task: “upgrade your plan and add a teammate.” Three of the five stall on the same screen — the plan picker reads as informational, not clickable. Nobody on the team had seen it, because they all knew where to click. One afternoon of testing, one obvious fix, and the upgrade flow's completion rate moves more than a quarter of visual polish ever did. The method's power is embarrassment: watching real people fail at your “obvious” design.

### User Flow (Process & Methods)
URL: https://www.themasterly.com/glossary/user-flow

A map of the sequence of steps and decisions a user moves through to complete a task, from entry point to goal.

A user flow diagrams the path to a goal — sign up, make a payment, book a call — as a series of screens, actions, and branching decisions. It exposes the length and complexity of a task before any screen is designed, making unnecessary steps and dead ends obvious.

Flows are the connective tissue between [information architecture](/glossary/information-architecture) and [wireframes](/glossary/wireframing). Shortening a critical flow is one of the most reliable ways to lift [conversion](/glossary/conversion-rate-optimization): every removed step is a place users can no longer drop off.

## In practice

Mapping “invite a teammate” in a B2B app exposes what no single screen shows: nine steps, including an email round-trip and a permissions picker most users don't understand. Two branches dead-end — an expired-link state with no re-send, and an edge case where the invitee lands on a signup page with no context. Cutting the flow to four steps and fixing both dead-ends lifted team activation; the map made the problem undeniable before a pixel moved.

### User Persona (Deliverables & Artifacts)
URL: https://www.themasterly.com/glossary/user-persona

A research-based, semi-fictional profile of a target user — their goals, context, and frustrations — used to keep design decisions grounded.

A persona distills patterns from [user research](/glossary/user-research) into a memorable, representative character: who they are, what they are trying to accomplish, the context they work in, and what gets in their way. It gives a team a shared, specific "who" to design for instead of a vague "the user."

Personas are only as good as the research behind them; invented from assumptions, they become a way to launder opinion. Used well, they anchor prioritization — "would this actually help Maya close her month-end faster?" — and feed directly into [journey maps](/glossary/customer-journey-map) and flows.

## In practice

A roadmap debate stalls: sales wants an admin console, product wants richer reports. The team's two research-based personas settle it — “Maya, the ops lead who buys and configures” touches the console monthly, while “Dan, the analyst who lives in reports” is the daily active user whose renewal depends on output quality. Reports win the quarter. The personas didn't add data; they made existing research impossible to argue past.

### User Research (Process & Methods)
URL: https://www.themasterly.com/glossary/user-research

The systematic study of users' needs, behaviors, and pain points — through interviews, surveys, and observation — to ground design in evidence.

User research is how a team replaces opinion with evidence. It spans qualitative methods (interviews, contextual observation, [usability tests](/glossary/usability-testing)) and quantitative ones (surveys, analytics, funnels), each answering a different kind of question — *why* people behave a certain way versus *how many* do.

Research feeds nearly every other artifact: [personas](/glossary/user-persona), [journey maps](/glossary/customer-journey-map), and prioritized problem lists all come from it. Skipping it doesn't remove the assumptions — it just leaves them untested until they surface as expensive mistakes in production.

## In practice

A team assumes users churn because the product lacks integrations. Six churned-customer interviews later, a different story: people left because the weekly report they showed their boss broke when data sources changed — trust, not features. Analytics alone couldn't reveal that (the events looked normal), and interviews alone couldn't size it (analytics showed 30% of accounts hit the breakage). Pairing the two methods is what turned a roadmap guess into a confident fix.

### UX Audit (Business & Engagement)
URL: https://www.themasterly.com/glossary/ux-audit

A structured expert review of a product's user experience that identifies usability problems and prioritizes fixes by impact.

A UX audit is a systematic diagnosis of an existing product: specialists review it against usability principles ([heuristic evaluation](/glossary/heuristic-evaluation)), analytics, and often [usability testing](/glossary/usability-testing), then catalog the problems and rank them by user impact and effort to fix.

The deliverable is a prioritized action list, not a redesign — it tells a team exactly where the experience leaks and what to fix first. Audits are the low-risk entry point before committing to a full [redesign](/services/product-redesign), and a reliable way to surface accumulated [design debt](/glossary/design-debt).

## In practice

Before committing to a redesign, a SaaS team orders a UX audit. Specialists walk the product across six layers — design review, IA, monetization, performance, SEO, analytics — and return a severity-ranked list: six blockers, nineteen frictions, a handful of quick wins. The surprise: half the blockers live in the upgrade flow nobody planned to touch. The team fixes the top five before any redesign talk, and two of them move revenue within a month — the audit paid for itself before the “real” project began.

### UX Design (Design Disciplines)
URL: https://www.themasterly.com/glossary/ux-design

The practice of shaping how a product feels to use — its flows, structure, and logic — so people reach their goal with the least friction.

UX (user experience) design covers everything that determines whether a product is easy or painful to use: the information architecture, the user flows, the copy, the states, and the decisions about what to show when. It is a research-led discipline — good UX starts from a real user goal and works backward to the simplest path there.

UX is often confused with [UI design](/glossary/ui-design), but they answer different questions. UX decides *what* the screens are and *why*; UI decides *how* they look. Strong products need both, and the handoff between them is where most quality is won or lost.

## In practice

Picture a SaaS signup that loses 40% of prospects on one form. A UX designer watches five real users attempt it and sees the same stumble: an ambiguous “company size” field and an error message that appears only after submit. The fix isn't visual — cut two fields, reorder the rest by confidence, surface errors inline. Completion climbs, and nothing about the “look” changed. That's UX design: the work is in the flow and the logic, and it's usually invisible when done well.

### Visual Design (Design Disciplines)
URL: https://www.themasterly.com/glossary/visual-design

The discipline of aesthetics and communication in an interface — typography, color, imagery, and layout working toward clarity and brand.

Visual design governs how a product looks and what that look communicates. It is the deliberate use of typography, color, contrast, imagery, and space to create hierarchy, guide attention, and carry a brand's personality into every screen.

While it overlaps with [UI design](/glossary/ui-design), visual design leans harder on craft and communication than on interaction mechanics. Done well, it makes a product feel considered and premium; done poorly, it undermines trust no matter how solid the underlying [UX](/glossary/ux-design).

## In practice

Take one wireframe and dress it two ways: version A with a disciplined type scale, generous whitespace, and one accent color; version B with five font sizes, tight margins, and competing colors. In tests, users rate version A as more trustworthy and even “faster” — before using either. For a startup, that perception gap is money: the same product demo reads as enterprise-grade or as a side project depending on visual execution alone.

### Wireframing (Process & Methods)
URL: https://www.themasterly.com/glossary/wireframing

Sketching the low-fidelity skeleton of a screen — layout, content blocks, and hierarchy — before any visual styling is applied.

A wireframe is a stripped-back blueprint of a screen: boxes, labels, and placement with no color, imagery, or final type. Working in grayscale on purpose keeps the conversation on structure and priority — what goes where, and what matters most — before anyone argues about shades of blue.

Wireframes sit between the abstract ([user flows](/glossary/user-flow), [IA](/glossary/information-architecture)) and the concrete ([mockups](/glossary/mockup), [prototypes](/glossary/prototyping)). They are cheap to change, which is exactly the point: it is far better to move a box in a wireframe than to rebuild a polished screen.

## In practice

Before any UI work on a new analytics dashboard, a designer sketches six gray-box layouts in a morning: metrics-first, table-first, alerts-first, and three hybrids. The team kills four in a half-hour review — something that would have taken weeks if each had been fully designed. The two survivors move to [prototyping](/glossary/prototyping) for a real test. Total cost of exploring six directions: one day. That economy is the entire point of wireframes.