Ideally, a design system designer should have experience coding. Understanding the technical or “real world” constraints will lead to more meaningful experiences and more robust components. Regularly ask the question, “What would this look like in code, and is this possible?” Similarly, rely on your internal designers and engineers as a first line of defense for testing usability. Create components that are ergonomical—that is, they feel familiar, intuitive, and easy to configure by the engineers and designers that will consume your design system.
Is your design system philosophy to build components that are rigid and opinionated, or is it to build components that are flexible and composable? Do you have an inheritance based design system where properties, tokens, and even relationships are shared across brands? As it relates to the brand(s), what aspects of the brand identity affect your design system philosophy? For example, if the brand represents a car company, how does motion or animation play into your design system? Spend time understanding how the design language influences how components are manifested.
Align with your engineers on a workflow that enables you to prototype components sooner rather than later in the development process. Establish partnerships with your engineers that allow you to ideate with them in code and understand why they use specific attributes versus others. Practice looking “under the hood” at how your engineers build components to review the component’s DOM (Document Object Model) and to make sure semantic HTML is being used, and attributes or tags are utilized in a meaningful way.
Are there members of your team who are accessibility experts, or who are passionate about champion accessibility? Invite them to collaborate with you on developing guidelines so that there is shared authorship from both the design and engineering standpoint. Be proactive in engaging engineers. Rather than waiting for them to come to you, ask your engineering partners to show you what they’re working on. Attend their stand-ups and other meetings they host. Understand their workload and how they measure success.
Components should be built so that screen readers and other assistive technologies can interpret them in a meaningful way. As part of your design process, listen to what is read by a screen reader to make sure it is useful information. Recognize that when you’re designing components for accessibility, you’ll come across success criteria that you might not typically encounter. Considerations like contrast ratio and target size are common accessibility concerns. However, be prepared to explore concepts like “meaningful sequence,” which is relevant for a timeline component, to make sure a user performs steps linearly, e.g., first, second, third, etc., and doesn’t jump around within the list.
Talk to your engineer partners and ask them what your component might look like in code and if it is possible. Approach the conversation with a sense of curiosity and willingness to learn. Practice referencing WCAG to understand how an ideally accessible version of your component might be built. Recognize, however, that the WCAG version may not be the right execution for your use case or brand, so together with your engineering partners, ask yourself why you're making design decisions and is it accessible. A prime example is that native iOS or Android components might be not be fully represented in the WCAG. In times like these you’ll need to use your best judgment and make tradeoffs where needed. Also, it’s equally important to determine and document what you won’t do.