Most front-end developers will be familiar with Storybook, an awesome tool that lends itself perfectly for building robust UI-components in isolation. Not only is it super handy for us, engineers - what we value most about Storybook is its ability to foster collaboration, to align disciplines of a project or guide teams across organisations.
In many companies a business feature takes form as follows: the business stakeholder explains an idea to the user experience specialist, the latter makes the flows and the sketches and the developer usually only gets involved as the last step. Although still a widespread practice, it’s not the most optimal: it doesn’t capitalise on the expertise of all the parties, its feedback cycles are long and it doesn’t inspire discussion at the right point in time. Storybook can be used to treat these ailments by giving developers a catalogue of components to let business and UX compose features from. Alternatively, they can choose to adjust the existing components - or, if necessary, design new ones altogether.
But even when you’re on a project that does not require much collaboration, Storybook can help you as an engineer. Have you ever just copy-pasted a piece of code in your codebase, swapped a few variables and left it at that? Or have you ever quickly added some padding without thinking through whether it should actually belong to a parent element? Ever had to modify data in a database to get some piece of the UI to render? Or worse, have you had to wait for a teammate or a team to deliver a service you depend on for your feature? The problem is: development in an app context doesn’t encourage the developers to respect component boundaries in the context of the whole app. As a result, they are often intertwined in the context and thus not reusable. They also tend to have unclear API’s and are harder to maintain than their counterparts built in isolation. And, last but not least, UX and business tend to concentrate on happy flows, while in practice things do go wrong, servers go down, connections are interrupted or terribly slow and your component had better be prepared.
This is, more or less, the situation we encountered at Malmberg, a Dutch educational publisher and part of Sanoma Learning Group, where we helped develop the online classroom tools and teaching apps. We wouldn’t be Flock. if we didn’t search for a better way.
Coincidentally, during one of our Flock. Days we studied Storybook and we were totally enthusiastic about it. Storybook allows components to be designed as if they were Lego-blocks: separate, robust and with clear instructions as to how they should be used. It’s enough to build them once in isolation, showcase them and allow others to re-use them. As to the unhappy scenarios, the developers don’t need to wait for them to actually happen. Error production (and reproduction) is easy in Storybook and most, if not all, unhappy scenarios can be tested and amended beforehand.
Needless to say, we were very eager to introduce it at Malmberg, as it seemed exactly the solution we were looking for. The result is a library of robust, reusable components, a way to involve various stakeholders in the development of features and, last but not least, a gradual change in engineering culture: from silos to cross-pollination. The latter usually takes time, but the first step is made and we’re proud to have been a part of it.
