Embracing the process: Learning to slow down to deliver clarity
I’m new to the design system’s team at Lyft. After 6 years of working as a feature designer, I decided to make the jump to design systems and I couldn’t have picked a better design system to learn from.
At my last gig, I built out a component library, but I did so as a side project unsupported by leadership and with few engineering resources. Sound familiar? In a world where most designers have to advocate just to spend some time componentizing, I feel very lucky to be at an organization with a mature design system. Our design system, Lyft Product Language (LPL), has org-wide buy-in, a fully stacked team (complete with designers, a design program manager and engineers), thorough documentation and meticulous processes.
Coming from the world of urgent product deadlines, I was accustomed to pushing through the design process at lightning speed. However, my time at Lyft has taught me that design systems and product teams have distinct rhythms. The design system should maintain its focus on delivering high-quality work without being pressured by fast-paced timelines, while product development should continue its momentum without being held back by the design system’s schedule. At Lyft, balancing these two areas is essential to achieving harmony.
For my first LPL project, I was tasked with building a validation message component. Validation messages provide clear and actionable feedback to users, help them understand the context and implications of their actions, and guide them towards resolving any issues or errors. They are typically paired with input components like form fields, but can also be used by non-input components where applicable. It was a relatively simple project, chosen to help me familiarize myself with our distinct end-to-end process.
Although it took some time to wrap my head around spending weeks investigating a small component like a validation message, the LPL process with its many checks and balances allowed me to slow down and ensure that nothing critical was overlooked during the design process. The highly collaborative nature of everything we do facilitated open discussion and review of everything I designed, maintaining the integrity of the system.
The LPL Project Process
Step 1: Project Brief
Every project begins with a detailed project brief, created collaboratively across the design systems team and any other relevant stakeholders.
Since this was my first project, the project brief had already been written. Initially, the validation message component was named “sentiment message.” There was existing documentation using “sentiment messaging” as a term, and some components, like text fields, had their validation messages labeled as “sentiment” in both Figma and web. However, the project brief revealed confusion about the scope of this component. Would it be user-initiated or system-initiated? Could it address empty states? What exactly did “sentiment” mean?
Step 2: Audit
Once a project is green-lit and prioritized on our roadmap, we kick off a crowdsourced audit by sending a call out in our Slack channels across the organization.
During the audit, it became even more clear that the broad nature of the term “sentiment” caused confusion. The expectations of what problems this component could solve were painted with a broad brush because its name lacked specificity. We were trying to solve for too many use cases, thus adding complexity to our discussions on how to design the component.
In this stage, I conducted a competitive analysis, investigated our current naming conventions, and crowdsourced an audit of use cases across the organization.This led us to uncover that while this component had already been built in iOS and web, they each had unique names. Moreover, in Android, they did not have a standalone component built at all.
Naming a component might seem simple, but if not thought through, it can cause confusion, inconsistencies, and difficulties in maintaining clear documentation. Now was the perfect time to get alignment across platforms not only on what we called the component but also on the specific use cases it solved for.
Step 3: Project Kickoff
We utilize one of our biweekly review time slots to hold a kickoff meeting, ensuring the working group is aligned with next steps across both design and engineering.
During the project kickoff, I presented my findings from the audit. With a broad name like “sentiment message” it was not clear whether or not things like help text should be included in the component. By making the name more descriptive we would be able to change the understanding of this component from one that simply conveys sentiment to one that conveys sentiment in response to a user’s actions. During this meeting, the working group agreed to rename the component. Applying systems thinking early on made our component simpler to scope and build. We now knew that we would be removing help text and empty states from the scope of this component. Moving forward, this component would be called “validation message.”
Step 4: Design
In the design phase, we work on solving the root of the problem, designing solutions that meet our quality standards. This phase includes multiple reviews with the entire working group and feasibility reviews within the design systems team.
Systems thinking allows us to identify root causes, feedback loops, leverage points, and unintended consequences. Due to the emphasis on alignment early in the LPL process, I could apply systems thinking at the outset of the project, thereby avoiding potential confusion among system users.
During the design phase, I used systems thinking to consider all different use cases for validation messages. While the component itself is relatively simple, the ways in which it can be applied and the vast number of other components it needs to be nested within can cause complications.
I had to contemplate things like content design (in-product style) or spacing all while considering the nuances between platforms. For example, due to the more complex use cases we needed to address for our web products, I established that we should have the mobile component max out at two lines while the web component would allow for three.
When you have a component that is used by so many other components, flexibility is key. This is why I landed on removing all padding from the component, allowing for any spacing required to be built into any parent components as needed.
Step 5: Design Documentation
We draft design documentation in Google Docs, which may include technical specifications not covered in design reviews. The document is shared in a designated Slack channel for internal review. If comments aren’t resolved asynchronously, we schedule a review meeting. Once approved, we publish it on the LPL site.
Once all edits had been finalized, I wrote our documentation in Markdown. Writing in Markdown via VS Code and using Github were all relatively new to me. So this part of my journey involved asking a lot of questions and doing a lot of Google searches. It’s not rocket science, but it definitely helps to have educational resources at your fingertips. At Lyft, there is hands-on training with Markdown that really helped set me up for success. But it also helped to have a Markdown 101 cheat sheet at the ready!
Step 6: Design Handoff
The design phase ends with an engineering kickoff, where the designer reviews the documentation, interactions, and Figma library with the engineers.
Creating the actual component in Figma was relatively simple. However, integrating it into other components like text fields, text areas, and dropdowns presented some challenges. This was especially true for the web, with its many different input field types.
Design system components have a large impact across other designs, providing opportunities to solve unique problems. This led me to learn new tips and tricks in my tooling and optimize my design workflow.
The first challenge was replacing all existing messages in the input fields with the new validation message component. Selecting each layer was a daunting and tedious task. Collaborating with Figma super users on the design systems team boosted my efficiency. For example, I learned that holding Shift while clicking into a layer in Figma highlights all similar layers, making them easier to select.
After swapping out the old components for the new one, I realized that in many instances, the new component retained the name of the older component. I reached out to our resident Figma expert, Mordechai Hammer, and learned about Figma’s built-in renaming functionality. Selecting all the layers and hitting Command + R made the process much simpler.
Step 7: Sendoff
We review the final product with the project working group and ensure all loose ends are tied up or handed off.
During this phase, we QA’d the built components and it was a pretty smooth process thanks to all the work and collaboration the working group had done leading up to this point.
Step 8: Inform
Finally, we send out communications to all relevant stakeholders to inform them of what to expect. The documentation site updates are also deployed.
In order to inform our users of this new component, I posted an announcement on the homepage of the LPL website, put out a communication on our Slack channel (being sure to highlight any breaking changes) and presented about the component at our monthly All Hands Design meeting.
Final Thoughts
Following this meticulous process was immensely beneficial. Not only did this process ensure that there was consistent adoption of validation messages across product teams, but designing for LPL has helped me unlearn moving too fast, flex my systems thinking muscles, and optimize my workflow. Reflecting on my journey so far, I am genuinely amazed at how much I’ve learned in such a short time, and I am eager to continue uncovering new insights and skills.
Have you contributed to a design system before? If so, I’d love to hear about your biggest learnings and the challenges you faced along the way.
This article was also posted in Lyft Design+.
