Benefits of a connected design system

Over the past year, I’ve been working collaboratively to build a design system at Lost My Name. We’ve worked to define new workflows and processes that bring design and engineering disciplines closer together. I wanted to share some of the ideation behind the project and what the benefits of a design system have been for us, as a smaller organisation so far.

Our living documentation: design-system.lostmy.name

A bit of background

We’re seeing more and more organisations, big and small, empowering design teams to think more systematically. Couple that with the adoption of declarative JavaScript libraries, such as React and Angular, we’re able to unlock new ways to use web components to design, build and maintain interfaces.

This shift in approach is pulling design and engineering disciplines closer together, aligning workflows, and fundamentally changing the way teams communicate with each other.

Many designers and design teams will be used to working with sets of rules and guidelines. We’ve seen terms such like UI toolkit, pattern library, style guide, living style guide, or design language system. But, where does a design system fit within these classifications?

Style guide: A set of documented design standards for an brand’s visual design assets. A style guide is used to create continuity and consistency of design assets across an organisation.

UI toolkit: Pre-defined UI components in an editable source file (such as Sketch / Photoshop) that designers can re-use, reference and evolve. Specifically built to support the creation of UI in a design team.

UI pattern library: A functional, coded version of a UI toolkit that have been defined by design and built by developers to allow for duplication and easy implementation of repetitive UI elements in code.

Living style guide: An accurate, live, coded representation of UI that’s depended on by design and engineering teams as the source of truth for UI components and visual brand assets on live product environments. It’s regularly updated and maintained.

Design system: A holistic, strategic approach to design across an organisation. A design system includes or informs the creation of a style guide / toolkit / pattern library / living style guide. It governs consistency, enhances re-usability, and makes UI maintainable at scale by powering UI from a single repository.

* These classifications were a little harder to define then I had expected, given that the meaning of the terms are changing over time. Would love to hear if you have anything to add or suggest an edit to the above :)

Why

It’s worth touching on why we explored a systematic approach to design at Lost My Name. Working in a growing start-up is fascinating and I’ve watched as the company has learnt how to ship features and iterations quickly. However, continuity in the customer experience took a tumble as design and engineering processes reacted to scale.

Leaning on atomic design principles, we changed our thinking towards a set of repeated rules, patterns and components. Building a set of tools and beliefs that design and engineering rely on, use daily, and embed into workflows.

By no means, however, did a shift in mindset happen overnight, this is our 3rd attempt at unifying the disciplines. The front end team started to move our view layer out of Rails over to React, making us much more component oriented in the code. At the same time, design moved from Photoshop to Sketch and started to build out a component based UI toolkit and style guide. This project became more and more achievable for us this time around as tooling and processes between the two teams edged closer together.

Marc has written a fantastic piece on how we ended where we did, and some of the history of the project. As well as a deeper-dive into the technical aspects of the project 🎉: https://medium.com/@mrcthms/lost-my-names-design-system-adventure-ddaf20f72deb

Our living documentation ( WIP 😬)

We’ve been working to create a centralised hub for showcasing our design rules, beliefs, and front-end components. We’ve taken all the parts of the UI that are continually reused across the site and have created a way of powering them from a single source in the code. Here’s what we’ve achieved:

A living, cohesive design language: An update to any React component in the design system will roll out across every Lost My Name application, reducing variation and inconsistency in experience across our interface.

More efficiencies: A single-source approach to building out our interface means we can create and iterate faster, empowering engineers to implement design changes and deliver basic features with minimal upfront design work.

Maintenance: Each designer and engineer works with the most up to date UI patterns, principles, and guidelines to maintain cohesion across the teams.

Reliable documentation: The creation of transparent and clear reference documentation for front end developers to confidently work from.

Our living documentation can be found here: design-system.lostmy.name

From within our component library you’re able to access the component control panel where you can manipulate all of the available component parameters. The component control panel also allows you to preview a component within the context of a viewport, offering a preview of the component at the upper and lowermost boundary limit of a viewport. Take a look at the Button component and try it for yourself.

I’ve also written a little bit about how we maintain and use version control to manage our design files using Sketch and Github to keep everything in sync. Take a look at that here, if you fancy: https://medium.com/making-lost-my-name/maintaining-our-pattern-library-1d5b2e56372e

Benefits for Design:

• Core UI consistency: We’ve substantially reduced inconsistencies across the core site UI. Creating an accurate pattern library that’s synced between the team (and reflected in the code) has meant we’re working with the most up to date UI patterns in our design files.
• Defined beliefs: This project has given us a chance to reflect on our team principles, what we want to achieve through design at Lost My Name, and what over-arching ideas/goals we want to lead our decision making.
• Questioning the documentation: Spending time documenting each component felt a little banal. However, we’ve seen the detail in the documentation questioned. Writing down behaviour and principles has meant we’ve identified gaps in the library, or uncovered the need to create a new component. Component documentation keeps conversations happening and the evolution of the library to be more considered.
• Design + Engineering 😍: The most important outcome of this project so far has been the alignment of the design and engineering disciplines. We’re finally moving forward together, working in similar process loops, and creating efficiencies collaborativly.

Benefits for Front End:

• Minimised code duplication: Building reusable components and holding them in a single repository has substantially reduced our code duplication, and need to write or re-write code for pre-exsiting UI components. It means now we can use the same code every time a component is used across multiple environments and applications.
• Universal guidelines: Clearly documented code standards and guidelines means every developer working with the design system can rely on clear definitions for how to implement code & components.
• Visual showcase: We’ve created an easy way to showcase all our UI components visually and interactively.
• Codified design: Versioning the component code (using npm) means we can capture snapshots of how the designs system evolves through time. As we realse a new version, the old versions persist. A super nice way of being able to quickly see how far we’ve come, how we did things previously and easily rollback or recover old components, if needs be!

Where we’re at

What I’ve come to realise is that we’ve started to build a translation layer. A layer of design and engineering tooling, process, anad documentation that serves as mutually understood framework. By collaboratively building a design language and supporting system, we can better speak the same language. With this comes more opportunity to frame discussion in the correct fidelity and work closer together to build better products and define new methods of collaboration.

The adoption of our design language across other functions in the business has also been super encouraging from a design point of view. By empowering people from all over the organisation, we’re changing the way people think about design. We’re seeing product managers diving into sketch and using the UI toolkit to help communicate their ideas. We’re seeing marketing teams working directly in sketch templates, sharing, exporting and handing over assets and copy for web. And, we’re seeing our principles and documentation challenged by other design disciplines, creating conversation, and pushing us towards more thorough and considered experience.

This project was a labour of love. Initially it sat outside the product roadmap. It took a ton of convincing, a lot effort, and some late nights to keep it moving forward. It’s meant that at the heart of the project there’s a passion to make it work for our team. To make sure that the thing we were building was useful and enhances the way we work together everyday, and I think we’ve made a good step in the right direction.

I would love to keep this conversation open, and I’m super keen to hear about how you and your team are solving similar problems and what approach is working for you.