Prospects call the member portal outdated — and it cost named deals. We drove the live portal, captured every screen, and traced the look back to its root cause. Here's what's actually wrong and the safe path to fix it.
The "outdated / broken" perception is dominated by design-token and component issues — empty-state badges, unstyled dropdowns, dated chrome — that we can fix without touching the markup your customers' custom CSS/JS depends on. The underlying structure (sidebar + cards + a real settings form) is sound and already close to the bettermode model.
A designer's-eye rating per screen. These are the baselines we measure the redesign against — the goal for Phase 1 screens is +3 or ≥8/10.
App Insights, 30 days, all orgs. Bar = share of portal page views. Color = current design score (red = worst). High traffic + low quality = fix first.
Search + Profile + Feed carry the majority of member eyeballs. Top 5 ≈ 67%. Fix these and the global token layer, and most members feel the change.
Search is the #1 page and was missed in the first pass. Messages is only 3% — not a Phase-1 priority. Profile being #2 AND worst-scoring confirms it as the anchor.
* Membership = create + view combined. Counts aggregate all orgs and may include bot/monitoring traffic; client_IP is anonymized so per-user dedup wasn't possible. Directional, not exact — a GA4 engaged-sessions cross-check would tighten it.
On Profile and Payments, empty fields render as red No Records / Missing / No data badges. The most-viewed member screen looks broken and error-filled when the data is simply empty. Biggest perceived-quality jump per hour: swap red alarms for neutral "Add your work history" prompts.
A yellow contact callout fights the white cards; Payments is four oversized cards each holding one line of "No Records" — vast dead space. One consistent surface + card system with a real type scale fixes the "empty and unfinished" feel.
Note: an earlier draft flagged a "dual nav." That dark icon rail is the admin panel, only visible to org admins — members never see it. Retracted.
Raw browser <select> menus (events filter, settings) are the loudest "unfinished" signal. Badges mix outline and solid pills; surfaces clash (a yellow contact callout against white cards). One consistent component set fixes all of it.
Flat pale-blue bars, hard 1px card borders, 2013-era link blue, weak type scale, oversized blocky headers, and large dead-space gaps. This is the framework's 2013 default aesthetic — exactly what reads as "old."
Captured headless against the live portal. Annotations call out the specific issues.
Customers write their own CSS/JS that targets the portal's markup. The HTML is effectively an unversioned public API — change a class name or DOM nesting and you silently break paying customers.
Change appearance only: Bootstrap variable overrides, a modern token layer, restyled components via existing selectors. DOM + class names frozen → customer code keeps working.
A Bootstrap 3→5 jump renames classes and restructures DOM — it breaks the contract. Only safe once a versioned component layer + customer migration path exist.
Phase 1 ships to the 99.3% with zero custom-code risk today. The heavy customizers (brotherspubcoclub 474k, Eureka 164k, timothyoulton 142k CSS; craftsavvy 102k, wms 80k, isssic 69k JS) get grandfathered onto the current theme via a per-org flag. No versioning system needed to start — the scariest unknown is now a 30-row list.
Each phase earns the right to the next. Ship value and recapture deals early; defer the risky structural work until it's de-risked.
Pull the list of paying orgs that ship custom portal CSS/JS and the selectors they depend on. That single data pull turns the scariest unknown — the markup contract — into a bounded, known constraint, and tells us how aggressively Phase 1 can move. In parallel: name the 2–3 deals that cited the look, so we can re-test them after the refresh.