Springer Nature · Identity Team
Designing failure as a first-class experience
The first cross platform error messaging framework for an identity suite used by millions of researchers globally.
audited & redesigned
auth · linking · account flows
for all auth errors
collaborators
At a glance
Identity flows used by millions of researchers had no error strategy. Messages were written ad hoc by developers, with no shared structure and no way out of a failure.
Audited every error state across the identity journeys, then built the framework, the content system, and the reusable components handed to the design system team.
- Agreed the success metrics with the Product Owner before proposing anything, which kept the work measurable instead of a content polish.
- Fixed one message structure, what happened plus why plus what to do next, so any team could write an error without guessing.
- Treated the drift from the design system as part of the same problem, and rebuilt the authentication screens rather than patching copy on top.
The first cross platform error messaging framework for the identity suite, shipped across the authentication journeys and credited with cutting drop off in auth flows. I changed roles before the full validation data landed, so the figures in the strip above are scope rather than measured result.
Context & Challenge
Millions of users, zero error strategy.
Identity flows power access, registration, and account management for millions of users at Springer Nature. When they fail, people drop off or call support.
One area had been consistently overlooked: error handling. Messages were written ad hoc by developers. No framework, no consistency, no recovery paths. Users hit a wall with no idea what happened or what to do next.
Why this work mattered
Access to research
Errors block access to research. High intent users fail at the moment that matters most.
Account abandonment
Users who fail at registration do not retry. Every dead end is a lost account.
Support costs
Unclear errors generate tickets. Every message without a next step becomes a support call.
User trust
Technical jargon and inconsistent tone erode confidence in the platform itself.
Scope of Ownership
Discovery
This wasn't a content problem.
I audited the error states across the identity journeys and mapped trigger, UI pattern, severity, and recovery gap for each one. What surfaced went well beyond wording.
What the audit uncovered
Solution
A scalable error handling framework.
Before proposing anything I agreed success metrics with the Product Owner: error frequency, form abandonment, recovery rate, and support ticket volume. That tied the work to outcomes from the start, and it is the reason this was never treated as a copy exercise.
Tone matched to context
| Scenario | Directive | Neutral | Empathetic |
|---|---|---|---|
| Empty field | Please fill out this field to continue. | This field is required. | Looks like this one was missed. |
| Server error | Try again in a few minutes or contact support. | We're unable to process your request right now. | Something went wrong on our end. We're on it. |
| Login failure | Check your email and password, then try again. | We couldn't log you in. | That didn't work. Let's try again. |
Guidelines established
Error UI Components
Clear rules for when to use inline validation, in-page banners, or full page error states.
Illustration Usage
When illustrations add value (empty states, major errors) and when they distract from the message.
Dismissible Banners
When banners should be dismissible, when they shouldn't, and how to handle user dismissal.
Multiple Banners
How multiple error messages coexist on one page. Priority, visual hierarchy, and stacking rules.
Visual Consistency
Standardised colours, icons, font styles, and message tone across all error states.
Prevention Patterns
Opportunities to catch issues before they become errors. Inline guidance, pre-checks, and smart defaults.
Transformation
From dead ends to guided flows.
The biggest shift was not better words. It was turning passive errors into active recovery, so every dead end became a decision point.
Collaboration
Built with the team, not in isolation.
This was not a solo exercise. Product prioritised by frequency and support impact, QA surfaced real scenarios, engineers flagged constraints, and Content Design refined the tone.
Realigning with the Design System
The audit showed that many authentication flows had drifted from the design system, so I used the work to realign forms, components, and layouts, adding patterns where they were missing. The error handling did not ship as isolated fixes. It shipped inside authentication journeys that finally represented the brand consistently.
Outcome
What we shipped
The framework shipped across the identity suite with tracking in place from day one, and it cut drop off in the auth flows. I changed roles before the full validation set came in, so what follows is what shipped rather than a final measured result.
Learnings
What I carried forward
Errors are core journeys, not edge cases
A confusing error seen by a million users is a million moments of frustration. Treat error states with the same care as success states.
Good UX is recovery design
What happens when things break is where trust is built or lost.
Systems thinking scales
A framework any team can apply beats a one-off redesign. This didn't fix 16 errors. It gave the team a way to handle every future error consistently.
Measure before you design
Defining success metrics before proposing solutions made the work defensible. Without that, this would have been seen as a content polish.
Designing for failure isn't about handling errors. It's about making sure users can still succeed.