Rodney Echols
About
Work
Let's Chat
RECOGNITION ENGINE
Fixing What Passengers Never See
A behind-the-scenes system for surfacing loyalty status, rebooking priority, and service recovery context - so frontline staff can make the right call in seconds, not minutes.
ROLE
Staff Product Designer
TIMELINE
6 weeks · 2025
CLIENT
Regional Airline, Confidential
DELIVERABLE
Recognition engine, UX spec
MY ROLE
01 Mapped frontline recognition moments across check-in, gate, and inflight touchpoints
02 Interviewed gate agents, flight attendants, and service recovery staff
03 Designed the recognition engine's information architecture and decision logic
04 Built the UX spec and flows handed to engineering for implementation
05 Partnered with ops leadership on rollout sequencing and staff training
06 Defined success metrics with analytics to evaluate post-launch impact
NOT MINE
PLATFORM SELECTION
Which loyalty, rebooking, and CRM systems the recognition engine would read from was decided by IT and ops leadership before this project began. That integration layer was out of scope for this engagement - the work here focused entirely on how frontline staff see and act on the information once it surfaces.
Context
Frontline staff at the gate, check-in counter, and onboard had no shared view of who a passenger was or what they were owed in the moment. A platinum flier's rebooking priority, a complaint history that called for extra care, a connection at risk - all of it lived in separate systems, or in no system at all, leaving recognition and recovery entirely up to memory and tenure.
The cost showed up as inconsistent service: the same passenger treated differently depending on which agent they happened to get, and service recovery moments that needed judgment calls staff weren't equipped to make quickly under pressure.
This project set out to surface the right context, at the right moment, to the person standing in front of the passenger - without adding another system for staff to dig through.
IMAGE PLACEHOLDER
Before/after: existing gate-agent workflow vs. the recognition engine surfacing status, priority, and service context at the gate
Decisions & trade-offs
01 Recognition surfaces at the point of contact, not buried in a back-office dashboard. Staff see status, priority, and context in the same screen they already use to check someone in.
02 The system recommends, it doesn't decide. Final judgment calls stay with the agent - the engine surfaces relevant context, not a prescribed action, so staff retain ownership of the interaction.
03 Built for the busiest moments, not the average ones. The interface was designed and tested against irregular operations - delays, misconnects, oversold cabins - since that's when recognition matters most and attention is scarcest.
WHAT THEY ASKED FOR
A single unified dashboard that surfaced every passenger data point ops had access to - loyalty tier, past complaints, rebooking history, seat preferences - in one screen gate agents could reference before every interaction.
FELT BY PASSENGER
01 Being rebooked onto the next flight before they've finished explaining what happened.
02 Not having to repeat the same complaint to three different staff members on the same trip.
03 A seat change that solves a problem they hadn't even mentioned yet.
04 Feeling recognized without knowing exactly why - the system stays invisible by design.
The impact passengers never see
Passengers never see the recognition engine. What they feel is the difference it makes - the agent who already knows them, the recovery that happens before they have to ask. The system's success is measured by what staff can do with it, not by whether passengers notice it exists.
UNSEEN
01 A gate agent who already knows the passenger's rebooking priority before they speak.
02 A connection at risk flagged automatically, instead of surfacing after the passenger misses it.
03 A service-recovery note from a prior flight carried forward, instead of starting from zero.
04 A platinum flier recognized at check-in without the agent having to dig for it.
WHAT I RECOMMENDED
A narrower, role-specific surface: only the status, priority flag, and service-recovery context relevant to the interaction in front of the agent - shown inline in the existing check-in flow, not as a separate tool to open and interpret under time pressure.
What I delivered: a system and a flow
The core of the work is a recognition engine that unifies loyalty tier, rebooking priority, and service-recovery context into a single signal, surfaced inline in the tools gate agents and check-in staff already use. Alongside it, a lightweight flow lets staff act on that signal in the moment - acknowledge a flag, log a recovery note, escalate - without leaving the screen they're working in.
THE SYSTEM
01 A recognition engine that pulls loyalty tier, rebooking priority, and service-recovery history into one status signal per passenger.
02 An inline surface in the check-in and gate tools staff already use - no second screen, no separate login.
03 A lightweight logging flow so a service-recovery note travels with the passenger, not just with the agent who took it.
THE FLOW
Staff see the signal the moment they pull up a passenger record - no second screen, no separate login. One tap acknowledges a flag, logs a recovery note, or escalates to a supervisor, so the response doesn't depend on which agent happens to be on shift.
Friction
None of this shipped clean. Four points of friction shaped the final design more than any single decision did - each one a constraint the system had to be built around, not a problem that went away.
SIGNAL VS. NOISE
01 Too much context is as useless as none. Early prototypes surfaced everything the back office had - the interface that resulted took longer to read than the interaction it was meant to speed up.
02 Staff trust built slowly. A recommendation that felt wrong even once was enough for an agent to stop trusting the system's other flags, so false positives had a cost disproportionate to their number.
THE QUIET COST
03 Built, then rebuilt, for irregular operations. A delay cascade or an oversold cabin changes what "the right context" means mid-shift - the version that worked for a normal Tuesday had to be redesigned for the day everything is late.
04 No system-wide metric captures a recovery that didn't happen. The strongest outcomes - the complaint that was never filed, the misconnect that was caught in time - are the ones hardest to put a number on.
Outcome
Full-scale measurement wasn't part of this phase - the program is still rolling out market by market. What's below is what's been reported back by the operations team so far, honestly separated from what hasn't been formally measured yet.
REPORTED
01 Faster recognition at check-in. Agents in pilot markets report spotting a status flag - priority rebooking, a prior complaint, a connection at risk - before the passenger has to explain it.
02 Fewer repeated explanations. Staff in later touchpoints (gate, onboard) can see what an earlier agent already logged, instead of starting the conversation from zero.
03 Positive informal feedback from frontline staff on reduced lookup time during irregular operations, where the old workflow required checking multiple systems under time pressure.
NOT YET MEASURED
Three numbers this design is meant to move, with no formal baseline captured yet: average time-to-resolution on a service-recovery case, the rate of repeat complaints from the same passenger within a trip, and gate-side rebooking speed during irregular operations.
The pilot markets are being instrumented for these now. Until there's a full quarter of comparable before/after data, any number here would overstate what's actually known.
What I'd do differently
"I'd bring operations into the room earlier than I did. The irregular-operations constraint reshaped the interface late, after a round of design that assumed a calmer baseline than the job actually is. Every version after that was better for having frontline input from day one - I just paid for not starting there."
Skills demonstrated
Service design · Systems thinking · Stakeholder facilitation · Interaction design · Design research · Information architecture · Cross-functional collaboration · Enterprise UX · Rapid prototyping · Accessibility