[brundolf]

It's the main benefit IMO. It's great for quickly seeing what a component can do, but it's also fantastic for testing the different features. You can click through all the states (and transition between them), mix and match every permutation you can think of to make sure they all work together, etc. I've discovered several bugs this way in the past by selecting an odd combination of flags and finding out they break when used together.

Tbh without the ability to play with props I wouldn't even bother with a storybook-like interface. As you say, they probably have the code (and all its comments) in front of them, so what's the point of pretty documentation at that point?

[runarberg]

I’ve found that with semantic prop names + values and good documentation there is no real need for developers to play with the components. E.g. if you have a boolean property called `filled` on a button, and the mock has a filled button, a junior developer can easily figure out how to get the button to look according to the mock without any need to open the story book and play with the knobs.

The only benefits for the knobs I see is to provide a nice interface for the designers to scrutinize the system on an atomic level. However I am not a designer so I don’t know how valuable it is for them to do that through story book over exploring the actual app or a custom showcase. And if the benefits to the designers are only marginal, you have to ask if it is worth it for devs to maintain the storybook interface.

[brundolf]

When I used one we didn't have a designer at all, much less neatly-organized mockups.

But even if we had, we might not have discovered things like "oh, if you have the modal set to show a close button in the corner and also give it a really long title and make the window narrow then the button gets awkwardly pushed to the next line". The kind of stuff that mockups often don't cover, but real-world users might encounter some day.