Chassis CodeGen
Dozens of service components, each needing its own customization form. Designing them one at a time would have spent the platform's entire design capacity on a single tool. So I designed the application, the component and pattern library and taught the basics of form design to the dev team, and moved from drafting every screen to approving them at sprint review.
Product designer, platform
55-component microservice “shopping cart” catalog
Chassis engineering, service teams
Stack Overflow instance, Chassis Confluence space
Developers can add and remove microservice components to their project "shopping cart". The microservice names are anonymized for confidentiality.
WHERE IT STARTED
Nobody picked Chassis but everyone had to use it.
To use one Chassis component, a developer had to download all 55 of them. The enterprise microservice library was one package — every service, every dependency, whether the project needed it or not. Documentation for each service lived in different locations. Each service team kept its own, in its own Confluence space, wherever that team decided to put it.
After adding the package, developers had to go through and delete each microservice the project wasn't going to use. Other teams left the whole library in place, unused files and all. Whatever remained still had to be configured by hand, one component at a time, against documentation a developer had to know where to look for.
Nobody picked Chassis. It was the standard. That work landed on every team, on every service, every time.
A one-stop shop for the back-end
Scroll or search 55 components, add what the service needs to a cart, and leave by one of two doors: download the selection as a single zip, or open each component and configure it first. The last screen lists what's in the package before the download runs.
Nothing arrives that has to be deleted. Configuration happens in the cart, so a component drops into the project ready to run.
Step 1, developers view their cart - they can review, remove, and configure.
Step 1, configuring a component - configuring here means time saved later
Step 2, adding project metadata - by adding it here, it adds the data to all the files in the package.
Step 3, review the package is listed before it's packaged.
Working with a dev team
I designed the application experience from end to end — catalog browse and search, selection, the cart, the download. That was one problem and it was solvable.
The customization forms were a different problem. Every component exposed its own options, and new ones arrived on the engineering team's schedule, not mine. Whatever I built had to work for components that did not exist yet.
So I provided the guidance instead: how options group, which control fits which kind of setting, what a default does when a developer changes nothing, what the form has to document. The engineering team built forms at their own pace from there. I approved layouts at sprint review.
As a lead designer, teach your developers design basics so you can focus on what's important: the experience.
Beyond the design...
Documentation was the part I could not design my way out of. It belonged to the service teams and it lived wherever they had put it. So we consolidated it into a single Chassis space in Confluence and made maintaining it there a condition of being in the catalog. Every component card links to its own entry.
To use the components they need, a developer now downloads only those. Chassis is still the standard. It just stopped making teams pay for it.
Consolidating documentation solved discovery but moved a maintenance burden onto service teams as a condition of catalog membership. That only holds while the catalog is worth being in.