— Work IV

Bringing a Legacy Product Back to Life

Legacy Product Modernizationthe biggest gain for the smallest cost

Read the case ↓
Project record — F. Reich
Timeframe
EventMobi era
Context
EventMobi — Event App & Experience Manager
Role
Product Designer & Strategist
Constraints
8 years without redesign · features-for-revenue pressure · deep technical restraints
Outcomes
  • Delivered a visible modernization win with near-zero engineering cost
  • Framed visual trust as a business argument, not an aesthetic one
  • Mapped the structural fixes — navigation, onboarding, the Back button — for staged releases
stakes

An outdated interface is a trust problem.

When I joined EventMobi, the event app hadn't seen a real redesign in eight years; the CMS, four. This isn't just a matter of delight — when a product looks dated, users quietly lose trust in it. That's a revenue argument, and it's how I framed modernization against the constant pull of new-feature work.

A design-file library of modernization workstreams — agenda refresh split across three releases, plus navigation, documents, and user agenda explorations
Fig. 1The ongoing exploration file — modernization as continuous iteration, not a big-bang redesign.
release one

The highest-leverage cut: kill the dropshadows.

With large technical restraints and every sprint contested, the question wasn't 'what's the ideal redesign' but 'what's the largest visual gain for the smallest engineering spend.' The answer was almost embarrassing: remove the heavy dropshadows across the app. One disciplined cut, and the whole interface stepped forward five years.

Before and after removing dropshadows across the event app
Fig. 2Release 1, before and after. Small change, disproportionate effect.
release two

The structural work, mapped and staged.

The deeper release was still being negotiated against technical and business restraints, but the certainties were established and evidenced: the confusing right-hand menu had to go (and its contents re-homed); login and onboarding needed a redesign — I'd watched people struggle with it first-hand while onsite at events; and the 'Back' button needed to become a true back button. It didn't take users back — it took them 'up' a level in the app's hierarchy, wherever that happened to be.

Mapping how the Back button actually behaves across the app
Fig. 3Mapping the Back button's actual behaviour — you can't fix what you haven't traced.