IBM Lotus One UI
Before design systems became a fixture in product organizations, IBM Lotus One UI set out to bring order to a growing portfolio of enterprise products.
I was part of the small team that defined patterns, wrote guidelines, and built an internal site that helped hundreds of designers and developers create consistent, usable experiences across the IBM Lotus suite.
Context
By the late 2000s, IBM’s Lotus software family had expanded quickly. Notes, iNotes, Sametime, Connections, Quickr, Symphony, and Traveler each had their own look, feel, and behavior.
Every product team made decisions in isolation, and users felt it. Interfaces were inconsistent, code was not reusable, and the brand lacked cohesion.
Our team created Lotus One UI (later, ICS One UI) to fix that. It was not just a set of colors and icons. It was a unified framework that covered design principles, interaction patterns, front-end code, and visual language, giving every team a shared foundation to work from.
ICS One UI design guideline for Person Cards
Challenge
The biggest hurdle was scale.
Each product had its own legacy interface, codebase, and stakeholders who were protective of what they had already built. To succeed, we needed a flexible system that could stretch across desktop, web, and mobile, while remaining simple enough for developers to adopt.
We also had to earn trust. Other designers needed to see that this was not a top-down mandate but a tool they could rely on. That meant working side by side with them to refine guidelines until they worked for everyone.
IBM Lotus One UI messages guidelines
Results
Within a year, three additional products had fully adopted One UI.
Visual and behavioral consistency improved across the portfolio, and shared components reduced redundant work between teams. The system eventually became the foundation for future IBM collaboration products, influencing design language well beyond the Lotus suite.
How the Results Were Achieved
My focus was split between two areas: defining guidelines and building the site that housed them.
I helped document interaction patterns, wrote specifications, and designed the internal One UI site so teams could easily browse examples and copy the related code.
To make adoption easier, we created two companion tools. Asset House provided ready-to-use design files, icons, and templates for quick project starts. ArtSource served marketing and sales teams who needed official product imagery without tracking down a designer. These resources lowered the barrier for consistent output across departments and time zones.
ArtSource allowed sales and marketing to have access to product screenshots and icons at anytime, without the need to track down a designer.
Asset House allowed designers to have a common repository of Photoshop files to pull images, icons, and device, browser, and OS shells from.
Collaboration was key. I worked closely with designers across each product team to test how patterns would hold up in different environments, then partnered with front-end developers to make sure the code samples matched the design intent. That back-and-forth shaped a system that balanced flexibility with discipline, something rare at the time in enterprise software.
Reflection
This project shaped how I think about scale and clarity.
One UI proved that consistency does not have to mean uniformity. It can be a framework that gives people room to build. The lessons I learned here about pattern extensibility, documentation, and cross-team alignment have influenced every system I have worked on since, including the multi-product design system at Acoustic Connect.