Selected workDeveloper tools

Rally Software

From 2014 to 2018 I worked at Rally Software, which CA Technologies bought in 2015. Two projects are here: Agile Central, Rally’s product for planning and tracking software work, and Mineral UI, the open-source React component library I started so every product at CA could build from the same parts.

Role
Director, Design Systems
Company
Rally Software / CA Technologies
Years
2014 to 2018
Users
Agile teams, then CA’s product teams
I made
Product screens, components, the library’s site
Agile Central iteration status for Sprint 17: a row of progress rings for plan velocity, iteration end, accepted points, defects, tasks and iteration progress, above a board with Defined, In-Progress, Completed and Accepted columns of story cards.Rally
Iteration status. The sprint’s health in one row, and the board underneath.
Project 1

Agile Central

Rally’s tool for planning sprints and tracking work, and the product the shared components were first built for.

Tracking a sprint

Software teams use Agile Central to plan a sprint and move each story from Defined to In-Progress, Completed and Accepted. The iteration status page puts the numbers a team checks every morning across the top: velocity, days left, accepted points, defects, tasks and overall progress.

Adding work happens in place. The Add New panel opens over the board, so a story gets its name, owner and tags without the team leaving the sprint.

The same board with a dark Add New panel open above it: name, description, owner and tag fields with Add New, Add With Details and Cancel buttons.Rally
Add New. A story created in place, with owner and tags, above the board.
The iteration status page with a pink baseline grid drawn over it, showing every line of text sitting on the grid.Grid
Baseline grid. The same page with its grid showing. Every line of text sits on it.
An inventory page titled My First Inventory with Teams and Work Item Types dropdowns, and a table of workspaces and projects nested several levels deep with workspace and project permission columns.Rally
Inventory. For running agile at scale, like several SAFe release trains at once: every workspace, project and team in one tree, with permissions at each level.
Project 2

Mineral UI

A React component library for every product at CA, built on what we learned in Agile Central.

Sombrero first

Before Mineral there was Sombrero, the internal component library we built for Agile Central. By April 2017 every new page in Agile Central used it, and teams had been shipping the same button, dropdown and select for over a year. That let them spend their time on the parts of the product that were actually different.

Sombrero Form Elements page: a photo header, tabs for Buttons, Inputs and Selects, and primary buttons in large, medium, small and disabled sizes with usage guidance.Sombrero
Form elements. Each component with its sizes and states, and a line on when to use it.
Sombrero Notifications page with a CA Technologies sidebar listing components from Buttons to Popovers, and a live success alert marked Unstable.Sombrero
Notifications. Every component down the side, a live example of each, and a flag on the ones still changing.

Code, not a document

For its 2018 fiscal year, CA set the design team a goal to make good UI easy to deliver, and I took the component library. CA already had a design language, the EDL, but it was a document. In April 2017 I told the design organization that Mineral would be something developers could install.

The pitch
“This isn’t the EDL. Mineral UI will be actual code that developers can use to build buttons, dropdowns, modals, etc. that make up our products.”

Mineral UI Vision & Roadmap, April 2017

The goal
“Consistency becomes a by-product, not a mandate.”

Mineral UI Vision & Roadmap, April 2017

The repository went up on GitHub that month. We set it up like a product: public code, automated builds, each component published as its own package and version, and a website with examples and documentation for every component. I drove the component library and the component pages of the site. A colleague drove the style guide the components follow.

The Mineral UI website home page: a dark blue faceted background, the headline Build Modern Products Faster, a short description of the open-source design system, and Get Started and View on GitHub buttons.Mineral
The Mineral UI site. An open-source design system for CA’s products, with the code on GitHub for anyone to use.
Open the live site

Built in from the start

Accessibility was part of every component rather than a later pass: color with checked contrast ratios, standards-compliant markup, and testing with assistive technology. Each component was self-contained, so a team could drop it into a React app without breaking the styles around it.

Theming ran on design tokens. A product could change its fonts and colors, or white-label the whole interface, without forking a single component.

Getting it used

A library only counts when products ship with it, and that was the harder job. Product managers had features to deliver, designers disagreed, and most teams were short on front-end developers. Into 2018 I worked with groups across CA, including the mainframe division, on which library each of their React and Angular products should use.

In November 2017 I wrote about what I was learning in Change Is the Real Value of a Design System.

Medium, 2017
“The design of our products is what is in our products.”

Change Is the Real Value of a Design System, November 2017

What carried forward

The code is public on GitHub. What I took with me is the habit of designing the product and the parts it’s built from together. I did it again at Cloudflare and at SMX, because the fastest way to change how a product looks and works is to change the code its teams build with.