Thanks a lot for a very well articulated process for the biggest pain point for every design team.
Rohan Verma

I don’t completely understand your question, but if you are referring to why we inverted the hierarchy to place Applications in the beginning, it was because we wanted to place an emphasis on how to properly use specific UI components by showing real examples rather than having people jump into assembling pieces however they want.

We didn’t really consider any alternatives because there is only two ways to order things: top-down or bottom-up. In the very beginning, even before we settled on an atomic approach, we had a case studies bucket which would hold the stuff that wound up in the Applications and Features levels. Our previous design systems used this approach but the case studies were always out of date and no one ever looked at them anyway. We are hoping by integrating this content directly into the design system more people will pay attention to it.

The primary audience we had in mind was our designers, but followed very closely by our front-end developers. Then the business folks, but they probably only care about the Applications and Features levels.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.