History
Browser
Redesigning the History Browser for a Cloud-based Video Surveillance System - reducing drop-off and bringing users back.
Redesigning the History Browser for a Cloud-based Video Surveillance System - reducing drop-off and bringing users back.
Users were abandoning the new web app and reverting to the legacy system at a rate of 70%+. The History Browser - the most-used, highest-friction feature - was redesigned end-to-end. After a phased rollout across two releases, adoption hit 99%+. The legacy system is now being retired.
A cloud-based smart video surveillance platform that allows users to manage their business anywhere, anytime, on any device - loaded with AI-based analytics and media operations, serving multiple industries around the world.
The project involved close collaboration across design, product, and engineering - working with a PM, Head of Engineering, Sr. Director of UX/UI, and Director of Product Management, with an engineering team executing the build. I led design end-to-end.
As part of modernising the platform, a new web application replaced a legacy system that users had relied on for many years. The new app was built with improved performance, a scalable architecture, and a refreshed interface - but migration wasn't just a technical shift. It required users to adapt to a new experience after years of habit-building.
Shortly after launch, a concerning pattern emerged: users initially accessed the new web app, but many did not stay. They frequently switched back to the legacy application, resulting in a high drop-off rate - measured through PostHog analytics and NPS feedback.
The legacy system had a planned sunset date - but retirement kept getting pushed back. Until users fully adopted the new app, the old system had to stay alive. Every user reverting was a delay to a deadline the business had already missed.
Enable users to seamlessly transition to the new web app by delivering a History Browser experience that feels intuitive, efficient, and reliable - reducing fallback to the legacy system.
The issue was not tied to a single broken feature, but to a broader mismatch between user expectations and the new design experience.
The new system required users to relearn workflows they had already mastered.
Although the problem was systemic, one feature consistently surfaced in both usage data and feedback: the History Browser. It was one of the most frequently used and workflow-critical features in the entire product.
We began by collaborating closely with the product team, business stakeholders, and incorporating user insights from our user summit. The system was feature-rich and complex - without clearly defining boundaries, the redesign risked becoming a large, unfocused effort with difficult engineering dependencies.
An open brief sounds like creative freedom. In practice, it meant the design work started one step earlier - before a single screen was touched, the problem itself had to be defined.
We conducted a thorough analysis of both our existing solutions and competitor products. A self-assessment compared the History Browser in the new web app with the legacy version, identifying gaps in usability, interaction patterns, and feature accessibility.
In parallel, a competitor analysis helped us understand industry standards and best practices - answering a critical question: why do users still perceive the legacy system as more intuitive, despite the advancements in the new application?
The most obvious path was to replicate what users already knew - rebuild the legacy experience inside the new app and call it done. We deliberately chose not to.
User feedback pointed to familiar patterns and interactions they missed. But familiarity is not the same as good design. The legacy system had its own friction - users had simply learned to work around it. Rebuilding those workarounds into the new app would have solved the wrong problem.
The goal was to make the new experience feel intuitive - not to make it feel old.
Here's how that principle played out across the interface.
A slider replaced the icon buttons for a reason. With + and - controls, the only way to know your zoom level was to read the time gap in the timeline. The slider shows it directly - no guessing, no reading. The same component was reused for playback speed controls, keeping the interface consistent without adding new patterns.
To help users quickly scan events without interrupting their workflow, we introduced an event preview card. Hovering over any point on the timeline - without clicking - surfaces instant context about that moment.
Accessibility was considered across every design decision, not added at the end. Icon touch targets were increased to meet minimum size guidelines. Event indicators were redesigned from thin strokes to larger blocks for better visibility. The timeline height was increased to improve interaction precision. Small changes individually - but together they made the experience usable for a much wider range of users.
During stakeholder reviews, we identified changes that could be implemented quickly while having significant impact on reducing drop-off. Collaborating closely with stakeholders, we prioritised high-value, low-effort improvements - changes that would deliver maximum benefit without requiring extensive development time.
We then organised these changes into a structured plan with multiple iterations, allowing us to deliver improvements gradually, gather feedback, and continuously refine the experience while ensuring early wins for users.
When the designs were presented to the development team, it became clear that modifying the existing component would be limiting. The team recommended creating a new, independent component instead - customisable and easier to maintain, allowing future features to be added without impacting other parts of the system.
Validating technical feasibility early ensured the redesign would improve the current experience and support future enhancements efficiently.
Adoption was tracked via PostHog across a phased rollout - first to select clusters, then to all users. The metric that mattered: were users staying in the new app, or reverting to the legacy system?
The legacy app is being sunset. When users stop going back, that's not just a metric - it's validation that the redesign solved the right problem.
Worth noting: retiring the legacy system wasn't a product or design initiative. It came from engineering. The 99%+ adoption rate is what finally made it possible. Maintaining two parallel systems has real costs: split engineering focus, dual infrastructure, and a support team stretched across two products. The redesign didn't just improve the user experience. It cleared the path for a long-overdue business decision.
