Role
Principal Product Designer
Scope
Enterprise design system
Environment
Multi-product / remote
Baseline
Ten product systems, no shared foundation
Sectigo’s product portfolio had evolved into 10 independent interface systems with no shared token foundation and minimal common documentation. Product teams had local patterns, naming systems, permissions, and working methods.
That fragmentation made brand modernization, accessibility, component reuse, and design-to-code collaboration harder than they needed to be. The program needed to create a shared foundation without erasing legitimate product-specific needs.
Objectives
- Create a shared foundation without erasing product-specific needs.
- Embed WCAG 2.2 AA and contribution governance into delivery.
- Structure tokens and components for dependable AI-assisted and design-to-code workflows.
Program scale and stakeholders
A cross-functional program across 10 product systems
Established a design-system program that connected executive sponsorship, a weekly design-system board, product councils, and delivery teams. Product management, design, engineering, QA, accessibility, brand, and leadership gained a shared route for resolving requirements, approving exceptions, and moving product-specific patterns into reusable standards.
| My role | Team contribution |
|---|---|
| Owned program framing, design-system strategy, Figma architecture, decision structure, priorities, and UX quality gates. | Product leaders supplied priorities and constraints; designers contributed product patterns and research. |
| Facilitated cross-product requirements, exception decisions, accessibility integration, and contribution governance. | Engineering and QA validated implementation behavior; accessibility and brand partners reviewed standards. |
| Built the design team and hired the interaction-design, user-experience, and design-systems personnel required to execute. | Contributing teams built, tested, documented, and adopted product-specific and shared assets. |
01 / Discovery
Audit, normalize, and distill shared requirements
The first phase documented file structure, product libraries, component usage, naming, permissions, collaboration practices, accessibility gaps, and duplicated assets. The audit produced a system map and a Figma enterprise framework before buildout.
Inventory
Catalog files, components, styles, permissions, ownership, and duplication.
Measure
Understand usage and identify high-value foundations that should become shared.
Structure
Define enterprise teams, product spaces, shared infrastructure, and clear ownership.
Normalize
Establish primitives, semantic roles, naming, states, and documentation.
A requirement journey
Product-specific requests were separated into user intent, interaction behavior, semantic meaning, and visual theme so legitimate differences did not create duplicate lifecycle logic.
- Product request“Each product needs a different certificate-status treatment.”
- Distilled requirementUsers need consistent recognition of lifecycle state, while product themes control presentation.
- System responseSemantic status tokens, documented states, and a reusable component.
- Delivery resultOne governed lifecycle model available to multiple product teams.
02 / System intervention
A shared design language that still supports product themes
Replaced product-local color values, status conventions, and component states with a semantic token architecture connecting brand foundations to reusable product behavior. The design system foundation supports product themes without requiring every product to use identical presentation.
Components became operational product assets: versioned, reviewed, measured, and prepared for implementation. Documentation places states, behavior, contextual guidance, and accessibility expectations beside the visual source.
| Before | After | Evidence |
|---|---|---|
| Product-local colors and naming | Shared primitives and semantic roles | Token architecture |
| Inconsistent status meanings | Documented feedback and status language | Component-state examples |
| Separate light and dark treatments | Shared semantic modes | Responsive examples |
| Local component decisions | Versioned, governed components | Contribution process |
| Minimal common documentation | Behavior, states, accessibility, and usage guidance | Published documentation |
03 / Changed behavior
From local approvals to a predictable route into production
The operating model combines strategic sponsorship, a weekly design-system board, and product councils. Disagreements and exceptions are resolved at the lowest appropriate level: product councils clarify domain needs, the board decides shared behavior and contribution readiness, and executive steering addresses portfolio priorities or unresolved risk.
| Before | After |
|---|---|
| Ad hoc requests and local approvals | Shared backlog, councils, and a weekly decision board |
| Separate product naming | Shared names connecting design, documentation, and code |
| Accessibility reviewed late in QA | Accessibility checks embedded in component and UX reviews |
| Product-specific recreation | Contribution path for reusable standards and controlled extensions |
Delivery gates
A design-system check at project start, shared stories in the backlog, accessibility reviews, Jira-linked guidance, shared names between design and code, a component-change process, and UX review make the operating model part of delivery.
04 / AI-ready operations
Trusted system data before automated output
Initiated four MCP integrations that make governed tokens, components, documentation, and accessibility rules available to AI-assisted workflows. This shifts experimentation away from disconnected prompting and toward system-aware output reviewed for product fit, accessibility, governance, and release readiness.
| Trusted source | Assisted task | Human review gate | Result to measure |
|---|---|---|---|
| Design tokens | Generate theme-aware UI | Brand and product fit | Manual restyling time |
| Component metadata | Recommend existing patterns | Behavior and contribution review | Duplicate components avoided |
| Accessibility rules | Review generated variants | Accessibility acceptance | Violations caught before QA |
| Documentation | Draft implementation guidance | Design and engineering approval | Preparation time and consistency |
Illustrative governed workflow
- A requirement enters through Jira.
- An AI-assisted design workflow accesses approved system inputs through MCP.
- A governed component or variant is proposed.
- Accessibility and product-fit checks run.
- Human reviewers approve, revise, or reject the proposal.
- The accepted result moves toward implementation and release.
Measurable results
Evidence grouped by what it proves
Delivery
429stories shepherded through design processAdoption
7,613component insertions trackedCapability
46people trained in accessibilityAI capability
4MCP integrations initiatedOutcome measures still in progress
Delivery, adoption, and capability signals are established. The next evidence layer is a controlled before-and-after measure of production-cycle time, clarification cycles, reuse, accessibility defects, and system-level change effort. Those numbers are intentionally not estimated here; they require consistent Jira, Figma, QA, and support scopes.
Result
A foundation teams can operate, measure, and extend
The transformation replaces isolated libraries with an operating system for product decisions: shared foundations where reuse creates leverage, documented contribution paths where product needs differ, and measurable delivery practices connecting design, code, accessibility, and AI-assisted workflows.
Teams now have a predictable route from product requirement to governed standard, with legitimate product extensions preserved and portfolio-wide decisions made visible. The program has established delivery, adoption, and capability evidence while outcome measurement continues.