A well known productivity hack to make a complex task easier is to break it out into separate tasks. For the last few years of web development, this was always a challenge to apply to front end web development. Working with different frameworks and CSS libraries had each project using its own approach UI development. After working with React for long enough, a process eventually finally emerged and Storybook was at it's core.
The Component 📦
It's the modular building block of front end web development. Popularized by React, it's introduced a paradigm into building UIs that a particular section or layout is simply an arrangement of one or more components.
Before Storybook, we called it the "kitchen sink". It was a term meant to express a place where you could go and view all the components in a team's particular design system. I'm really glad storybook came around because it was a bit of a pain to build those single pages apps over and over. Also a lot of people had to be sold on the idea in the first place.
Who are stories for?
Stories are a great resource for anyone working on a software project.
- For front end developers, they are a place to take inventory of what building blocks they have at their disposal when building interfaces. They also are a way to visually test and organize their component kit. It's a development team's single source of truth. My personal workflow start with building components directly into storybook, and hold off on routing and full pages until the majority of required components are complete.
- For designers, storybook is a great place to review and compare functional components to those developed in Figma, Sketch or other web design tools. They can compare components and sections to their designs, and with a single bit of feedback- drive systematic style improvements to a whole ecosystem of applications.
- For product people, its a continuous stream of status updates on the (often nebulous) creative workflow between designers and developers. Product owners can validate interfaces ahead of demos into a final product to ensure end users needs are satisfied.
Pros and cons ⚖️
All decisions in software come with trade-offs. Like more quality-focused processes, it will slow front end development down a bit at first. Key phrase is at first. Having a framework UI organization and review quickly pays for itself back. Of course, there's the complexity overhead of having to configure storybook and learn the API for creating useful stories. Admittedly, getting storybook working with popular CSS libraries like postcss, tailwindcss and styled-components comes with its share of hurdles, it's worth taking the day at the start of a project to make sure everything is configured properly. Storybook has its own webpack config, and way of importing styles. This was surprising to me at first, but makes complete sense once I took the time to learn how it all works.
How do I get started?
Head to storybooks docs and run the one liner to add storybook to your project. Depending on what CSS libraries you're using there may be some additional configuration setup. Your storybook environment should operate just like your development one. If there are missing styles or libraries not working in your stories, make sure all the same webpack, babel and postcss configs that are used in your main app are applied to the storybook config.
Once it's set up, begin documenting your components with stories- following a bottom-up approach to design.
Final thoughts 🤔
I'm still learning about building design systems from the seat of developer, but I've discovered some key insights worth sharing.
- Kicking off a project with a massive directory of responsive interfaces you can use as start points for developers is the best case scenario. With the purchase of a license, TailwindUI provides a kit of components you can use, but there are many other options. I highly recommend making this investment if your alternative is nothing. At Point Blank Dev, we've open-sourced a project details steps to import all the latest TailwindUI components to you project, and generate a story for each. Credits to Wildan.
- Not all style frameworks are great for everything- plan accordingly. We've discovered that while tailwind serves our purposes for over 80% of all style-focused development work, it's not great for building primitive components. We want primitives that can work with a variable number of themes. We'd want primitives that can utilize mixins through props. Tailwind struggles here- but styled-components shines. Styled-components also has a far more robust system for managing multiple themes through it's ThemeProvider context APIs.
- Typescript makes writing stories easier. Storybook will automatically pick up on your component's props if you assign the types in your stories. This just make viewing the stories that much nicer, without the overhead of assigning each argument type explicitly.
- Like many other quality processes, it a lot easier to start with it and stick to it then try to add it on down the line and retroactively implement it. Start your project with storybook and stay firm on component driven development. It will pay dividends.
Have fun building your very own customized design systems! 🖌️