Why you need a front-end styleguide for your IT product.
In EFI4 team we are all lazy. Not as in “I don’t like doing stuff” lazy, but a good and efficient “let’s do it smarter and save ourselves unneeded work” kind of lazy. This means that we are constantly looking for ways to improve our product development setup so it’s more comfortable for the team and more efficient. One of the ways that let us do just that was introducing the front-end styleguide to our product.
What’s that you’d ask? For starters, don’t mistake it for a brand style guide, as many people do. While a brand style guide is a set of rules and examples on how to use brand visual assets (like logo placement, brand colors etc.),
the front-end styleguide is a library of all the elements in your product’s user interface accompanied by code snippets,
that make implementation of given element a merely copy-paste-adjust action.
The styleguide typically includes common UI components used product-wide — buttons, navigation menus, tooltips, overlays, form-input elements etc. Basically, it comprises a base of UI building blocks used in the product, organized in modules. A great example is Lonely Planet’s styleguide available online: http://rizzo.lonelyplanet.com/styleguide/ui-components/cards It’s one of the most comprehensive ones of course and yours should start small and just build up with time.
Do you want to spend your team’s time on building a styleguide? Yes, you do. The mere existence of a styleguide already organizes the work around UI better and makes UI design much faster and more efficient. It gives you a set of Lego bricks for your app / website, both for the designers and developers (and a product owner, too!). What’s equally important, it provides a quick, universal reference for the whole team. Also, it frees up the time of designers, as front-end devs are able to do part of their work on their own, by simply using the elements pre-existing in the styleguide. Finally, the styleguide provides coherence and makes introducing new team members much faster and hassle-free.
On the other hand, having a styleguide allows you to separate the creation from implementation. Smaller tasks are always better, especially when you work in a fully agile setting. It’s also a good place for testing different scenarios when introducing new components to your product. Plus, it’s a nice clean place for keeping developer scripts (e.g. translation generator).
There’s really only one con to building a styleguide — you need to set aside some resources to create and maintain one. But in the long run, the net effect on your development is definitely positive. It’s an investment, not a cost.
Simply put, all the profits of styleguide fall into 2 major benefits a) save the time of your team in the future and b) make your work more comfortable. Told you, a good kind of lazy.
Want to see our Digital Banking Platform and its styleguide in action? Drop me a line and we’ll set up a live demo.
