Style guides, component libraries and documentation: describing things and creating conversations

Published 10/12/2014

The technology around us is changing fast. What is not changing fast is people and processes that govern how we work together. All the best projects I’ve worked on had one thing in common: great communication, regardless of the odds. Thus one of my favourite trends recently is more focus of how visual designers work with software designers. We have a lot in common - we both work towards building a living, evolving thing by producing snapshots of it in time. Effectively though, the language, the culture and processes are different (it's easier on teams with cross-disciplinary and full-stack people) so often a lot of time is spent explaining our problem domains.

Style guides & component libraries are powerful tools to help with this. Their aim should be to create a visual language that both groups can use to iterate on ideas. Properly made, they enforce focus on granular elements of the design as well safeguarding design consistency. They allow for experimentation out of the context. There is place for the design rationale and usage patterns. This helps enforce modularity (because large, problematic components become quickly apparent) and expose certain kind of problems early (like duplication of patterns, coupling, poor rationale etc).

It's not easy to keep any kind of documentation up to date. But this is because it is often an afterthought. It needs to be part of your and the team's workflow. It should be easy to contribute and use. Automate all that can be automated and a lot of the traction needed to create it will go away. Put it in the center of what people do.

Executed properly, documentation, style guides and component libraries promote conversations and improve communication within a team. And on web the platform, where trends change with seasons a team that is flexible, open and can communicate efficiently will have less problems adapting and can achieve better focus.