# All channels
Design systems and style guides and pattern librariesMarch 23, 2017 at 6:00am
Do you use one? How well documented is it? Do you cover all cases of a certain component? Do you break it often?
We are building one at the moment and our team has long discussions around how much we should scope out and future protect our designs. We've got a good vision and also have a nice plan for execution. Just curious to know how others here have found working with or on such projects
March 23, 2017 at 8:46am
Here at Spectrum we're currently building it out as we go along. Seeing how fresh the platform is right now it wouldn't make sense for us to spend a long time on scoping it out and building it in isolation, we just extract components that we use throughout different parts of the app into a shared folder. In the future we might spend time cleaning it up and documenting stuff, but for now it's more impromptu rather than planned. (at least on the code side, maybe Bryn and Brian do have some master plan in terms of design 😉)
March 23, 2017 at 5:38pm
Yeah it seems like style guides and systems are correlated to the size of the project or team. Since we're just 3 people we all see every new bit of code that gets pushed, which helps us build our own internal contexts. But that'll break after a handful of people
My general thoughts on style guides is to build as you go and don't overthink them. They will never be "done", so not treating it like that during the design process means you can move faster and not get so hung up on the details4
March 24, 2017 at 2:51am
Tackle one component at a time - get the most basic button system designed and built. Ship it. Then do inputs. Then links. Then modals. etc etc2
I'd probably do the same with legacy - just start identifying super small components that get reused across the code in a non-shared way
March 24, 2017 at 5:34pm
A big piece of the puzzle with legacy is inconsistency, right? There are old components that need to be pulled into adherence with new design patterns, which you are defining from the bottom up. Brian's approach essentially suggests finding the simplest thing(s) you find correct enough to build on, and go from there. So if you are going to build everything around an 8-pt grid, you might start by making variables for 8px, 16px, 24px, and so on - since these are going to be monotonic units, maybe you call them $mu1, $mu2, $mu3. Then you find a simple component, say, a button - used throughout your app, and give it $mu1 (8px) of padding all the way around and ensure the margins are treated accordingly, and you get your typography and colors and corner radius and all that abstracted into "atoms" that can become part of a pattern library.2
You don't want to start fancy with legacy systems, because you'll just break things. You want to codify / make a more manageable version of all these components by extracting the elements of the ones you choose to start with into atomic "truths" of your Design System (notice the capital letters). It is a bit like the approach veteran type designer Matthew Carter takes in creating a font: "The letters that I like to start with are the ones that embody the most information that I can then reuse and extrapolate from. People think, “Oh, I bet you start with G or capital Q,” where you can have some fun. The absolute contrary is the case. I start with lower case h, lower case o, lower case p. In fact, I would probably do the capital Q as the very last letter because it doesn't tell me anything about the other letters."
His approach to type design is a lot like what I would advocate for creating design systems for legacy products; it is rare that you have a full product Design System without a product, right? So instead, you start creating the actual thing, but you *pay attention* as you do it to being systematic and applying principles of constraint and consistency and future-compatibility. Because those guiding principles are going to make their way to the written principles of your Design System, and the constraints are going to keep things from getting crazy when you have a larger team, and the consistency is the bedrock of your system.
Wonder if image URLs will render...? http://playgallery.org/images/uploads/gallery/Matthew_Carter_HOP.jpg
Loving all the responses! I'm in the same boat. We have a lot of legacy code and styles some are bootstrap a lot are custom off of bootstrap. We've been talking about moving to react and building out all of our components to ensure a better reusable style guide. So far we haven't come up with a grand solution, but you've definitely helped me think about how we can solve it.
I'm curious to hear people's thoughts on using a framework like bootstrap,foundation, a pre built react components library or going custom and building your own from scratch?
I really enjoy studying frameworks just to see what kind of props and variants they've accounted for...i.e. loading states, null states, error states, disabled states, etc...studying that kind of system helps me to prepare better as we build out our own custom components
In terms of rolling with a premade framework or building your own, it seems like it mostly depends on the team's bandwidth and legacy that needs migration? probably fine either way, even if bootstrap gets a lot of flak in the tech community