Enable / 2026

The front door and the first mile

Designing authentication and data onboarding for Enable Edge, an AI-native rebate platform, in production-grade code.

Role

Senior Product Designer

Surfaces I owned

SSO and passwordless login, data onboarding

Timeline

Mar 2026 to ongoing

Status

R1 pilot, Aug 2026

Enable Edge sign-in screen, an Auth0 Universal Login replica themed with Enable's branding — The front door: Edge's sign-in screen, designed as a faithful reconstruction of Auth0's Universal Login, themed with Enable's brand.

In short

Context.Enable Edge is the company's next-generation, AI-native commercial intelligence platform, launching as a rebate optimization product with a customer pilot in August 2026. I'm a Senior Product Designer on it.
My role. I led the design of two foundational surfaces, how you get into Edge (SSO and passwordless login) and how your data gets in (data management and first-time onboarding), and shaped decisions across the wider navigation rebuild, working closely with PM and our auth engineer.
What I did.Reconstructed Auth0's Universal Login as a themed, faithful, end-to-end coded prototype; designed a provider-row login-methods admin; and ran the first-time-login research that reshaped onboarding. I prototyped it in real React: 409 commits, the largest human contribution to our prototype repo.
The senior bit. Prototyping it in code, not mocking it, is what surfaced the decisions that matter: lockout-safety guards, provider-accurate failures, and an information architecture that keeps authentication legible.
Honest impact.The pilot is still ahead of us, so there are no post-launch numbers yet. What's real today: research I authored that changed the product, a prototype adopted as the team's primary design reference, and design that fed engineering's foundation.

(1)

Context & my role

Enable sells rebate-management products to manufacturers and distributors. Edge is the bet on what comes next: a margin-intelligence layer that moves customers “from seeing margin to getting ahead of it.” It's deliberately AI-native: a persistent agent (“Ask Edge”), conversational task flows, and recommendations the system has to explain to be trusted.

A product like that lives or dies on two things most demos skip: whether enterprise buyers can actually get in, and whether their data can actually get in. Those are the two surfaces I owned. The wider shell (the new sidebar, the page-aware breadcrumb, the “New Task” landing, and user-composed “Spaces”) was a team effort; a design peer led the navigation concept and the portfolio side, and on the portfolio first-time-login flow I was explicitly supporting, not leading. I'm precise about that because the work I did own stands on its own: SSO and passwordless, the data-admin first-time login, the data-management hub, permissions, navigation and branding rework, and the combined end-to-end prototype.

Timeline: I spun up the dedicated design workstream in March 2026, ran first-time-login research at the end of April, and built the Auth0-faithful SSO prototype in June. The R1 pilot lands in August 2026.

The Edge app shell (team-led navigation rebuild). I owned data management inside it; a design peer led the navigation concept. The page-aware breadcrumb replaced the old top bar, a direct response to research.

(2)

The problem & why it mattered

Two problems, one theme: trust at the threshold.

Getting in. Enterprise customers treat SSO as a procurement non-negotiable. Our own PRD says it plainly:

“We have previously failed due diligence with larger prospects on the old platform because of SSO limitations.”

Edge's launch success criteria name “SSO + RBAC functional” as an explicit enterprise-readiness gate. The strategic decision was already made: no username and password, ever (owning a password database is liability we don't want), with Auth0 underneath both SSO and a passwordless fallback. Okta, Microsoft Entra ID, and Google Workspace at launch.

Getting data in. The other threshold is the first session after login. When a data administrator signs into a brand-new tenant, there's zero data and no guidance, and as the onboarding PRD warns, “if this user stalls, the entire organisation's onboarding stalls.”For a platform whose pitch is “clean data in, your highest margin out,” the onboarding mile is the product.

Neither problem is glamorous. Both are where enterprise deals quietly die.

(3)

Research & insights

I came at this from two studies, and the research is where the senior signal is clearest, because of what changed as a result.

Study 01

Portfolio round-1 usability (April 2026)

Across four customer organisations the prototype averaged 4.6/7. The throughline was legibility: an AI text panel explaining a recommendation lost, every time, to a simple visual of the old tier structure beside the new one.

A category manager: “reading that blurb does not tell me; visually it was easier to see it.”
A finance lead: “I’m in accounting, I really like to tie things out; I’d feel better if it would show its work.”

That became the principle I carried into the auth and data work: show your work, don’t narrate it. (A mock-data arithmetic error, 120 minus 45 shown as 117, was caught live in three separate sessions and dented credibility: on a financial tool the numbers are the trust.) WSH’s commercial finance lead called the missing back button “one of our biggest flaws with Enable,” which is why the rebuilt navigation makes a page-aware breadcrumb table stakes.

Study 02

First-time-login usability (Apr 30 to May 6, 2026)

This one I owned end to end: I wrote the study, co-moderated it with our PM, and authored the synthesis. Three sessions, four internal proxies, average self-serve confidence about 3.75/5. The headline finding was uncomfortable and useful: the flow worked at the layout level but the language didn’t.

