A colleague with far more developer experience went through the repos, uncovering all the dependency versions that were out there on the main apps, resulting in the diagram above. It became apparent that the solution we were looking for would have to be compatible with as many of these apps as possible, despite the different dependencies and frameworks, with the least amount of yak shaving. We still needed to provide a proof of concept that this work would get us to a desired state, which was not another failed Design System.

And so a fuzzy vision began to emerge of what this thing was going to be:

But what is a design system? We still hadn't defined it.

Those words meant a lot of different things to a lot of folks. So we had to come up with a definition.

Having been in manufacturing for a bit, I said let's look at it as a process. Cut out all the noise, simplify it, and focus on where inputs come from and what outputs look like.

Then we said 80% of our success was going to come from the stuff in the middle; it's not the designing or coding of the outputs, nor the collecting of what to build next. It was a process that would have to work in an environment that was constantly changing, wouldn't work if it was forced on the team, could be tested, and most of all relied on the team.

By mapping out the apps and their dependencies, we had enough information to talk to the engineering team about feasibility. Without understanding what was happening in the product architecture, it would have been naive to start any design system work. This was a win in discussions with the engineering folks because it was coming from the trenches—the reality of the dev environment.