Tutorial Progress
Why use Style Guide Driven Development?
Lesson Contents
- 3 reasons for using Style Guide Driven Development
Video Lesson
Written Lesson
In the first two lessons we talked about what is Style Guide Driven Development and how it incorporates design as part of the process via a Living Style Guide. Now let’s dive into the reasons why you should be using it.
style guide driven development provides both a framework and a playground for development
Reason #1
It provides a framework as the living style contains the definitions of UI elements (think of colors, typography, as well as headers, input controls and buttons) as well as a library of components (think of navigation systems, toolbars, search bars and the like). So when you start coding you are not starting from scratch. Instead you can build upon existing definitions and continue contributing to it.
It also provides a playground because you can also use the living style guide as a place for building, testing, and ultimately demonstrating the implementation. Because the living style guide is installed as part of your application, you can build new pieces of your application and see how they work in isolation via the living style guide, which becomes the place where development takes place, even before it is integrated into the application.
style guide driven development encourages creating reusable components
Reason #2
Something interesting about laying out in front of you multiple items that you want to organize, is that you immediately start finding similarities and differences among them. Based on this, you are likely to create groups (think of inside of a kitchen cabinet: glasses go together, cups go together, plates goes together, and so on. And among the plates, you probably group together small and large ones).
Kitchen Cabinet Organization. Credit: Kitchen from ikea.com
In the same way, when you start storing the different UI elements that you create in your living style guide, you get to see their differences and similarities. This quickly puts you in a mind set of “reusability” as there is no point on creating a new UI element if one like it already exists.
Additionally, because new UI elements are added to the living style guide, making this element play along with the rest becomes paramount. It’s no longer, about making this new button, or side nav for a specific page in your app. Instead, is about making this element fit the styles and patterns established in the living style guide. This is where components come into play, as they are reusable parts of the whole, vs elements created for a “one-time” use.
style guide driven development facilitates communication among teams
Reason #3
As part of building a living style guide a UI language will be developed as well. In a way, when new documentation is added, there is an implicit agreement that this new “widget” has a certain name, or that a “popover” is this dropdown module that behaves like this. Naming UI elements is something that will happen regardless of using a living style guide. However when these decisions are recorded in a place the team has agreed to use as a guide, they become common language and make communications with the client and the team much easier.
And being that you can share links to specific places, styles, or components in the living style guide can save a lot in time in explaining something that can be looked at, and many times interacted with, putting everybody, literally in the “same page”.
Now, one of the main challenges that we have observed when using Style Guide Driven Development is finding time to get a project setup with a living style guide. At Bitovi, we can help you create a living style guide for your project and provide training for your team to make it part of your workflow, without disrupting your team’s workload and efficiency.
That is the gist of why use Style Guide Driven Development in your design process. In the next part of the course we will delve into the Style Guide Driven Development Process.
[wpforo item=”forum” id=”7″]