Chassis CodeGen
To use one Chassis component, a developer had to download all 55. I redesigned the catalog into a browse, configure, and download experience, so teams get only what they need, ready to run. The customization forms were a second problem: new components arrived on engineering's schedule, not mine. So I wrote the form guidance developers built from, and moved from drafting every screen to approving them at sprint review.
Design lead, platform
55-component microservice “shopping cart” catalog
Chassis engineering, service teams
Stack Overflow Enterprise engagement, Chassis Confluence space
Developers add and remove components from their project's cart. Service names are anonymized.
WHERE IT STARTED
Nobody picked Chassis's microservices, but everyone had to use them.
To use one Chassis component, a developer had to download all 55 of them. Before Chassis CodeGen, the Chassis 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.
That work landed on every team, on every service, every time.
One catalog 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 code is generated and downloaded.
With the customized code generated by Chassis CodeGen, nothing 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 components.
Step 2, configuring a component - configuring here means time saved later
Step 3, adding project metadata - by adding it here, it adds the data to all the files in the package.
Step 4, review the package is listed before it's packaged.
Designing for components that didn't exist yet
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.
Teaching developers the basics of form design freed me for the part only I could do: the experience.
One home for the documentation
Documentation was the part I could not design my way out of. Before Chassis CodeGen, documentation was in a spread of locations across Confluence. Each microservice belonged to the service teams and it lived wherever they put it. For the MVP (and, shocker, there wasn't anything released past it beyond maintenance and microservice version updates), documentation for each service was consolidated into a central location in Confluence. Every component card had links to its documentation in the central location.
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.