Repfabric
De-scoping a 20-role, 12-module CRM/ERP into a focused, AI-ready system for the one persona who actually buys it.
📌 The Real Pain
A CRM built for every role, understood by none of them
Repfabric arrived as an already-live, fully built cloud-based CRM/ERP platform — every workflow existed, but the product had accumulated functionality for years without ever being re-scoped around who actually buys and uses it. The client, founder John Mitchell, brought me in to audit the existing information architecture and map the real workflow through stakeholder workshops across sales and ops, before touching a single screen.
❌A dated visual system that hadn't kept pace with the product's growth
❌~20 distinct roles coexisting in one interface, each with its own configuration surface
❌Most of the platform's functionality unused by the persona who actually drives the sale — manufacturers' sales reps
❌A backend team already mid-build on "the future of the CRM," creating constant risk of shipping designs that would break work already in flight
Before
–12 functional modules serving ~20 mapped roles inside a single, undifferentiated interface.
–Configuration and data model already deeply established — any redesign had to preserve it, not replace it.
–Design proposals converged slowly: workflow reality and backend feasibility routinely pulled in different directions.
After
✓A single, deliberately scoped experience built around the sales rep — the platform's real buyer — without discarding the underlying multi-role data model.
✓~85% of legacy functionality removed; 12 modules consolidated into 3-4 core ones (Dashboard, Sales, Opportunities, Settings).
✓A new design system and brand book, plus a dedicated decision-history screen giving every major action a visible, auditable trail.
Product Foresight & Constraints
This was never a greenfield redesign. Every proposal had to survive three constraints at once: the real workflow the client's team actually ran, the feasibility of the current backend and its infrastructure coupling, and an explicit mandate not to break a parallel effort already bringing the CRM toward a future, AI-integrated direction — the discipline of designing inside those guardrails shaped every decision. The paradox: what shipped looks simple to the end user. What it took to get there — reconciling 20 roles' worth of legacy behavior against a live backend under active construction — was not.
Selected Impact
✓Scoped 20 mapped roles down to the 1 persona that actually drives platform adoption and revenue — the manufacturers' sales rep.
✓Removed ~85% of legacy functionality, consolidating 12 modules into 3-4 core ones, without losing existing configured data.
✓Shipped 3 major iterations (V1 → V2 → V3) over 12+ months of near-daily collaboration directly with the founder.
✓Extended the redesign across two purpose-built platforms — desktop/web and mobile — designed for genuinely different contexts of use, not just responsive breakpoints.
🤔 Hypothesis
If we mapped the full multi-role workflow first and then deliberately scoped the product around its one real buyer persona, we could cut complexity dramatically without losing the underlying data or breaking a live backend build.
🗺️ Users & Workflows
One persona, fully redesigned — a broader ecosystem, respectedThe workflow mapping surfaced ~20 roles across the CRM/ERP. The client made a deliberate call to focus the redesign on the one role that actually buys and drives adoption of the platform, while keeping the broader ecosystem's data model intact underneath it.
Sales Rep (primary focus)
Owns the full cycle: prospecting and conversion, then opportunities. Within a role-based permissions model, routes a closed deal to manufacturer, transporter, and installer. Frequently manages a sub-agent/resale pattern — buying on behalf of a customer and routing fulfillment to that customer's address.
Manufacturer / Distributor / Installer
Receive handoffs generated by the sales rep's opportunity workflow; not redesigned directly, but the data model and Salesforce-mapped integration were designed to keep them in sync.
Founder / Product Owner (John Mitchell)
Reviewed and approved or rejected every design proposal in near-daily working sessions, embedded from discovery through delivery.
🧠 Strategy
From a 20-role CRM to a 1-persona system of actionWe shifted from a platform trying to serve every mapped role equally to one built deliberately around its highest-value user, without losing the data other roles still depend on.
Scope to the real buyer
Design for the persona who drives adoption and revenue, not every role a legacy system accumulated
Preserve the data, cut the surface
Removing functionality doesn't mean removing the underlying configuration other roles depend on
Feasibility is a design input
Backend coupling and infrastructure constraints shape decisions as much as user needs do
Make decisions visible
Every major action gets a traceable, auditable record
✨ Solution Snapshot
Funnel 20 roles to 1 persona
Concentrate design effort on the role that actually buys and drives adoption
Cut ~85% of legacy functionality
Remove complexity the target persona never used, without discarding configured data
New design system & brand book
Replace a dated visual language that hadn't kept pace with the product
Decision-history screen
Give every key action a visible, auditable trail — human-in-the-loop by design
Two purpose-built platforms
Match desktop (office, tracking, webhooks) and mobile (field visits, voice-to-text) to how reps actually work
How I made key design decisions
Every decision here had to satisfy three constraints simultaneously — workflow reality, backend feasibility, and "don't break what's already being built."
Funnel to one persona, then cut ~85% of functionality
Serving every role equally kept the product unusable for its actual buyer. Through Service Blueprint and journey mapping work, I made the case for scoping to the sales rep, then wireframed and prototyped the narrowed flow and validated it through usability testing and near-daily stakeholder reviews with the founder — stripping the interface to that role's core loop: sell, then hand off.
New design system vs. patch the existing one
The legacy visual language couldn't carry a scoped, modern experience. I partnered with engineering on a migration to a new design library and brand book rather than layering fixes on the old one.
Two distinct platforms vs. one responsive design
Desktop use (in-office, client calls, shipment tracking via webhooks) and mobile use (field visits, voice-to-text call logging) are different jobs, not different screen sizes. I designed them as two purpose-built experiences sharing the same underlying model.
Decision-history screen (V3) vs. no formal audit trail
By the third iteration, the founder needed a single place to see what decisions had already been made and why. I designed a dedicated screen surfacing that history — the same human-in-the-loop instinct that shows up across my other AI-native work.
📈 Outcome
✓Delivered a CRM experience the sales rep actually adopted, validated through 3 major iterations and near-daily reviews directly with the founder.
✓Preserved the existing configured data and multi-role model while radically narrowing the active surface area.
✓Kept a live backend build from breaking across 3 major iterations, by treating feasibility as a design constraint from day one.
✓Extended the same scoped model across desktop and mobile, plus a designed Salesforce data-sync mapping.
💡 What I Learned
Perceived simplicity can hide real complexity
The finished product felt lightweight to use; the construction behind it — multi-role legacy plus backend feasibility — was not.
Scoping is a design decision, not a shortcut
Deciding who not to design for was the highest-leverage call on this project.
Feasibility constraints sharpen design
Designing around "don't break the backend" produced a more disciplined, iteration-tested product than an unconstrained rebuild would have.
Domain-expert clients change the process
Near-daily reviews with a founder who knew the platform end-to-end meant every proposal had to be defensible, not just plausible.
Closing
Repfabric shows how I approach ambiguity at its most extreme: a live, feature-bloated multi-role platform, a backend under active parallel construction, and a client who could evaluate every pixel against years of domain expertise. The result wasn't a bigger product — it was a dramatically smaller, more defensible one, scoped around the person who actually buys it.