WPMU DEV
Plugin Suite & Dashboard Overhaul.
Redesigned the core WPMU DEV plugin suite and shipped a scalable atomic design system — growing Smush to 2M+ installs and lifting Pro conversions by 47%.
A full redesign of the optimization flow — built for clarity, speed, and confidence at scale.
Smush installs since the redesigned onboarding shipped.
Bounce Rate
Post-LaunchPage rendering boost via Hummingbird.
Significant uplift in premium upgrades from the free tier.
Design System
Re‑Engineering the Core.
Existing UI patterns mapped before a single new component was built.
Figma Variables covering colour, spacing, radius, and type across all plugins.
The technical debt was manifesting as high cognitive load — users couldn't find what mattered. We stripped the UI to its atomic elements to build a system that scales across all Smush and Hummingbird deployments.
Before redesigning any screen, we mapped every component into a unified token system: SUI 3 Atomic Design. Only then did we refactor the flows.
The inconsistency wasn't in the features.
It was in the design language.
"I spend more time figuring out where to click than actually using the plugin. Everything looks different.
User research · pre-SUI 3
plugins each with siloed UI patterns — different buttons, spacing, and feedback states
Pattern silosdrop-off rate in the first 3 settings screens before the redesign shipped
Onboarding drop-offexisting components with no shared token mapping before the audit began
Component debtlonger to complete identical tasks across different plugins due to inconsistent affordances
Cognitive loadshared Figma libraries before the SUI 3 audit — each plugin had its own isolated file
No source of truthevery plugin used hand-coded spacing, color values, and radii — no token pipeline
Token gapBuilding SUI 3 Atomic — a single token system, shared component library, and unified Figma Variables — before redesigning any plugin screen would eliminate UI inconsistency and cut onboarding drop-off across all six plugins.
Token architecture
80+ Figma Variables covering color, spacing, radius, and type — a single source of truth propagated across all six plugins simultaneously.
Atomic component library
Base atoms → molecules → organisms, all connected to tokens. Every component variant tested at all breakpoints before plugin redesigns began.
Unified Figma Variables
Single library file. One variable change cascades to every plugin frame — no more per-plugin manual updates or style drift.
Design-to-code handoff system
Token names matched 1:1 to SvelteKit CSS custom properties. Zero translation layer between design and production implementation.
Hypothesis confirmed — onboarding drop-off fell 43% and support tickets citing UI confusion dropped within 4 weeks of the SUI 3 rollout.
Onboarding drop-off measured across new free-tier installs in the 8 weeks post-SUI 3 rollout compared to the same period prior year.
Next Chapter
Smush
Image optimization — Ultra, Lossy, and Lossless compression at scale.
Image Optimization
Smarter. Every time.
Pro-exclusive Ultra tier. Lossy and Lossless stay free — always.
Already-optimized images get a second look on every update.
If a better algorithm exists, Smush finds it automatically.
Ultra delivers 5× the file reduction of Lossy — for sites where every kilobyte matters. Lossy and Lossless remain free because not every site needs the maximum.
The library rescans on every plugin update. Better algorithms get applied retroactively — without any user action required.
01 // Smush · Original Userflow
02 // Smush · SUI 3 Redesign
Images were compressed.
Just not compressed enough.
"It said everything was optimized. I tried rescan on a whim and it found 200+ images with another 38% to save. I had no idea.
Community thread · WordPress.org · Smush reviews
avg file reduction with Lossy on large images — industry benchmark is 60–80%
Compression ceilingsupport pattern: "Smush ran but my images are still large"
Trust gappreviously optimized images re-checked after algorithm updates — stale library by default
Stale libraryguidance on which tier to pick — users chose Lossy by default unaware Ultra could save 5× more
No guidanceemail digest, background toggle, and onboarding guide were absent in v2
Feature gapevery re-optimisation required user-initiated action — no set-and-forget capability
Manual overheadIntroducing Ultra (5× compression), auto-rescan, an onboarding tier guide, and email reports would break through the 4–5% ceiling — and give users confidence the library was always at its best without manual effort.
Ultra tier · New, Pro-exclusive
5× better reduction than Lossy. Tested on 10–20 MB images across all color profiles and image types. Lossy and Lossless remain free.
Auto-rescan library
Re-checks every image after algorithm updates. Better compression applied retroactively — no user action needed.
Compression tier guide
Inline comparison of Ultra, Lossy, and Lossless with plain-language guidance. Pick once, Smush handles the rest.
Email reports + background toggle
Compression digest sent to admin after each run. Toggle to control when background jobs run — set it and forget it.
Hypothesis confirmed — Ultra adoption hit 34% of Pro users in the first month. "Still large" support tickets dropped significantly after rescan shipped.
Ultra tested on a large dataset of 10–20 MB images with full color profile variation across all supported image types.
Next Chapter
Hummingbird
Speed & performance optimization — Critical CSS, JS Defer, and Asset compression.
Performance Optimization
Critical. Fast. Clean.
Measured across 20+ live WordPress deployments with varied plugin stacks.
Faster page renders via Critical CSS generation and JS Defer automation.
Users were confused about which optimizations were active. We redesigned Hummingbird to show live status inline with every feature — Critical CSS, Delay JS, Asset Optimization — so the interface answers the question before anyone thinks to ask it.
Progressive disclosure kept power features accessible without overwhelming beginners. The new SUI 3 Atomic components unified every setting panel with a consistent visual language.
Users weren't failing at optimization.
They were failing at trust.
"I set it up, it said done, but pages were still slow. I turned everything off thinking it wasn't working.
User 4 · Session recording · Hummingbird beta
couldn't confirm optimization was active post-setup
Visibility gapsupport category: "is this even working?" before inline status
Trust failuresession users disabled features they thought were broken
False negativeavg time wasted re-checking already-configured settings
Wasted effortonly had CSS Minify + basic JS toggle — no Critical CSS, no JS Defer
Capability gapvisual difference between "optimizing" and "idle" states in v2
State clarityMaking status visible inline — and shipping Critical CSS + JS Defer as default-on replacements for CSS Minify and the basic JS toggle — would eliminate the trust gap and reduce the support burden.
Inline status on every control
Critical CSS generation state, JS Defer exclusion counts, compression ratios — surfaced next to each control, always visible.
Critical CSS · New, default on
Replaced CSS Minify. Auto-generates above-the-fold styles. Enabled by default for all new installs.
JS Defer · New, default on
Replaced basic JS optimization. Safe script deferral with built-in exclusion logic from day one.
Progressive disclosure
Clean surface for beginners. Full control accessible one level deeper for power users.
Hypothesis confirmed — "not working" tickets dropped 42%. Users stopped disabling active features within 2 weeks of launch.
Measured across 20+ live WordPress deployments with varied plugin stacks.
01 // Figma Design · CSS Info & Tags
02 // Live Beta · Critical CSS SUI 2
Next Chapter
Snapshot
Backup & restore — Scheduled backups, selective restore, and cloud storage.
Backup & Restore
Backup all. Restore one.
Reliable scheduled backups across all connected WordPress sites.
Restore only what broke — database, files, or both. One click, no technical decisions. Critical for low-storage sites.
Snapshot removed the anxiety from site maintenance. Selective restore, backup composition badges, and two new cloud destinations — Backblaze and OneDrive — gave users control they didn't have before.
SUI 3 email alerts and in-dashboard notifications mean you know the moment a backup succeeds or fails — not when disaster strikes.
Backups felt like
a developer task.
"Users were unsure if their backups had run, where files were stored, or how to trigger a restore. Critical status was buried behind technical jargon and nested screens.
User research · WPMU DEV user survey · pre-Snapshot 4.10
of restores were all-or-nothing — no scope selector. 67% of users who needed only a DB fix restored the entire site, risking content overwrites.
No granularityvisibility into backup composition — users could not see whether files, database, or both were captured in a given backup entry.
Hidden compositioncloud destination supported (Amazon S3 only) — no Backblaze or OneDrive, locking out users on non-AWS stacks or with existing OneDrive licences.
Destination lock-inbackup failures — no in-app notification, no email. Users discovered failures only during a disaster restore, not when the job ran.
Silent failuresto confirm restore scope — users navigated four screens before seeing what would be restored. High abandonment before commit.
Restore UX frictionverification required post-backup — no badge, no confirmation detail. Users had to open individual backups to confirm what was saved.
No post-backup proofStatus visible at a glance. Restore in one action. Selective scope (DB · Files · Both), backup composition badges, Backblaze + OneDrive destinations, and SUI 3 email alerts — no multi-step wizard, no technical decisions. Users know exactly what ran, what was saved, and where.
Selective restore engine
Full site, database only, or files only — chosen upfront before any restore is initiated. Low-storage sites can target just the DB without touching the file system.
Backup composition badges
Every backup entry shows a DB · Files · Both indicator. Know what was captured at a glance — no need to open the detail view to verify.
Backblaze B2 + Microsoft OneDrive
Two new cloud destinations alongside existing options. Backblaze for cost-efficient object storage; OneDrive for teams already in the Microsoft 365 stack.
SUI 3 notifications + email alerts
In-dashboard notification and a branded email on every backup event — success or failure. Designed with SUI 3 components for full visual consistency across WPMU DEV plugins.
Hypothesis confirmed — selective restore reduced abandoned mid-restore sessions by 67%. Users on low-storage sites could target just the database, avoiding the file system entirely.
Restore abandonment measured across Snapshot beta users in the 6 weeks post-4.10.0-beta rollout. Abandoned restore = user-initiated restore that exited before completion without reaching a confirmed clean state.
What I Owned.
SUI 3 Atomic Design System
Token architecture, component library, monochrome mode for white-label use. Every plugin in the suite was built on this foundation.
Smush Compression Flow
Reduced the core flow from 7 steps to 4. Led every Maze test and synthesised findings into the shipped design.
Snapshot Restore UX
Scoped selection redesign (DB · Files · Both) — eliminated the top support ticket category within the first quarter post-launch.
Hummingbird Onboarding
Led Figma system and interaction design. Product defined the performance metric triggers and threshold logic.
SmartCrawl & Beehive
Mapped to SUI 3 tokens and audited for inconsistencies. Full redesign scoped for a subsequent phase beyond my tenure.
What I'd Do Differently.
Snapshot Restore Modal
I'd have run a second Maze test before shipping. The first round showed clear improvement — but users were still over-reading the "Selective Restore" options before committing. A follow-up test would have told me whether the bottleneck was copy or information architecture. I shipped the first iteration and moved on to Hummingbird. That's the call I'd revisit.
Token Governance
SUI 3 scaled across six plugins with no formal deprecation protocol. Old alias tokens persisted in legacy components longer than they should — visible in the visual gap between fully updated and partially updated plugin screens. A token governance doc from day one would have prevented that drift.