One design system for design and engineering
Design SystemsDesignOpsAI-Assisted WorkflowsIn Progress
Design lead · Tidal Cyber · Figma, GitHub, Codex, Material UI
Tidal Cyber Design System: cover page and project overview in Figma (in progress)
The Problem
Our design system didn't reflect the product we were building.
We had an existing design system created by an external agency, but it wasn't fully aligned with the MUI-based components used in our production platform. Over time, this created a disconnect between what was documented in Figma and what users actually experienced in the application.
With multiple engineering teams contributing to the UI, inconsistencies became increasingly visible. Components didn't always follow the same visual patterns, styling decisions were sometimes hardcoded, and design specifications didn't consistently reflect implementation.
We also had powerful tools across design and development, but they largely operated as separate environments. Figma housed our designs. GitHub contained the production code. Engineering implemented components, and AI-assisted tools offered new opportunities for development. We lacked a connected workflow that brought these capabilities together around a shared source of truth.
The challenge wasn't simply to make the interface more consistent. It was to create a system that connected how we design, build, validate, and evolve the product.
My Role
Leading the system, not just designing the components.
As the design owner for a growing enterprise cybersecurity platform, I initiated and led the design system modernization while continuing to support feature development and other product experience initiatives. I owned the design vision, system architecture, naming conventions, design tokens, Figma variables and components, documentation strategy, and overall approach to adoption.
I also worked directly with engineering to audit the existing platform, understand implementation constraints, and establish how design specifications could connect more closely with actual code. Engineering owns coded component implementation, technical validation, Storybook integration, and deployment. I contribute to QA, validating that tokens and components match design intent before they ship.
My responsibilities included:
- Defining the modernization strategy and establishing a scalable design foundation
- Partnering with engineering to audit production components and identify inconsistencies
- Aligning the new system with the platform's existing MUI architecture
- Building and organizing design tokens, Figma variables, and reusable components
- Using Codex and GitHub to inspect, generate, compare, and validate implementation patterns
- Collaborating with engineering on technical feasibility, component implementation, and incremental rollout
What Was Built
Color token architecture: semantic color system defined in Figma variables, aligned to the platform's MUI foundation
1. Starting with the product, not an idealized design system
One of the earliest decisions was to audit the existing application before defining the new system. Working alongside engineering, I compared what existed in production against our previous design system. We identified inconsistencies between Figma and implemented components, hardcoded styling, and areas where our agency-created system didn't align with the platform's MUI foundation. Rather than introducing a completely new architecture, we built on the framework engineering was already using.
2. Establishing a shared design foundation
The system includes: design tokens (shared definitions for colors, typography, and spacing), Figma variables (structured properties for consistency and maintainability), reusable components aligned to the platform's MUI foundation, and component documentation in Figma matched with engineering implementations. One early area of focus was button styling and hierarchy. Different areas of the platform had developed inconsistent patterns, and shared tokens gave teams a common reference.
3. An incremental implementation strategy
We deliberately avoided a platform-wide overhaul. Instead, we established an incremental rollout strategy, modernizing one page at a time while building reusable foundations that could be adopted elsewhere. This approach lets us validate components in real product contexts, work within engineering constraints, and improve consistency without disrupting ongoing feature development.
The Engineering Connection
Button & Icon Button component page: 36 variants with usage documentation, property definitions, and Storybook integration
Each tool in the ecosystem has a distinct role:
- Figma: design source of truth: specifications, variables, tokens, reusable components, and Dev Mode for engineering access
- GitHub: the bridge to production: I use it to inspect implementation patterns, identify inconsistencies, and compare designs against what's actually built
- Storybook: the engineering-facing component playground: live, actively maintained by engineering, and a company-wide reference for what components exist and how they behave. I participate in QA to validate that tokens and component output match design intent
- Codex: AI-assisted design and development collaboration: I use it to inspect code, audit styling, compare implementations against design specs, and generate functional prototypes
The objective isn't to automate away design or engineering judgment. It's to make that judgment better informed and easier to translate into implementation.
Adoption & Status
Initial components are in production, Storybook is live, and engineering is actively building out the shared component library. Adoption is still incremental. The new system has not yet been deployed consistently throughout the entire platform. The work has established a common direction for design and engineering, particularly around component structure, reusable styling, and more consistent implementation decisions.
The next challenge is establishing a sustainable governance model. Design and Product own decisions about changes to the system, with the CX team expected to manage ongoing component creation and maintenance. A key objective is keeping Figma and Storybook synchronized so the system doesn't gradually drift apart again.
Reflection
01
Start with the product that exists, not the ideal system you imagine.
Our previous design system demonstrated the limitations of creating a component library that wasn't sufficiently aligned with production. Auditing the actual codebase alongside engineering gave us a more practical starting point. A design system only delivers value when it can be implemented and maintained.
02
Design-engineering alignment is an ongoing practice, not a handoff milestone.
Shared technical understanding leads to better design decisions, while shared design principles help engineering make more consistent implementation choices. The goal is for design and engineering to keep working together long after handoff.
03
AI can expand the impact of a small design team.
Owning design end-to-end across a growing platform means balancing foundational system work with active feature development and broader product experience improvements. AI-assisted tools have helped me work more effectively across these responsibilities, making it easier to understand code, audit components, generate prototypes, and validate implementation details. The biggest lesson: AI is most valuable when it strengthens collaboration and extends existing expertise.
Helping security teams see what changed and what to do about it
Landing ExperienceSecurity IntelligenceCustomer Research
Design lead · Tidal Cyber · Partners: Product, Engineering, Cyber Threat Intelligence (CTI)
Status: Initial release shipped; subsequent enhancements in progress
The What's New landing consolidates coverage score, threat intelligence feed, and AI-prioritized recommendations into a single starting point.
The Problem
We had plenty of data. We weren't helping users understand it.
The original landing experience combined two primary areas: What's New, which surfaced threat intelligence and content updates, and Coverage Map Rollups, which summarized an organization's defensive coverage.
Both served a purpose, but together they exposed a larger problem: we were showing users information without providing enough context to make it useful. Security practitioners needed more detail to investigate threats, coverage gaps, and recommendations. Leadership needed a simpler way to understand security posture and communicate progress. Neither audience could consistently get what they needed without additional interpretation.
Coverage Rollup brought individual Coverage Maps together into an aggregate view, but the meaning of that aggregate score wasn't immediately clear. Users couldn't easily understand what contributed to it, why it mattered, or what actions they could take to improve it. The experience placed the burden of interpretation on the user.
The design challenge became less about what data we could display and more about what questions the experience needed to answer: What matters to me? Why does it matter to my organization? What should I do next?
My Role
I led the UX strategy, research, design, and prototyping for the unified landing experience. I partnered with Product leadership, Engineering, and our Cyber Threat Intelligence team to align customer needs with business priorities and technical capabilities.
My work included leading customer feedback sessions, translating research into design decisions, developing interactive prototypes, facilitating stakeholder alignment, and contributing to implementation tradeoffs. My responsibility extended beyond designing a new interface. I helped establish how the experience should communicate complex information, serve different audiences, and connect users to the actions that mattered.
The Design
Coverage Priorities surface gaps by category (Execution, Initial Access, Persistence) and across environments (Windows, Cloud, SaaS, Linux).
The What's Changed section shows coverage movement over time with an integrated Threat Intelligence Feed surfacing relevant matched threats.
From reporting information to supporting decisions
Rather than abandoning the existing Coverage Rollup, I used it as a foundation for a more useful landing experience. The goal wasn't simply to combine separate pages. It was to help users understand their security posture, recognize meaningful changes, and take action without navigating across the platform to reconstruct the context themselves.
I focused the design around four core areas:
- Relevant threat intelligence. Bring threat updates into the same experience as customer coverage information. Help users understand why new intelligence matters and provide paths into existing workflows, including Threat Profiles.
- A clearer coverage overview. Build on the original Coverage Rollup by presenting security posture in a more approachable way. Give users a high-level understanding of their coverage while preserving access to individual Coverage Maps for deeper investigation.
- Contextual recommendations. Connect recommended actions to the affected coverage, defensive tools, and underlying findings. Help users evaluate recommendations rather than simply presenting another list of things to review.
- Changes over time. Make coverage trends and changes more visible so users can understand how their security posture is evolving, instead of relying exclusively on an aggregate score or passive notifications.
Validation
Top 5 Coverage Map Movements and Defensive Opportunities give users actionable signals: what changed, by how much, and where detection and prevention gaps remain.
Interactive prototype demo: the time-range toggle updates coverage trends, threat activity, and score movement across the full experience.
Motorsport: Connecting intelligence with reporting
In research with an enterprise security team in the motorsport sector, we received positive feedback on bringing threat intelligence and coverage insights into one experience. The customer saw value in the consolidated view, particularly its potential to support management reporting, reinforcing the need to accommodate users who wanted to understand overall security posture without navigating through detailed operational views.
Pharmaceuticals: Preserving the value of detailed coverage analysis
Research with a pharmaceutical-sector customer revealed an important distinction: the team placed greater value on individual Coverage Map analysis than on the overall rollup score. This challenged the assumption that the aggregate score should always be the dominant element, and reinforced my decision to treat the summary as an entry point rather than the complete story.
Healthcare: Validating a consolidated starting point
A healthcare-sector customer responded positively to the consolidated landing-page direction. Their feedback reinforced the importance of reducing fragmentation while maintaining clear distinctions between different types of information and the actions available to users.
Defense: Moving from notifications to meaningful change
One of the most useful findings: the customer valued understanding how coverage had changed over time more than receiving passive notifications that something had changed. They also described how evaluating a recommendation required additional investigation: identifying affected tools and Coverage Maps, understanding implementation effort, and deciding whether the benefit justified the work.
Knowing that something changed isn't the same as understanding what to do about it.
This feedback directly influenced the design direction. I placed greater emphasis on coverage trends and the context behind changes, rather than relying on notification indicators alone.
Outcome
We shipped the first phase of the unified landing experience, establishing a new starting point for customers to explore threat intelligence, security coverage, and related actions. Customer validation supported the overall direction, while also revealing opportunities to improve relevance, clarity, and how information connects to existing workflows.
We haven't established quantitative evidence of improved task performance or engagement for this case study, so I view the initial release as an important milestone rather than a final measure of success. After the initial release, I continued working with Product and Engineering to evaluate feedback and prioritize refinements. We're now preparing a subsequent release focused on clearer threat intelligence context, improved coverage explanations, and more meaningful paths from findings to actions.
Reflection
01
More information doesn't automatically create more understanding.
Early in the process, we focused heavily on the information available to display. I learned to challenge whether each piece of information actually helped someone make a decision.
02
Inclusive design means accommodating different information needs.
Not every user needs the same level of detail. If I approached this again, I would establish those differences earlier and validate how different roles prefer to consume, interpret, and act on information before committing to a specific information hierarchy.
03
Design doesn't stop at the first release.
Shipping the initial experience gave us another opportunity to learn. Continuing to evaluate feedback, question assumptions, and refine the design has been as important as defining the original direction. Organizing information is the easy part. The real job is helping people see what matters and act on it.
