Living diary: Workflow of a Design Language System (DLS)

Hey there! Seems like you found my diary☺ I️n here, you’d find me documenting design decisions and my journey of creating a baseline DLS.

The Vision

With the goal of standardising and optimising our team designers’ mindset and practices when working with a Design Language System (DLS), a group of us, designers and creative technologists, came together to form an interest group. Our aim was to dedicate time, apart from our time on projects, to create a foundational DLS that would serve as a guide for teams, informing best practices and providing an exemplary framework that could be further customised or scaled.

What? Why?

We have a sizable team of designers assigned to various projects, and aligning design standards across team members from different regions poses a significant challenge. This isn’t to suggest that all regional projects must adhere to rigid standards of a single DLS workflow, as project characteristics can vary. However, recurring gaps occasionally emerge, and it’s essential to address them. Question arises:

“How do we establish guidelines? When and how should we decide which components to include in the library? Who needs to be onboarded? Different designers are constructing components in diverse ways — what is the ‘right’ way? What is the one-source-of-truth?”

Rather than simply passing templates from project to project, we should invest time and rigorously evaluate the reasons behind our approach. A ‘cookie-cutter’ method doesn’t always fit every project. While many of us are well-acquainted with the purpose and goals of the living repository, how do we guide new members who are tasked with delivering a DLS and bridge gaps?

If you’ve been following along and are still wondering about the term ‘DLS,’ let me clarify it now. A Design Language System (DLS) is much more than a design library on Figma; it encompasses a broader spectrum, including the coded library and all elements that influence the product’s expression. This implies that it involves multiple stakeholders and contributors. Therefore, establishing and maintaining a DLS is not the job of a single person; it’s a collaborative effort. Its primary role is to support brands in accelerating development and maintaining the quality of digital products across various platforms, ensuring a consistent and cohesive user experience.

//

The Kick-off

The kick-off activities included:

1. Setting group expectations
2. Defining scope — determining DLS-related boundaries to address
3. Identifying required support
4. High-level prioritisation of tasks
5. Establishing a timeline and plan

Information Architecture

Starting with the overarching structure of the DLS, we delved into its core, the Information Architecture (IA). Recognising that a well-structured IA is fundamental to improving users’ access to core components and enhancing their understanding of how to utilise and adopt the DLS. (More details to be composed soon)

Organisation

The DLS will commence in a centralised mode, with rules and processes governed by a dedicated team. After the release of beta version 1, the DLS will transition into a semi-distributed mode. This transition allows us to collect feedback from all users, who will also play a role in enhancing and evolving the DLS.

// To be continued