Hey Nathan, thanks for the post! I think this framing is very useful. I have a question about the boundaries of this approach.
Seems like schemas could deterministically guarantee things like teams using only the available variants, which is terribly useful. What it can't tell us, as far as I can see, is whether they picked the right component/variant for a given use case. The rules governing such choices still belong in the design system: "use this component for this type of use case". But most of the times these can't be automatically verified because they would need extra application context that doesn't exist when the contract is written.
So, in your mental model, are decisions like these deliberately outside what a contract arbitrates? And if they are, do they still live somewhere in the design system, in a less verifiable form?
That’s a good question! I dig into the broadening relationship of component data that’s generated (this contract) vs authored (guidance docs like you refer to) a bit in my subsequent post. I also admit that my work has far for targeted making components more than using components.
Hey Nathan, this is a great primer for component contracts. Would you be able to share an example of a component contract for a publicly available (documentation) design system so that we can compare the component details and its contract side by side. It would really help us understand the concept better
I could. However, you can use specsplugin.com’s Figma plugin or command line tools, taking a few minutes, to generate those specs on your own assets for free (at least, other than tokens, which require a subscription). No comparison needed. Connect with me on the product’s Slack or email if you run into challenges.
Natan, this past Saturday at Inspect26 was the first time I saw you present, and it landed differently than just reading your posts. The passion is obvious — and honestly, it's rare and energizing to witness that, especially in a market like ours that's pretty beat down right now. Thanks for bringing that kind of work to the conversation.
Thanks for sharing that! Are you saying that this post's writing is less passionate or more passionate than how I present? If less, I need to work harder to convey that more :)
Hey Nathan, thanks for the post! I think this framing is very useful. I have a question about the boundaries of this approach.
Seems like schemas could deterministically guarantee things like teams using only the available variants, which is terribly useful. What it can't tell us, as far as I can see, is whether they picked the right component/variant for a given use case. The rules governing such choices still belong in the design system: "use this component for this type of use case". But most of the times these can't be automatically verified because they would need extra application context that doesn't exist when the contract is written.
So, in your mental model, are decisions like these deliberately outside what a contract arbitrates? And if they are, do they still live somewhere in the design system, in a less verifiable form?
Jesús,
That’s a good question! I dig into the broadening relationship of component data that’s generated (this contract) vs authored (guidance docs like you refer to) a bit in my subsequent post. I also admit that my work has far for targeted making components more than using components.
https://nathanacurtis.substack.com/p/spec-driven-ui-component-development
Hey Nathan, this is a great primer for component contracts. Would you be able to share an example of a component contract for a publicly available (documentation) design system so that we can compare the component details and its contract side by side. It would really help us understand the concept better
I could. However, you can use specsplugin.com’s Figma plugin or command line tools, taking a few minutes, to generate those specs on your own assets for free (at least, other than tokens, which require a subscription). No comparison needed. Connect with me on the product’s Slack or email if you run into challenges.
Natan, this past Saturday at Inspect26 was the first time I saw you present, and it landed differently than just reading your posts. The passion is obvious — and honestly, it's rare and energizing to witness that, especially in a market like ours that's pretty beat down right now. Thanks for bringing that kind of work to the conversation.
Thanks for sharing that! Are you saying that this post's writing is less passionate or more passionate than how I present? If less, I need to work harder to convey that more :)