Want to know how much website downtime costs, and the impact it can have on your business?
Find out everything you need to know in our new uptime monitoring whitepaper 2021



As a developer, I am a massive fan of documentation and (as you can probably tell from my previous blog post) also a big fan of Storybook. If you’re interested in what Storybook is and how to set it up, or integrate it into your existing project, you can find out more about that here. However, in this post, I am going to be outlining why you should be using Storybook and each of its features and capabilities. This is in addition to (at the time of writing) some exciting new additions to the library.
There is a reason so many big name brands such as GitHub, Mozilla and Airbnb use Storybook to document their components. The first (and in my opinion the most redeeming) benefit of using the library is that it is the most extensive and detailed way of documenting your components. Within Storybook, components are thought of as ‘alive’. What I mean by this, is that the component within Storybook isn’t just a static snapshot of that component at a certain time, it is the component itself at any given time. So whenever changes are made to that component within the codebase, the story will reflect those changes too.
You can also add the integration of ‘controls’ to make your component completely interactive as if it were on the live site. The best part of this is that these controls have a very user-friendly interface, so each user (no matter their technical capabilities) is able to see and interact with the component in every state that it has. I have found that this is a very useful tool to increase collaboration between both development and design & UX teams, as it acts as a single source of truth for all of the components within your codebase.
The next benefit (from a developers perspective) is the great way that it documents the technicalities of the component. We’ve all been there, when you’ve worked on a large codebase for a while and you come across a component that you haven’t seen for too long and you’re not sure what the hell it even does. Similarly, you could be a developer that is new to a pre-existing codebase and need to familiarise yourself with the components available to you and how they work. This is where the ‘docs’ Storybook addon comes into play. With story docs, you can add a description of the element as well as being able to view it in a sandbox. The best part of this though, is that each of the props that are passed through to this component are laid out in a grid with descriptions, so you can easily view the data and variables that go into a component and how they affect that component if amended.
Speaking about docs, in addition to being able to add documentation for each component on a per-story basis, with Storybook you can also add what are known as ‘doc blocks’. Doc blocks are separate pages that sit outside of the component folders. They are used to add much more generalised information about the project, such as an introduction page, or a theming page such as typography. It is completely up to you how extensive and in-depth you want these doc blocks to be, but in my opinion, every little (bit of documentation) helps.
Now, moving away from documentation for a little bit, another significant benefit of integrating each of your components into Storybook is the testing capabilities that it gives you. With your components now in isolation, visual tests can be created to ensure no visual regression when you are writing your day to day code. This, to me, is a very powerful addition to any codebase and can work very well alongside any functional or end to end tests you may already have.
This leads nicely on to a very exciting feature that (at the time of writing this blog post) is currently in beta mode. Storybook Interaction Testing will elevate the current testing capabilities within Storybook and allow you to write UI tests within stories and (using the new test runner) execute them. This is a great addition to the visual tests as you will be able to verify both looks and logic at the same time.
A great feature of Storybook that I personally benefit from when working day to day is the fact that each component is visible and can be worked on from the sandbox that it lives in within its story. This means that when you are creating a brand new component, instead of needing to add it to a page to work on its UI and styles, all you need to do is make a story for it. This is also fantastic for code review as well, as instead of having to search through a website to try and find the component you are reviewing, you will always be able to find it on your Storybook instance as long as a story has been created for it.
There are also a multitude of addons that you can add to your Storybook integration in order to elevate its capabilities even further. I will list some of my favourites, but there are many more that you can explore here.
The first (and my personal favourite) is an addition that both makes your components more accessible, as well as maintaining any accessibility standards you may already have. storybook-addon-a11y is really simple to install and adds another tab onto your story to allow you to run Axe to let you know where you are going wrong in terms of the components accessibility. As well as running it on your existing components, you can also use it while you are coding and creating new components, to ensure high accessibility standards are being met at all times.
storybook-addon-designs is another fantastic addon that improves collaboration between development and design teams. Using this addon gives you an extra panel on your story, where you can view the design of that particular element directly from Figma via a link. Alternatively, if you use other design tools on your project (e.g. Adobe XD) there are other addons that work with those too.
Another valuable addon for Storybook would be storybook-links-addon. This allows you to navigate between your stories by using links, instead of having to use the sidebar. This makes the user experience much nicer.
In conclusion, Storybook itself is a super powerful addition to any project and you can use each of its capabilities to improve code quality & accessibility, increase collaboration between teams and ensure no regression of your existing components using the testing integrations. As mentioned before, if you are now interested in introducing Storybook into your project, as well as using the fantastic docs, you can also view my tutorial blog post to show you how to do that.
Share this
3 min read In the first two posts of this series, we explored how alert noise emerges from design decisions, and why notification lists fail to create accountability when responsibility is unclear. There’s a deeper issue underneath both of those problems. Many alerting systems are designed without being clear about the outcome they’re meant to produce. When teams
3 min read In the previous post, we looked at how alert noise is rarely accidental. It’s usually the result of sensible decisions layered over time, until responsibility becomes diffuse and response slows. One of the most persistent assumptions behind this pattern is simple. If enough people are notified, someone will take responsibility. After more than fourteen years
3 min read In a previous post, The Incident Checklist: Reducing Cognitive Load When It Matters Most, we explored how incidents stop being purely technical problems and become human ones. These are moments where decision-making under pressure and cognitive load matter more than perfect root cause analysis. When systems don’t support people clearly in those moments, teams compensate.
4 min read In the previous post, we looked at what happens after detection; when incidents stop being purely technical problems and become human ones, with cognitive load as the real constraint. This post assumes that context. The question here is simpler and more practical. What actually helps teams think clearly and act well once things are already
3 min read In the previous post, we explored how AI accelerates delivery and compresses the time between change and user impact. As velocity increases, knowing that something has gone wrong before users do becomes a critical capability. But detection is only the beginning. Once alerts fire and dashboards light up, humans still have to interpret what’s happening,
5 min read In a recent post, I argued that AI doesn’t fix weak engineering processes; rather it amplifies them. Strong review practices, clear ownership, and solid fundamentals still matter just as much when code is AI-assisted as when it’s not. That post sparked a follow-up question in the comments that’s worth sitting with: With AI speeding things
Find out everything you need to know in our new uptime monitoring whitepaper 2021