- Proposed the platform and led its architecture
- Designed and built reusable HTML/SCSS components and tokens
- Defined the conventions and documentation teams needed to adopt it
- Tested changes and evolved the system through product feedback
Platform StrategySystems ThinkingAdoptionTechnical Delivery
ObserveIT
Building a Shared Platform Across Six Cybersecurity Applications
Platform Strategy, Incremental Adoption, and Acquisition Transition
I proposed and led a shared internal platform for ObserveIT's new cloud product and five existing applications. It grew through real product needs until all six applications used at least part of the system.
Shared application platform
Central internal system
Reusable Components and Platform Rules
One living source that applications could adopt incrementally.
New product
Cloud Security Platform
Built alongside the shared system.
Existing portfolio
Five Applications
Adopted useful components incrementally.
- Role
- Lead UI/UX Designer, focused on the shared design system
- Timeframe
- March 2019 to January 2020
- Application scope
- One new cloud product and five existing applications
- Contribution
- Platform strategy and technical delivery across six applications
My contribution
What I personally owned
- Platform ownership
- Originated the central-platform proposal, defined its architecture, and led the incremental adoption strategy across six applications.
- Design and build
- Designed and built the shared system while contributing hands-on UX and UI to the cloud product.
- Adoption and delivery
- Helped application teams integrate the system, then improved it through documentation, testing, and feedback.
I personally contributed to every interface shown in this case study. Cloud-product UX and UI was shared with Oscar, while engineers implemented application logic and integrations.
Ambiguity
One New Product, Five Existing Applications, No Shared System
“How could one internal platform support a new cloud product and five existing applications without forcing every team into a disruptive migration?”
ObserveIT was building a new cloud-security product while continuing to operate five existing applications. The products had different levels of code maturity and no shared source for UI or implementation decisions.
The system also needed to serve two internal audiences. Designers needed clear interaction rules, while developers needed working components they could configure and integrate.
The decision was larger than choosing a component library. We needed to decide whether to adopt an existing approach or create an internal platform that could evolve with the product portfolio.
01
One cloud product and five existing applications
02
No shared design system
03
Different levels of legacy code
04
Design and development audiences
05
White-label and brand requirements
Investigation
Testing Existing Approaches Against Portfolio Needs
The internal users were designers and developers. Their operational and technical needs provided the evidence for the platform decision.
The investigation combined a review of available design-system approaches with an audit of how ObserveIT's applications and internal teams actually needed to use the system.
6
Applications in scope
2
Primary internal audiences
1
Shared platform proposed
I reviewed the cloud product already underway and mapped how its components could connect to the five existing applications. I also evaluated available approaches with design and engineering partners, including Storybook as it existed at the time.
The options we reviewed separated implementation from guidance and did not support the application-level variation the portfolio required.
Requests from developers working on the existing applications became an ongoing source of evidence. Their integration needs helped determine which components and configuration options the shared system needed next.
- One source for working components and design rules
- Configurable tokens for brand and application needs
- Implementation guidance teams could use directly
- Incremental adoption for older applications
Structure
Designing a Central Platform, Not a Static Style Guide
I turned the portfolio's scattered requirements into a central internal platform that connected shared rules and implementation assets to six different applications.
Application layer
Six Product Contexts
- New cloud-security product
- Five existing applications
- Application-specific workflows
- Different levels of legacy code
Shared system
Reusable Components and Guidance
- Component library
- Design and usage rules
- HTML/SCSS implementation
- Selectable options and snippets
Platform foundation
Tokens and Complexity Controls
- White-label colors and logos
- Booleans and component states
- BEM naming structure
- Three-level nesting rule
Product decision
Build a custom internal platform
I originated the proposal, then whiteboarded the model with Oscar, Michael, and other developers. The group chose the custom direction together.
Tradeoff
Greater flexibility required more implementation capacity
The custom system could meet the portfolio's needs, but its implementation competed for the same capacity needed for UX and front-end delivery on the cloud product.
Prioritization
Expanding Through Real Product Needs
We avoided a portfolio-wide migration. The system grew through current product needs, beginning with the cloud product and expanding to existing applications one useful component at a time.
Current product needPortfolio reuseIntegration and legacy-code effortDelivery capacity
01 Foundation
Build with the Cloud Product
Develop the shared system alongside the new product where component needs were most immediate.
02 Reuse
Add Real Components
Connect new modules to the shared system as product work created reusable patterns.
03 Integration
Guide the First Adoption
Help each existing application integrate its first useful component with developer support.
04 Expansion
Respond to Application Needs
Add options and components when existing applications revealed portfolio requirements.
The adoption strategy was incremental: prove value in one application, support its first integration, and let real product needs determine what the shared system added next.
This reduced the risk of requiring older applications to migrate all at once. Adoption depth could vary while every application still gained access to shared components and platform rules.
New requests were evaluated by immediate product need, reuse potential, integration effort, and the capacity available to support adoption.
Alignment
Winning Adoption One First Integration at a Time
The platform became useful because each application team had a practical path into the system.
Cloud product team
Five existing application teams
Design
Shared operating system
Living Internal Platform
A shared source for working components, platform rules, and application configuration.
Front-end development
Application engineers
Quality assurance
6
Applications used at least part of the system: the cloud product and five existing applications
The proposal was mine, but the adoption decision was collaborative. After the group selected the direction, I made in-flight architecture and implementation decisions in response to the people using the system.
Each application's first integration received hands-on support from me and a developer. I explained the token and boolean structure while the developer helped connect the application to the shared implementation.
Execution
Operating the System While Building the Cloud Product
I operated the design system as an internal product while continuing to contribute UX, UI, and front-end work to the customer-facing cloud platform.
- UX and UI work on the cloud product was shared with Oscar
- Developers implemented application logic and supported first integrations
- Application teams supplied the requirements that shaped expansion
- QA verified the Proofpoint brand transition
Delivery boundary
The internal design system was live and used daily. The customer-facing cloud product reached beta users with an alerts-and-review MVP, but it was not fully launched during my tenure.
UX/UI contribution
These retained images show customer-facing ObserveIT applications to which I contributed UX and UI work. The cloud-product work was shared with Oscar. They are not screenshots of the internal design system.
Operational Outcome
Six Applications and a Rebrand in Minutes
6
Applications using the system
One new cloud product and five existing applications
Daily
Internal operation
The living design system was used as application work continued
~15 min
Brand update
Estimated time to change tokenized colors and logos for Proofpoint
~3 hrs
QA verification
Estimated time for QA verification across the applications
These are operational outcomes from my firsthand account. Adoption depth varied by application, and the cloud product itself remained in beta. The case does not claim a customer, revenue, or acquisition outcome caused by the design system.
Portfolio-wide reach
Every application used at least one part of the shared system.
Incremental adoption
Older applications could begin with one useful component instead of a disruptive migration.
Acquisition transition
Centralized brand tokens made the Proofpoint update a controlled platform change.
Reusable operating knowledge
Documentation and implementation guidance helped teams use the system without reconstructing its rules.
Lessons
What I Would Carry into the Next Platform Initiative
Adoption is part of the product
A shared system creates leverage only when teams can integrate it. First-use support and clear documentation mattered as much as the architecture itself.
Architecture should make change less expensive
The Proofpoint rebrand validated the token strategy. A change that could have required application-by-application styling became one controlled update followed by verification.
Capacity requires shared priority ownership
When UX and front-end groups assign work to the same person, availability and tradeoffs must be visible. The groups assigning work need one negotiated priority order instead of evaluating progress independently.
