Published on | Prototyping: From UX to Front End — Medium Tim McKenna

This is the third post in my process series and this time it’s about design systems; specifically how my team is designing, coding, and housing a design system. The main tools I am using for this right now are Figma for UI design, Atom Editor for coding, and WordPress to house the design system. This is by no means the only way or the best way to create a design system, but it is the way my team is currently doing things so we can maintain a high level of energy for the project and keep things moving in the midst of other projects.

First, it’s important to define what a design system is. A design system is a series of components and elements that you can utilize in various combinations. This system allows you to create and manage projects at scale. This system defines the rules and guidance on how these components and elements are used and creates a shared language between design, development, product management, and other business partners.

For our design system project, we’ve identified several roles that we needed to fill to successfully build our design system. First, we need a project manager to keep us on track. This person needs to ensure what the team is creating and building meets the goals and requirements of our system. Second we need a either a design director or design lead that will lead the team of designers who will create the design system and the front end developer who will code the elements and components. Of course, you’ll need a designer and ideally a separate front-end developer. Having two dedicated professionals, one to handle design and one to handle the code, doesn’t overburden any one team member and allows for quick and efficient progress. This is the most basic team setup that you can utilize; one project manager, one design lead, one designer, one front-end developer. Can you do it with less? Possibly…your project manager and your design lead could be the same person, but I wouldn’t honestly go any less than that in regards to team size.

Now could you have more? Absolutely, but you get into the problem of “having too many hands in the cookie jar” and not having a cohesive and efficient team work with all of the differing opinions and approaches. I find that if I have a large team of designers, the best way to include them is through frequent design reviews and critiques. Frequent and productive reviews can help the designer creating the artifacts get valuable feedback throughout the process without duplicated work happening. The project manager and/or design lead might have different roles in the critique such as making decisions for the good the of project’s progress, leading the discussion, and defining the shared vernacular between the team.

Here is how the production sprint works for the design system team.

1) Setup: armed with data about what the team is trying to accomplish (in this case, build a library of components and elements to use for scalable design implementation in our digital tools and assets) the design lead starts a new project in Figma and invites the entire team to participate. The design lead and the designer will have editing capabilities while the developer and the project manager have commenting capabilities only (at first). The design lead works in tandem with the designer to set up the responsive grid system (either CSS grid, Flexbox, or combination of the two) and the front-end developer will between to set up their file structure and begin to bring in various SCSS staples (such as reset.scss, animate.scss, etc.) Our team likes to use Brad Frost’s Atomic Design principles as the basis for our design system, so our designer and developer align their work and folder structure to utilize that methodology.

2) Production: Here’s where the fun begins…the designer and design lead work in tandem to tackle various elements of the design system, concentrating on wireframe level focused elements to build into Figma components. The front-end developer will work on the responsive grid system and test “dumb elements” to ensure everything works well from a responsive perspective. Iteratively, the designer and the design lead will work to ensure elements are meeting the requirements set forth from the beginning of the project. The front-end developer will work just slightly behind the designers to ensure elements are getting coded properly. First the designers will tackle form elements, then interactive elements such as toggles, cards, accordions, etc., then tackle components and design page sections. In between each block of work, the designers will review with the design team to ensure they aren’t being too narrow or close to the project. The project manager will ensure the pace; quality, requirements, and milestones are met with the design lead. The developer will recreate elements from Figma into coded SCSS components and constantly test elements with the designers.

3) Documentation & Governance: Now that all of the necessary wireframe focused elements are coded and designed out, they will be added as components inside of Figma to use for every project with a naming convention that corresponds to their coded cousins in the SCSS files (that way in the future whenever apps or websites are designed, front-end development is incredibly fast.) At this stage two things happen; documentation from the design side and the development side will happen. Everyone writes everything down in pre-establish templates in WordPress. The governance of components will be handled through the project manager and the design lead who will ultimately decide if a pattern or component needs to be retired or amalgamated.

4) Theming: Once documentation of the wireframe focused components is complete, next the designers and developer will work on applying styles to the wireframes components to build components that will look identical to the end product, sort of a lo-fi and hi-fi production. This will entail the developer to create themable SCSS files and build off of the wireframe focused components. The project manager will ensure that everything from the wireframe focused elements are up to date in the WordPress installation and will work with the design lead on formatting and publishing of the rules and guidance on components. The rest of the theming work will fall on the designer and developer (with frequent design critiques with the rest of the team)

5) Wrapup: Now that the theming is “done” (to a point that is acceptable for production use) the team will continue to document their work and publish to the WordPress site that will house the design system. The developer will create rules on how to utilize the design system with Grunt/Gulp workflows and even gives guidance on using it with Angular and React systems. The Project Manager will ensure that all published materials to the design system in the WordPress site follows established standards as part of the design system governance. The developer will zip up all of their files and upload them to the WordPress site for download.

Pros

This process is incredibly simple to follow. Figma is incredibly intuitive to use….so is Atom Editor…so is WordPress. For WordPress I am using the McLuhan theme by Anders Noren because frankly it’s an easy theme that already conforms to a lot of design system layouts, plus I can hack the hell out of it. Figma allows my designers and developers to work very closely with each other.

Cons

This process may be too simple and too abstract and makes too many assumptions. Questions you might ask are how do you setup requirements? How long does this take? How can you ensure quality? Where is your testing? How do you handle design reviews? How do you identify the right team? Is that the right amount of team members? Why WordPress? Why not [insert CMS/tool here]? Why Figma? Why not [insert tool here]? Why Atom Editor, etc., etc., etc.

There are a lot of questions that could poke holes in this process and I don’t discount them. Like I said, there are many ways to do this…and this isn’t the best or ideal way. It’s just one way I am doing it with my team.

Verdict

This is one way to tactically build a design system, a bare-bones framework…and frankly, I am still learning. This is in process right now with my team and we are just at step 5. Will it fail? Maybe. Will it succeed? Maybe? Will I have I redo this? Possibly…maybe…sure. Did I learn from this process? I can say that I have. Let me ask you this…how did you build your design system?

<a href="https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href">https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href</a>

Process: Tools I use for building a design system was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Process: Tools I use for building a design system

Cool stuff, every week

More Articles