Component Driven Development

 

and Breaking Down the Design/Development Barrier

The design department (the user interface and user experience kind) has always tried to influence the entire production lifecycle of a product out of an instinctive need to improve upon it from every angle possible. The same applies to modern day page & app design where the design department needs to have input from the very earliest concepts of the product all the way to construction and delivery. In this day and age and in the most forward thinking design departments, we are all designers. For this reason there is more and more overlap and connection between the various departments and indeed a complete breakdown of the siloes and walls when we form agile, multi-disciplined development teams. Here I want to talk about the overlap between design and front end development using component driven development.

Component driven development is all about centralising, unifying and simplifying the design/development cycle. In the simplest terms, before any development starts we have the UX cycle which takes the product from concept to a well researched and tested set of wireframes and stories. These wireframes and stories are naturally closely linked. They are also closely linked with our library of components allowing and developer to quickly read the story, see the wireframes, and then pick the components needed for the view.

After this, in a perfect world, it is just a case of stitching the parts together for a release candidate. This works well in a close knit, multi-disciplined team as well as across teams so that aspects can be farmed out to other offices or even other companies.

The Component Library

Component driven development relies on three main branches coming together at a point where development has a complete understanding of what is being built, together with the component parts required to do so. Here I will talk about the third branch: the component library.

What is a component library? A component library is just another name for a living style guide or pattern library. It is a central collection of all the elements, widgets, colours, fonts, sounds, animations, etc. used to build our apps/pages. In short, if a user interacts with it, it should go in the library. It is formatted in a way that is easy to use, link to, or copy and paste .

There are many reasons for this but here are a few key ones:

• Faster development time
• A common, centralised and unified style
• In part already tested, and so fewer defects
• Better code control leading to better security
• User tested patterns

This marriage and breakdown of departments where stories, wireframes and code are so closely locked together can only lead to improved products both from the business point of view with a quicker/cheaper turnaround, and from the user’s point of view with a higher quality experience.

The library is the design department’s masterpiece. It is what we build and horde and lovingly tender to and refer to it as “my precious”. It is a living document that we update and renew and police. It is a powerful device, but the true power comes from the overlap of design and development. The truth is that a modern, living component library is just as much Development’s and it is Design’s with all the HTML, CSS and JavaScript that can go into them. If we did not break down these borders however, we would not see this new horizon of possibilities.

Conclusion

If you are running a design department and have not already done so, break down those walls, build your nest of components and share it with any and all who are involved. Make it the bible for your wireframes and stories and you and your business will have a much better and more productive time of it.

Note: none of this is to be confused with Test Driven Development, but instead considered complimentary. In fact TDD can be improved by having common tests for individual components.