IntranetPro
Design System
Grids, colors, typography, icons, and components.
Overview
When I came to work for Codesigned in 2016, IntranetPro was an up-and-coming product. During this time, the company's focus was on custom client intranets. It was a few years later when the company shifted its focus to becoming a product company and we realized the importance of creating and maintaining a design system.
Role
The early stages of starting a design system were done in Sketch where we created a basic grid structure, buttons, inputs, typography, and colors. I assisted my co-worker Zac with this, however, my primary focus was on client customizations at the time.
In 2020, I became the sole designer for IntranetPro and that was when we decided to transition our product from Sketch to Figma, complete an audit of our current design system in Sketch, and create a fully revamped design system and component library. Since we had a short timeline, I was able to work closely with Maciej, who we contracted to assist.
During this time, I led weekly design meetings to review work in the current active sprint. I was a part of sprint planning, road mapping sessions for future enhancements and product features. I worked with the dev team during the design process of new components and conducted design reviews in Storybook as new components were being built out in React.
Tools: Figma, Jira, Storybook
Goal
The goal was to ensure UI consistency, reduce complexity, save time in the long run, and build a foundation that we can always be improving on. This entailed moving our current product designs from Sketch to Figma. We did a lot of contemplating on this, but ultimately Figma had more of the features we were looking for compared to Sketch at the time. This allowed the dev team to access the design system without needing a Mac. We could perform an audit of our current design system, create a consistent naming structure, and create a complete design system with reusable components that make up the product.
Inventory
This was done before our first design system was created in Sketch. We reviewed 130+ screens capturing all elements that we needed to create in the design system. This included all UI elements (buttons, inputs, icons, etc.), all states (hover, focus, disabled, active), and coming up with a consistent naming convention.
Audit
The audit was completed just before we migrated everything from Sketch to Figma. It was important to take an in-depth look at the current system and make sure everything was accounted for and consistent. For example, we had dozens of button styles, inconsistent font weights, and spacing on inputs with labels, and inputs with icons. Some of the little things could have been missed if we didn't complete a full audit. We needed to make sure we were building a solid foundation in Figma from the start.
Naming Convention
Coming up with a naming convention for components and UI was a bit challenging but also necessary to create a source of truth for the product, design, and dev team. This also brought clear communication and understanding between design and dev when meeting to discuss what components/ UI elements are to be designed and built out in our upcoming sprint.
Naming convention for buttons: [Button Type / Button Color / Size / State]
Here we are determining what type of button we are using (solid or outline), button color (primary, secondary), the size (48px, 40px, 32px - depending on use case), and the state (default, hover, focus, active, disabled)
Example: Solid / Primary / 48px / Default
Naming convention for components:
[Component Name / Content Type / Size / Layout]
In this case, we are determining the component name (content card, widget, modal, etc.), the content type (news, events, media, documents, etc.), the size (small, medium, large), and in this case, the layout (grid, or list).
Example: Content Card / Event / Large / Grid
Versions
We are always pushing out new versions of our product, whether that be bug fixes, enhancements, or new product features. Each version is carefully documented in Confluence, and it's important for the design files to stay updated and aligned with this to avoid any confusion. Version names are simple, IntranetPro 2.0, 2.1, 2.2 .. etc. This keeps us all on the same page with the current version we are working on.
Grids, Colors, Typography, and Icons
The foundation of the platform is based on an 8px grid which gives consistency and flexibility to the design and layout. Our color palette, typography, and icons all contribute to the overall look and feel which is modern and clean to highlight the focal point of the intranet, the content.
Components
Components make up the platform. Once we implemented all of our UI elements into the design system we were able to get started on building out some of the components. One of the most widely used components is the content card. The content card shows any type of content that a user has created. This could be a new community update, a news article, event, media, document. These content cards roll up to the homepage feed and are also shown within Department and Community sites. The content card can be shown within a grid layout or a list layout.
The content card component is shown on the left. Here, you will see that the content within the card is what changes by type. In this example, we have an event in the grid and list view showing the various states (same-day event, multi-day event, and an event with no image).
Lessons Learned
Working on this design system allowed me to collaborate and learn from the dev team, learn Figma, maintain organization within the system, time management, and tested my patience 😊. It gave me the chance to really understand what a design system entails and why it's so important.
The design system is by no means complete. It will always be evolving alongside the product as we roll out enhancements and new features.