“Data type” read as a SQL field type, “is it a string, is it an integer?”, not a logical dataset.
Customers won’t pre-clean data: “they just do not like to fix their data before sending it into Enable.”
And the agent, in prime real estate, was distrusted: “I probably focus more on that than the chatbot… it gives you crap responses.”

What changed is concrete: I fed the findings straight into the prototype, renaming “data type” to “dataset” throughout, adding inline glossary triggers, surfacing file size and type limits at upload, promoting the required dataset names above the upload call-to-action, and adding row-level error messages. Research that doesn’t move pixels isn’t research; this did.

(4)

Constraints & strategy

The strongest constraint was also the most clarifying: Auth0 was already there.My job wasn't to invent auth, it was to design the human-facing layer on an existing technical reality. That produced the central principle for the SSO work: faithful reconstruction. Edge doesn't host its login page, Auth0 does, so I designed the sign-in screen as a replica of Auth0 Universal Login as it actually renders with Enable's branding theme: the layout and structure are Auth0's, the colours, fonts and borders are Enable's. Designing to the grain of the real system, and flagging every value that wasn't genuinely Enable's, kept the prototype honest about what engineering could ship.

The second strategic call was the admin surface, how a customer's IT team turns SSO on. The conventional answer is a wizard. I rejected it.

Login methods admin showing the three identity providers as always-visible rows rather than a wizard — Login-methods admin: the three providers are always-visible rows, not a wizard. “Set up” opens that provider's own one-page setup; configured connections get a “Manage” page for status, audit, test and actions.

A hard boundary went with it: authentication admin must not absorb user management.Managing people belongs in user settings, so “Manage people” is a deliberate dead-end until that surface exists. Keeping the auth admin about connections, not people, is what keeps it comprehensible.

(5)

Process & explorations: the messy middle

The provider-row pattern wasn't my first idea. I built the setup as a stepper and wizard first, and it broke against reality: the stepper overflowed the narrow settings pane. The commit history is the honest record, a fix to “setup stepper overflow,” then the rework: “Rework Login methods IA: provider rows, per-provider pages, sticky chrome.”The wizard's failure in the actual pane produced the better IA. That's the argument for prototyping in code, in one commit.

The data-onboarding surface forced its own forks. The first-time-login research showed the agent in the homepage's prime real estate was actively distrusted, so rather than lean harder into it I demoted it: the agent earns its place once it has a defined task, and the zero-data homepage leads with the data work instead. And I chose a two-gate readiness model over a single “onboarding complete” bar (foundational entity data opens the portfolio wizard; transactional and earnings data lets it actually run) because customers upload incrementally over days, and one bar would either lie or block them.

In parallel I drove the rebrand groundwork the login surface needed: a neutral-forward shift of the primary colour, 258 component rebinds across 77 component sets, moving eight semantic tokens off brand green while reserving green for identity (and keeping “Completed” a success state, not a brand accent). The login page is one of the most brand-sensitive surfaces in the product; the token story had to be right there.

(6)

The solution

The sign-in flow reads as a single, quiet sequence: identifier-first, routed by tenant config to either an SSO redirect or a passwordless one-time code, through a designed callback, to a successful landing.

Email-first authentication routing: one sign-in screen routes by tenant config to either an SSO redirect or a passwordless one-time code, both on Auth0, converging on an authenticated landing — Email-first routing: one screen splits to an SSO redirect (Okta, Entra, Google) or a passwordless code, both on Auth0. The side panel captures the admin-lifecycle decisions the coded prototype surfaced: enabled-but-unverified, verify-by-real-sign-in, and the “last way in” guard.

SSO redirect interstitial handing off to the customer's identity provider — The SSO route: a designed redirect interstitial handing off to the customer's IdP.

Passwordless one-time-code verification screen for customers without an identity provider — The passwordless route: a one-time email code for customers without an IdP.

Every identity provider gets a faithful page, and the admin side carries its full set of real states: new tenant, one IdP live, all live, set-up-but-not-tested, SSO-required, plus verified and failed banners, with per-provider setup, edit and manage. Crucially, I designed the system, not just the screens.

The Connection Row component shown across five states: not set up, live, off, not tested, and test failed — The provider row that replaced the wizard, as a single reusable component with five states (not set up, live, off, not tested, test failed).

(7)

Designing in code: the prototype

I built this in real React (Vite, Vanilla Extract, React Aria) rather than clickable mocks, and that's where the seniority shows. The flagship commit alone is 29 files, +4,522 and -477 lines: a complete auth module plus the entire login-methods admin. A later commit is nothing but a copy assessment, “voice, clarity, trust, naming,” because I own the words as much as the layout.

Three things only emerged because the thing actually ran:

Provider-accurate failure.

A failed connection test shows the provider’s real code, Entra’s AADSTS90002, Okta’s unreachable_org, Google’s Error 403: org_internal, not a generic error. You only design those well once you’ve wired the real failure paths.

