Style Guides, So Hot Right Now

Ben (developer) and Tim (designer) are building a design system to drive consistency across the global development teams at Aconex.

In this presentation, they’ll look at emerging tools and strategies that drive collaboration at the boundary of design and development, point out some pitfalls you might want to avoid, and help you evaluate the right approach for your team and organisation.

As Aconex scaled, they found that things that worked for design in the early days just didn’t work any more. Word docs, PDFs of design rules, etc… these were not enough. A retro on a project showed they needed a systematic approach to design.

Devs would spend time building minor variations, because six different teams with different designers weren’t aligned. The placement of primary buttons, simple things like the design of a loading spinner… none of it was aligned.

By 2015 it became almost impossible to onboard new designers. “How do I do a modal?” Well… there’s some info over there… a bit over there…

They tried to unify it with Google Docs, again in Confluence, another in Drupal… but nobody ever kept it up to date. It was essentially useless. They tried a live style guide, although it did end up being one gigantic page documenting everything, but it was not much use for designers.

It showed devs how every possible existing thing worked, but it didn’t say how they should be. Style guides were the hot new thing in 2015. Could it be the thing that sat in the middle between devs and designers?

They figured they needed to convince the business that this was what needed to happen… but then discovered the founders were saying that’s great, why aren’t you doing it already?! So it had the blessing of leadership… it needed a champion.

They use the open source model:

  • Consumers who use it and comment on issues
  • Experienced contributors who create PRs
  • Core developers who merge PRs and manage the project

This applies to design as well. There are custodians of the design, then contributors (designers embedded in teams).

So they built their first pattern library; although they did have issues getting contributions from designers, who couldn’t handle the dev aspects of the doc project. So they use Confluence to research patterns; discuss ideas on Slack; only the actuals go into the library.

Meanwhile devs had issues where they might submit a PR but it might take some time to get things merged. They resolved this by letting each team run its own local set of extensions. Teams can move really fast; but the risk of course is that they can go off on their own design directions. The core library just handles the completely shared stuff. They did try having teams run off forked versions of the library, but that didn’t go well and they came back to versioned modules.

Now when design patterns come up in a team, opportunity to make something better is pushed to Slack for discussion. When the research comes together, there’s a fortnightly check in to talk about them. Ultimately there’s a lot of trust that the designers have made a coherent decision before pushing an idea to development.

Initially they thought they’d just make Bootstrap-for-Aconex, even tried reskinning Bootstrap. But they ended up doing their own library and were really glad they did that. An illustration of that is the icon naming – Bootstrap names according to what the icon looks like, their own library names according to purpose.

When you build your own, you build it specifically for your own company.

They did think they could get to something truly brilliant very fast – thinking of the Apple HCI guide, Lightning, etc. But they found the team dynamics need heaps of work, the deliverables come after that.

The style guide doesn’t just capture how things work, they also need you to figure out great ways for people to work together.