‘Helios’ Design System development
Project Details
While working at Lightspeed Commerce, part of my day-to-day work as a Senior Product Designer was to develop, maintain and document our Design System, Helios. Helios is a living document - we made changes to it only when it became a necessity, not for the sake of design trends or preference, but when it no longer worked for the user’s needs.
Part of the design system was the copywriting and voice/tone, to ensure it is consistent throughout. We could spend hours discussing minute detail of a sentence!
During my time in this role, the company went through an acquisition from Vend to Lightspeed. Helios was chosen as the flagship Design System, so our design team worked to rebrand it. During this refresh, I advocated for and successfully implemented changes to the colours, text and contrast to meet more of the WCAG accessibility guidelines.
I’ve included here just a few samples of specific areas and elements that I worked on.
Action Bars
The ‘Action Bar’ is an element that exists on most pages of the Lightspeed Retail POS software.
I was driven to make changes to this element after noticing that they were inconsistent in different pages throughout the app. After discussing with the team’s front-end software engineer, we found that we could create a UI element that could be re-used across the app easily - it just hadn’t been made yet.
Once I had collated the variations, I took it to the team to workshop the use cases and needs. This process involved many conversations about the difference of having 8px or 16px padding around our button (I love lengthy chats at pixel-detail level!), and the precise animation of how an Action Bar moves up and sticks to the top of the page when a user scrolls down. After defining and documenting exactly how the Action Bars should look, I shared the information with the software engineering team, who were able to implement the changes in the framework.
Shown below are samples of the documentation, where I have included direction for many possible use-cases, including how the Action Bar looks in smaller viewports, and sizing specifications.
Notifications
I also spent some defining the types of notifications that were used throughout the software.
The documentation needed to be clear to designers what type of notification should be used where (a dismissible ‘Toast’ for feedback on a task being performed, or a page-width banner to provide a call to action or recommendation, which are not dismissible until the user has taken action.
Part of our consideration was how the notifications act when a longer amount of copy needed to be shown, as this had caused issues in the past when text was too long to fit into the area provided. I think it is important in these situations to prioritise clarity over aesthetic looks - we must provide clear information to the user to help them, so it is a requirement to have the notification show the full copy rather than force a short sentence.
