Design System Lead Architect

For the second time I orchestrate and architect an enterprise scale design system. Solving hard problems of design systems.

Dynamic Color Architecture

One of the harder problems of design system architecture, creating cohesive but simplified colour palettes for theming and application.

…& Color Indexing

A guided scale for both light and dark modes using the full colour spectrum, as a guideline for choosing colour combinations and leveraging patterns for the design system architecture.

Modular Type Scaling

Another hard problem: architecting a UI that can retain its form even when the underlying typographical structure shifts.

Theming

Theming enables dark mode - everyone’s favourite - as well as, of course, branding and enabling other styles, especially for a “House of Brands”.

Documentation & UI Kits

 

The hard problem of documentation and guidelines. Unless there is a content strategist or a UX writer it is usually the task of the UX designer to write these. The designer can either be opinionated, or democratic - both of which methodologies bring their own issues.

 

Components

Detailed documentation on how components are built, and how to use them.

Patterns

Writing guidelines around UX patterns, reviewing them with teams, reviewing best practices and compiling into a unique proposition for this brand.

Socialising

 

The hard problem of socialisation. How to get people using this thing…

 

Designers

Designers are often on board with the design systems because (a) they love ready solutions, (b) they are usually part of the design process, (c) they use the UI kit.

Developers & Product

Developers and product can be more difficult to convert to using the design system. This is often due to the fact that Product teams have their own features to deliver which conflicts with a mandate to focus on the design system usage. Oftentimes a design system doesn’t cover exactly their needs and so they “branch off” - which then needs to be brought back into the system itself.

Product Ownership

 

A small design design team can oftentimes own itself - which means no official product owner. This was our case. I like to see where I am going, so I stepped up to provide - at least - a roadmap view of our work, and some prioritisation, documentation and product management.

 

Jira Board

There are so many teams with empty Jira descriptions, no roadmaps, un-categorised tickets and never-ending epics. I’m not saying Product Ownership is easy, but some principles really do help.

Documentation & Goal Setting.

Roadmaps are difficult to prioritise without some coherence with company wide initiatives via goal setting.

Design Ops

 

Often associated with design systems. Design Systems teams can often offer other kits, such as I did below: Lofi and wire-framing libraries.

Resource kits for designers

Wireframe Kit v1.0

Usage statistics

Previous
Previous

UXR & Operations @ CloudBees

Next
Next

AI Dashboard Assistant for CloudBees