As creators of guidelines, our Design Systems team is compelled to follow them. Not just ours — WCAG, HIG, Material Design, Android Auto… the list goes on & on. This is expected, table stakes, for our team because it has been and continues to be a huge selling point for our system. “Use Lyft Product Language and get guideline adherence for free!” But what does that actually mean when that isn’t the expectation of feature teams?
When feature designers follow guidelines, especially ones around inclusivity, they are seen as compassionate, empathetic — going above & beyond — vs meeting expectations. So many don’t. Not because they don’t care, but because it hasn’t been prioritized and they don’t have the time, so the responsibility to adhere to the guideline falls on someone else. Therein lies the guideline gap: what is prescribed versus what is enforced organizationally.
By not holding designers accountable internally, we open ourselves up to external consequences. Designers avoid facing the consequence because engineering protects them — and the gap between the two disciplines widens.
After chatting with other Design Systems’ teams we realized that this pain point is shared by many. In the end it comes down to the fine line between what is suggested vs mandatory and how you ultimately educate and enforce those rules.
Common UX guidelines
Similar to many companies, Lyft has a variety of guidelines that its employees are expected to follow to varying degrees. Our main guidelines include:
Quality Principles — Lyft leadership’s definition of quality.
WCAG 2.1 — Web Content Accessibility Guidelines (WCAG) 2.1 defines how to make Web content accessible to people with disabilities that can often improve usability for users in general.
Localization — Defines how to adapt products to ensure they’re culturally appropriate — familiar languages and environments.
Road Safety Guidelines — Pulls from Android Auto & the Human Factors Design Guidance for Driver-Vehicle Interfaces — both define how to design for driving.
Brand Guidelines — Defines how the Lyft brand manifests across our marketing and products including our mission, vision, platform, voice, tone, logo, colors, illustration and iconography styles, and motion.
Content Guidelines — Building off of the more high level brand guidelines, we have additional more detailed guidelines for UX writing, illustration, and iconography.
Education & enforcement over time
In a perfect world, feature designers & engineers know, understand, and create with guidelines in mind. There is no need for guidelines checks throughout the product / feature creation process.
Unfortunately we don’t live in a perfect world and guidelines require a considerable amount of reading and comprehension in order to effectively put them into practice. When guidelines aren’t outlined as requirements to launch by leadership, it’s difficult for feature designers and engineers to prioritize the time it takes to learn. Especially if there are no consequences for not adhering to them.
This is where design systems usually step in. Lyft’s Design Systems team created an internal tool, Lyft Product Language (LPL), to make the guidelines easier to follow. Foundational elements and components follow the guidelines, so feature designers and engineers get a large amount of adherence for free. In our most recent survey, 98% of designers and engineers agree that LPL has delivered on efficiency and consistency.
However, it is a common misconception that by using the system that you have followed all of the guidelines. Not all guidelines can be encapsulated by the design system & need to be defined or documented within the feature itself.
For the sake of clarity, for the rest of the post I won’t show it in this chaotic way.
But not everyone followed LPL and, in turn, did not follow the guidelines. Design Systems made following LPL mandatory using linters — a bold choice. This decision, whether or not we knew the weight of it at the time, turned these guidelines into policies. They were no longer general recommendations, they were mandatory and had consequences. Teams couldn’t launch unless they complied.
The foundational elements that are enforced (color, typography, and iconography) through linters have a high usage rate. LPL components are used the majority of time, and we have seen an uptick over the past year with folks using them all the time. We continue to see engineers receiving designs that could be LPL eligible but not adhering. The top action engineers do when receiving these is pushing back to design to use LPL (or just using LPL and not telling design).
It is also worth noting that there are many guidelines that are not linted as part of LPL.
LPL Linter can’t catch everything. Last time with the chaos picture, I promise.
The guideline iteration loop
This has created tension between the two disciplines. Here is a real example that happens frequently:
Designer tells the engineer, “Here are the designs! Sorry, I didn’t have time to spec them.” at handoff.
Engineer thinks aloud, “I had to hack LPL a bit to make this how the designer wanted…” when submitting the PR.
The linter reports to the engineer, “Follow LPL! Hacks break guidelines.”
Engineer tells the designer, “LPL won’t let me do these designs — can you redo it using LPL?”
By the time this information gets back to the designer (IF it gets back to the designer), they’ve moved onto a new project. It usually falls on the Design Systems team to assist the engineer in fixing the issue. Captured in this narrative as well is the misbelief that LPL, the design system, created the rule vs something that the team should be following outside of LPL. This creates tension between the Design Systems’ team and the feature team — we have a separate solution for this.
Closing the gap
Design Systems and various task forces have attempted to make quality appear mandatory to designers through onboarding, classes, handoff checklists, and Figma plugins (like LPL Lint) to shorten the iteration loop and repair the relationship. We know that this can continue to be improved because we have surveyed low guideline adherence percentages. So what now?
Education
Set clear expectations through a mandatory education program on our various guidelines. Using programs like Docebo or Deque University allows for managers to be notified who has completed the training or not. This also requires managers to prioritize the time it takes to complete the course.
Process
Have a defined design process that includes handoff expectations. Every designer is expected to go through the handoff checklist, which hopefully will become second nature over time, and requiring use of the Figma linter will result in less lint checks at the end of engineering. Managers and PMs are responsible for checking-in on if these tasks are completed and protecting the designer’s time to do them.
Support
Hire design guideline specialists with QA capabilities. Designers who are extremely well-versed in guidelines who can provide guidance & spec’d designs on a request basis. They can take on the QA work when designers don’t have enough time and can educate them when they don’t have the expertise for a comprehensive handoff.