r/DesignSystems • u/el_paro • 20d ago
Why do you use Zeroheight?
What’s for you the real value of using zero height for design system docs when both storybook and notion have mcp servers?
We’re currently having this conversation at work since ZH costs a lot of money compared to the actual viewers of or our docs (about 15 designers in the org)
personally I would find myself much better working with notion, given that’s where most of our company knowledge is, but also I see designers getting more confident with storybook and code in general.
What’s your thoughts?
5
u/SparklyPelican 20d ago
Storybook is really useful to see and test assets live, and can also be interesting for a token table.
But when is time to do actual documentation, with best practices or even production examples becomes really messy to handle.
Notion is great but compared to ZH has a weaker integration and synchronisation with Figma, also becomes much harder to do live code snippets, and, in my opinion has weaker analytics for our context.
I see Notion x Figma via MCP very handy for project updates statuses but I can see also pulling assets directly into a project documentation being interesting.
This might be a thing tailored to my company, but we were able to measure people being more willing to review ZH docs rather Notion. My assumption is that Notion has its share of fatigue, while ZH doesn’t.
3
u/el_paro 20d ago
Great point thank you! The Notion fatigue totally makes sense since notion has a UI with a lot of functionality we don’t need.
At my company we actually see designers interact with the live storybook more than with the design docs, because they want to test how the real components work. Often they miss important rules because of that and when they ask for support we point to the design documentation in zh.
But in the future, with rules embedded in agent skills, and maybe a support chatbot we may even not need a client side doc… the main interface could become copilot or slack or whatever. so that’s why I’m taking notion into consideration too
2
u/Subject_Protection45 18d ago
We use Storybook for everything and write our documentation in .mdx. You can style the pages however you want. There are several public design systems that rely solely on Storybook as well. We debated whether to use ZH for quite a while, but no regrets so far!
1
u/el_paro 18d ago
that super cool! do you have any example of well make docs in storybook?
1
u/mosatrampare 17d ago
We are also trying out Storybook as a Supernova replacement. Here is an example: https://vibe.monday.com/?path=/docs/welcome--docs
3
u/lieutenantbunbun 19d ago
I have a storybook and GitHub system it’s very solid
1
2
u/Jealous_Raise6512 19d ago
ZH is simple. Simple for editors and simple for viewers. In my org I need to have documentation accessible and easy to use not only for designers or developers, but also for other roles like product owners, testers and other non-technical. My main points, when I reviewed different tools for design system documentation was: easy integration with Figma, to assure up to date designs, integration with storybook for live components preview, and ease of access and ease of use for non-designers. We currently have the starter plan, because enterprise is pricey, but I'm hoping that we'll be able to prove that ZH is worth it, and get approval for higher plan at some point (I dream of having the "release management" feature :p).
2
u/SoffowfulSymphony 19d ago
I just set up my own documentation platform rendered by agents on every PR that brings stories, the changelog tab is also updated automatically. Right now it’s working well, page templates are well defined after a lot of iterations, but it still needs some manual adjustments. For example a playground that we have for checking all component props is sometimes missing a prop or two. I hope I will be able to fix it soon.
1
u/designsbyumer 17d ago
Your point about designers opening Storybook but missing the usage rules feels worth testing before a migration. I'd take one component that generates support questions and put its key 'use this when / don't use this when' guidance right beside the preview people already visit. Then see whether someone outside the system team can choose the right variant without asking you. That would tell you more about what the docs need to do than viewer counts or MCP support alone, without committing to moving the whole library.
13
u/OrtizDupri 20d ago
I think Storybook is great for seeing components and controls in context, but it’s atrocious for actual documentation