Style guides exist to keep brand frameworks together. And they’re especially valuable now, when we have more platforms to design for and screen sizes to accommodate. Every project demands consistency, and the more avenues we design for, the harder it is to consistently maintain and evolve a brand.
The quality of the finished product depends on how well the team understood the vision and saw the product as its own system. Seeing the product as one, cohesive piece is essential. This is easier for smaller teams who have a few graphics and lines of code as reference. In big projects, though, the requirements shift. For small projects, the main goal is delivery, with large ones it’s workflow. This is why a style guide is so important.
To make it easier for teams to stay on track and within style, we’ve developed Styleguide on Github—a service that lets people create and manage their own style guides.
Style guides are often created as PDF files, which makes updating them a matter of reassembling the entire document. While HTML-based style guides are easier to maintain, they only serve users who know how to code.
Both of these methods had issues that made them feel outdated and unable to keep up with today’s demanding state of design. So, Styleguide improves on those oversights and automates the process so team members can focus on their tasks without distraction.
We ran user testing during the development of Styleguide and found that rather than catering only to developers, we needed to suit three tiers of users. By building for the person who would need a style guide in its simplest form, we satisfied all user types, such as those with:
- Little coding knowledge (usually the intern or designer)
- Some coding knowledge (prototyper or junior developer)
- Good coding knowledge (developers)
Styleguide can be useful in two different scenarios:
- Starting Styleguide: Often, the development and design teams work together from the beginning of the project. While the design is being created Styleguide is being shaped with basic elements such as color and typography. Instead of having the starting point for the developer being a project of its own, each block, module or component is developed inside Styleguide. You can also reuse modules throughout the project. In this case Styleguide and the product are always in sync. Styleguide becomes the source of truth for the entire team.
- Sharing Styleguide: If you already have a product, Styleguide serves a slightly different purpose. Another team can take over the development and need to maintain the product's identity, making elements within Styleguide essential for those who aren’t familiar with the work.
Work in progress.
Styleguide is a living tool, and features are being added and developed constantly. Today, it is a tool focused on minimizing repetitive work based on common user actions.
What it offers now.
- Just one click to start Styleguide automatically.
- One click to compile to static HTML.
- Menu generated automatically from the folder structure.
- Modules files imported from the folder structure.
- Live reload.
- Demonstration of breakpoints.
- Configurable breakpoints.
- Automatic last updated date.
Creating pages inside Styleguide, or making it easy to use together with different technologies, like client-side frameworks, is essential. As we use Styleguide in our own work, we see how we can reduce the development time and build the following for the next phase:
- Modules as pages and not only blocks.
- Friendly module reuse (or atoms and molecules) inside Styleguide.
- Modules library, making it easier for reuse in other Styleguides.
- Sub-menus and hierarchy for modules.
- Different layouts for Styleguide.
- Integration with external tools.
- Live editing, making creation easier and minimizing code usage.
The creation workflow of digital products is something that can be always improved. Opening up Styleguide will allow us to create even more ways to ease the integration with other types of projects and languages.