Thanks to fellow designer Mike Scopino for including me in Nonfiction’s recent blog article “Expert Perspectives – Let’s Talk: Live Style Guides“.
Guests included Josh Briley, Vanessa DeCollibus and myself.
How do you define this resource? In other words, what do you call it, and what’s in it?
JAMES YOUNG: The audience for our resource is a bunch of globally distributed sprint teams within a big company that moves at a fast pace. So we decided to follow how the developers that were leading the project were comfortable referring to it—as a UI component library.
JAMES: We’re using it as the source of truth. We’re saying that the source of truth is no longer drawings of screens or components in Sketch, it’s the implemented UI that’s on our staging environment. In the past, our guidelines might have just been visuals or only a reference, but we still had to re-create the work. Now it’s copy and paste, and we’ve got a component.
What is your elevator pitch for why you need a live style guide?
JAMES: For us, the benefit is trying to get our sprint teams more closely aligned. We’re a big company, so not all of them are in the same location. People can just copy a code snippet and over time that will result in more baseline consistency. It’s also an entity with a process in place that can help us move toward consensus on where we want to go with certain UI elements.
JAMES: In the past we were like, “Well if we don’t see a design for it, we’ll just build it and move on.” The proliferation of inconsistencies could grow and grow. Now the style guide provides a clear structure. Work is tracked and considered. We are saving time and gaining efficiency, because we can lean on the style guide to
start informing any new pages or components that we need.
Which comes first, the product or the live style guide?
JAMES: We’re running the product development in parallel with creating the library. I don’t think there’s a right or wrong way to do these things. We took an approach that was appropriate to the way that our teams are configured.
JAMES : We literally treat it as a product. It started off because we didn’t have any preconceived notions. We started off with a small team dedicated pretty much 100 percent to figuring this out. Our goal was to just run it as its own product to support the teams. We did get a bit of a head start, but not a long head start, to take care of some of the basic atomic features of it—you know the “atoms and molecules.” We got those things that you can easily anticipate people needing in place, and we are working from there in parallel with
the product.
Can you share an insight you gained in creating your live style guide that surprised you?
JAMES: I think what may have surprised us a little were the places where there was a disconnect between the theoretical and the application. The UI library could have some stuff in it that works in theory but then we’ll find in practice it needs to be fixed. Also really understanding that this is a living guide, that the library is not a strict, sacred guideline. Just because something is in there doesn’t mean it’s perfect. But our hypothesis that we’re still testing out is that when we need to refactor or pivot direction on certain UI controls, it will be easier to roll those changes out across a bunch of different teams. I have a feeling that the pace of development is going to pick up to the point where we don’t want to be a bottleneck. If other teams need to develop a new component, we’ll pull it into the library. We might be refactoring it in the process then communicating that back out. But adding it into the library assures that all those refinements are a part of
future releases, and that’s the real goal for us.
What advice would you give a product owner that doesn’t yet have a live style guide?
JAMES: Don’t just jump in head first. Familiarize yourself with what this tool can do for your organization and your team. Different businesses have different needs. And some businesses just don’t need a style guide to get a product out the door.
JAMES: You’re not just adopting something to check a box but you’re actually building a system that works day to day for your team. You can capture what you’ve done in the past, and try to forecast the types of things you might need in the future. But expect it always to lag behind the innovations your team is making, and make it flexible enough to capture those. It’s a big job, so allocate support to develop it and maintain it. Also, try to do a good job of communicating what this resource can and can’t do. It’s not a magic UI machine. You’re still going to have to go through the really hard work of translating it into an actual product.
Read the entire 2018 archived article.
