Kanso Design System

Transform a fragmented enterprise platform into a cohesive, consistent user experience. This meant reconciling years of organic feature growth, integrating multiple acquired products with conflicting design philosophies, and solving critical memory management issues—all while preserving the workflows customers depended on.

Sumo Logic was founded in 2010 to leverage machine-generated big data for real-time IT, security, and business insights. After finding initial success with their log analytics platform, they added feature after feature to support expanding use cases. Design, however, wasn't a priority.

When I joined in 2019, the UX team operated on an agency consultant model — designers assigned to projects short-term, often deferring to engineers and product managers on design decisions. The result was an inconsistent patchwork of approaches across the platform.

Then came the acquisitions. A security startup in late 2019 and an incident management startup in early 2021 — each with their own design philosophies that conflicted with Sumo's paradigms. Legacy features were released and never updated. Iconography meant different things in different places. Color schemes clashed. Integrating new products often meant bolting on pages with jarring transitions and no warning between disparate experiences.

Customers noticed. Complaints about inconsistent experiences became frequent.

I was one of the earliest voices advocating for this initiative and became one of the main drivers of the project—though as different aspects became priority, other team members took the lead at times.

We started with a small core team: myself, the Head of UX, and a newly-minted senior designer scoping the work. As the project expanded, we grew to six designers holding regular meetings to evaluate approaches, conduct research, and design the navigation framework that would unify the platform.

Sumo's platform included an in-application pseudo-tab system that let customers close the app or log out, then resume exactly where they left off — all "open" tabs restored. For investigation workflows, this was invaluable. Customers made their feelings clear: "I will move to a different provider if you get rid of the tabs."

But the tabs created massive memory management issues — both client-side and on the backend, where we maintained tab states for thousands of users. As our customer base grew, the problem became untenable.

This became the catalyst. I had been one of the earliest voices advocating for a design refactor, but it took this critical technical constraint to justify the investment. By anticipating the need and starting early, we hit the ground running when leadership greenlit the project.

We began with myself, the head of UX, and a (newly-minted) senior designer scoping the work. The first phase was tedious but essential: inventorying the entire product, including pages from the acquired security and workflow products. While I performed much of the work, this was an all-hands effort involving every designer at some point.

Once complete, we categorized pages by design inconsistencies and by codebase — many were built on legacy code that was barely supported and no longer used for new projects. We'd need to rewrite or retrofit many of them. Some pages were left as-is when they were "close enough."

With the inventory done, a larger team convened for engineering scoping. The design team expanded to six designers holding regular meetings to evaluate approaches, research initiatives, and design a top-level navigation framework.

Navigating organizational dynamics

The security team initially pushed back on the level of work required. I pushed back harder — with leadership support — and got them on board early. The workflow product team was less reluctant, and leadership ultimately decided to include only a subset of their product, making integration more manageable.

We settled on a phased approach: top-level navigation framework first, internal page design consolidation second, then sunsetting the legacy interface once the existing customer base accepted the new approach.

We knew we needed to preserve the essence of the pseudo-tabs while eliminating the memory overhead. Several key decisions emerged early:

New customers, new experience

Once the first phase was complete and available for general use, all new customers would be required to use the new UI. This eliminated legacy experience going forward — new customers would never know about the old tabs.

Recents: context without the cost

To preserve the main advantage of pseudo-tabs — maintaining context — we introduced a "Recents" feature. Instead of holding tabs in memory, we captured state via a URL shortener: the log query, time range, panel arrangements, etc. This lived in a database rather than browser memory.

This choice also created unexpected opportunities. Sales could upsell larger or longer recents history. And sharing became dramatically simpler; users could copy a URL and send it on to colleagues, with security controls ensuring only authorized users could access shared links. There would be no more wrestling with the platform's overcooked sharing features.

Dual navigation model

Sumo's design system was stable but aging. We needed a consistent navigation approach across the main platform and acquired products. I strongly advocated for separation of concerns: a top configuration bar for platform settings, and a sidebar for feature navigation.

This sparked significant debate — many internal designers and engineers preferred a single sidebar for everything. But after several rounds of user testing showed 70-30% preference for the segregated approach, we moved forward with my recommendation.

Visual restraint

The security product was visually superior in many ways, and there was pressure — including from marketing — to pursue a more exciting overall feel. After multiple design rounds, we determined (again with my strong advocacy) to stick with a subtle approach, eliminating unnecessary design elements. Consistent typography and iconography using the incumbent design system became the standard.

The Library reversal

Sumo's Library was a heavyweight feature that let users manage their own content and access proprietary application analytics solutions. It also contributed to memory issues, so we initially decided to exclude it from the new UI.

That was a mistake. User acceptance testing revealed the Library was universally loved and crucial to existing workflows. After months of discussion, we reversed course — preserving the feature but rewriting its implementation for better memory management.

Links should act like links

Legacy Sumo had overloaded link behavior — on some pagesevery click opened a new (pseudo-)tab, which preserved state for previous views. Some pages included links that overwrote system context menus and replaced them with custom menus, hiding important functionality in many cases. Users had grown accustomed to this, but it was contrary to how links work everywhere else on the web.

As a former front-end engineer, my view was clear: links should follow canonical web behavior. Shift-click opens new tabs — that's how modern browsers work. But I knew it would be painful for existing users to relearn.

We landed on a compromise: links follow standard behavior by default, but legacy users could enable legacy behavior in settings. We also added an "Open in new tab" icon next to links. I found the icon cluttering, but conceded the point — I'd won the larger battle of web-consistent link behavior.

As of late 2025, the new UI is the default for all Sumo Logic customers. The old interface remains available only for grandfathered legacy customers.

I left Sumo in late summer 2024, before the full release, so I don't have visibility into the final customer impact metrics. But the project achieved what it set out to do: transform a fragmented, inconsistent platform into a cohesive experience that could scale.

The project was overwhelmingly positive despite being fraught with challenges. I had anticipated the need for this work very early in my tenure at Sumo, but it understandably took significant breakdowns of the legacy codebase to justify the investment to leadership.

Looking back, I wouldn't have done anything differently. The outcome was necessary and obvious in my view — I just needed everyone else to catch up.