The “last way in.”

Building the enable, disable and remove flows in code made an entire class of edge case obvious: a tenant admin must never be able to turn off or remove their last working way in. So there are explicit lockout-safety confirmations for exactly that, a guard the running build surfaced, not the happy-path mock.

Verified-but-unverified state.

A connection is created enabled but unverified, and never appears on the live sign-in page until it passes a real sign-in round-trip; a failed test auto-disables it. That state only matters once you model the real lifecycle.

A confirmation guard preventing an admin from turning off the last remaining sign-in method — The “last way in” guard: a lockout-safety confirmation the running prototype surfaced, that a static happy-path mock never would.

The login-methods admin running live inside the real Edge app shell, with single sign-on on and passwordless email codes active — Not a mock: the login-methods admin captured from the running prototype on localhost:5188. Provider rows inside the real Edge shell, SSO on, passwordless active, and the “go to user settings” dead-end that keeps auth admin about connections, not people.

The prototype is preserved as a restorable build, runnable on localhost:5188, including the work in progress. It isn't a dead screenshot.

(8)

Craft details & edge cases

The edge cases are designed, not deferred: no-connection, invalid-email and provider-failure errors; OTP wrong-code and resend; governance variants where email codes are disabled at org or account level; and the destructive-action confirmations. The handoff itself is an artifact.

A state-coverage matrix enumerating every screen state designed for the sign-in and admin flows — A state-coverage matrix proving every state was designed, not left to engineering to invent.

Provider logo and trademark legal flags carried into engineering. Microsoft, Okta and Google marks are a compliance minefield, so the rules travel with the design.

I wrote a dedicated provider logo and trademark rules document and encoded the constraints directly into the components and the handoff, so brand and legal rules travel with the design rather than being discovered in review. Accessibility was built in at the primitive level: the auth module is built on React Aria's accessible components, including its live-announcer, so the async states (redirecting, signing-in, verifying) are announced, not silent. I added an inverse focus ring at #FFFFFF for the dark themed surfaces and fixed callout contrast where tertiary actions disappeared on grey fills.

The component library I built

A documented set of variants with their states enumerated: Provider Mark, Identifier and OTP fields, the IdP and Primary buttons, inline banners, the spinner stack, the error panel, the connection row, and the status chip. I designed the system, not just the screens.

The Provider Mark component with variants for Microsoft, Okta, Google, and Enable — Provider Mark: logo-compliance rules encoded as component variants.

The Primary Button component across default, hover, focus, disabled, and loading states — Primary Button: interactive-state rigor down to the button.

The Error Panel component across provider, access-denied, and generic variants — Error Panel: the error taxonomy that handles failures gracefully.

The Status Chip component showing all of its states — Status Chip: one shared status vocabulary across the admin.

Outcome & impact

I'll be straight: the R1 pilot starts in August 2026, so there are no post-launch metrics yet, and I won't invent any. The PRD targets (SSO live in under five business days, over 99% login success) are goals, not results. What's genuinely true today:

Research I owned changed the product.The first-time-login study I wrote and co-moderated produced a specific, actioned set of changes in the canonical prototype: the “data type” to “dataset” rename, glossary triggers, error specificity. The onboarding PRD names my prototype “the primary design reference for this feature.” This one is wholly mine.
The prototype is the team's source of truth. The combined end-to-end prototype is the artifact used for PM and dev alignment sessions and stakeholder demos.
Design informed shipped engineering,by the design and engineering ticket trail rather than my own production commits (I design and build the prototype; engineers take it the rest of the way to the shipping app). The base user, permissions and audit-log areas of the customer app are built and marked done in engineering's tracker.
Team context, not my personal credit:after the broader Edge customer-demo programme, which included the data-onboarding flow I own, a UK customer converted from a research conversation into a pilot. That was driven by the product's overall value prop (the portfolio and agent side led by a design peer), not my surfaces specifically.
Scale of contribution.409 commits to the prototype repo, the largest human contribution, is itself evidence of how much of this product's interaction detail I carried.

Reflection

The hardest problem wasn't a screen; it was sequencing across three functions. In my words: “making sure engineering, product and design know when things are going to be built, and we have the right pipeline and roadmap.”My answer was to make the coded prototype and a rigorous handoff (Definition of Done, state matrix, “Ready for Dev”) the shared source of truth, so the three functions argue about one concrete thing instead of three mental models. It's why the staged navigation decision, interim top-bar now and finalised side-nav later, gated by a design review before engineering builds, was the right call rather than a compromise.

If I did it again, I'd push the first-time-login research earlier and with real customers rather than internal proxies, which the synthesis recommends. And I'd keep doing the thing that worked: designing the front door and the first mile in real code, where the lockout guards and the provider errors and the awkward empty states stop being someone else's problem and become the design.

What's next: the August 2026 pilot, self-service SSO configuration for customer admins, and just-in-time provisioning.

Next Project

Ledn

Ledn Transfer

→