The face of the system
Examples and guidance read directly from the repository.
Return home
B2B cybersecurityDesign-system leadershipFront-end architecture
I built a shared, white-label design system
I designed configurable components for cloud and on-premises, then expanded the system through developer feedback.
01 · Shared foundation
I proposed a system we could own and evolve.
I needed to give a new cloud application and an established on-premises application a common foundation they could adopt at different paces. Cloud had one unified team; on-premises had several feature teams.
We chose a repository we owned so we could shape the design system and continue growing it. Our earlier build-versus-buy experience at Intralinks informed that decision. I built the HTML/SCSS components and a documentation interface that read directly from the repository.
I first implemented a simpler white-labeling approach for VIA, Intralinks’ flagship product, in 2014. At ObserveIT, I expanded that experience into a shared system serving cloud and on-premises.
I ownedDesign system, HTML/SCSS implementation, configuration, documentation, testing, and maintenance.
I worked withA fellow UX designer and engineers. Adoption decisions and application integration were collaborative.
Delivery stateLive internal system, used daily. The cloud application remained in beta during my tenure.
One maintained foundation
Shared code repository
Components · options · brand variables · HTML/SCSS
Built with the foundation
One unified team working on the new cloud product.
Adopted incrementally
Feature teams integrated shared components as they needed them.
Conceptual relationship map. Sketch held working design files; InVision supported developer handoff.
02 · System evolution
I expanded the system around the people using it.
As developers used the components, their questions showed what information they needed alongside them. I added HTML/SCSS examples, variables, design rules, and responsive guidance so that information was available in the shared system.
Illustrative reconstruction. Based on my recollection. Layout, code, values, and responsive behavior were recreated for this portfolio.
Start with a component and an include snippet.
Representative additions, grouped for explanation rather than exact releases.
Component preview
2 eventsActivity review
1 event needs review
Application eventReview the flagged application event.
File eventRecorded file activity.
No alertInclude snippetIllustrative
include("activity-review", {
alerts: true,
reviewEnabled: true,
density: "comfortable"
})Initial entry point
A component ready to include.
Each block started with an include snippet. Developers subsequently asked to see more of the implementation, design rules, and behavior.
How I kept component structure manageable
Block .activity-review
Element .activity-review__row
.activity-review__row--alertContainment and variation are different.
My blocks contained elements, and I applied modifiers to elements. I kept nesting shallow; exceeding my three-level boundary meant extracting a component or justifying a distinct one.
The modifier marks a variation on the element. It is not another nested container. This anatomy uses illustrative names.
Working with teams
I worked with developers on their first integrations while they connected components to application logic. I added guidance as needs emerged, working with engineers on capabilities and limits.
03 · Brand configuration
I separated customer branding from shared component structure.
I tested white-label configurations with customer palettes and used the shared brand variables for the Proofpoint rebrand. Related component states came from the base palette, with QA following brand changes.
The same component, a different brand
One base color. Related component states.
Component preview
2 eventsActivity review
1 event needs review
Application eventReview the flagged application event.
File eventRecorded file activity.
No alertBase
Hover
Pressed
Subtle
Border
Illustrative SCSS relationshipIllustrative
$brand-color: hsl(29, 85%, 72%);
$brand-hover: darken($brand-color, 8%);
$brand-pressed: darken($brand-color, 16%);Illustrative palette and derivation, not historical formulas or exact customer colors. White-label changes still required QA.
04 · Team requests
An on-premises request grew the shared system.
The on-premises recording team needed a screen-replay player before cloud did. I designed and built it as a component in the shared library, expanding the system around that team’s needs.
Other interfaces I designed
Supporting product-interface work
05 · Outcome
I gave teams a shared foundation they could adopt and keep building on.
The internal design system was live and used daily. Teams could adopt components incrementally and pick up tested updates from one maintained library. As I added guidance through feedback, the team had more information readily available.
The cloud application remained in beta during my tenure.
