Design tokens have provided a visual foundation of many design systems since Salesforce pioneered the concept in 2014. I wrote an impassioned article on design tokens in 2016, and my energy on the topic continues to grow. As systems of visual style spread across a widening landscape of components, platforms and outputs, design tokens — and their names — are increasingly important.
Effective token names improve and sustain a team’s shared understanding of visual style through design, code, and other interdisciplinary handoffs. Terms matter. As we make things, we must be able to browse and search tools to quickly recognize and recall the purposeful decisions we’ve made. …
Immediately, the community used it. And, immediately, they needed help.
What kind of help? Oh my goodness did those requests fly! Fix your defect. Add a feature I want. Answer my question. Approve my proposal. Set up my files. Train us. Review that we used the system correctly. Link our library. On and on and on. Over eight weeks, 100+ incidents (or cases, in tech support speak) inundated the team in Slack, email, tickets, and more.
Gulp. We hadn’t anticipated the demand. Cases felt unceasing. Responses flew haphazardly. It was all quite chaotic. We figured it out, and we gained our customer’s trust. And, along the way, I learned a lesson. …
As new collaborators engage with a design system for the first time, there are two common, similar objections:
There’s so many steps. It’s so long and too complicated.
This workflow is far more complicated than how we make things on our team.
First off, I recognize and validate their perception. Yes, making design system features requires many steps. It takes time. Yes, making design system features (on teams I lead) is always more complicated than how other squads make features directly for their products. But why? Shouldn’t it be the same?
There are two main reasons it’s not: quality and engagement. …
Originally published on eightshapes.com.
Top-level steps to develop a system feature—from
Doc—are valuable but not enough. Teammates made different assumptions about what’s needed to complete a step. High-level definitions-of-done were helpful. Yet, outputs lacked robustness when smaller substeps were completed inconsistently. Team members called for checklists to identify everything expected along the way.
This post introduces Subtasks per Step organized in Phases. Each of four major steps —
Document—are expanded to include detailed subtasks with examples revealing what subtasks are needed when. …
Contributing to a design system should be simple, even if you aren’t on the core team. Find it, change it, publish it, and everyone uses it! Easy peasy.
Unfortunately, completing most design system features is slightly more complicated. Bug fixes and tiny enhancements should be autonomous and quick. However, most prospective contributors don’t know or want to do all the steps involved in delivering large enhancements or new features.
That’s why a design system program needs stewards: selfless, knowledgable, attentive and warm people to guide contributors through their work. …
Every system team I’ve worked with yearns for a better — even perfect — contribution workflow model. Nobody feels they have it (although some have parts of one). They all seem to tell their design and dev constituencies continually that “We’re going to refine our contribution model next quarter.”
Trouble is, the premise of a perfect model conflicts with a harsh reality: teams must optimize multiple contribution models. Adding yet another icon is different from making a data visualization color hierarchy. Contributing a chip is simpler than contributing a functioning, high-quality data grid that’s like Excel in a browser. Making and fixing small things is different than making large, new things. …
Everyone — designer, developer, leader, anyone else — contends that contributions are essential to legitimize a design system. This sentiment is instinctual, a yearning for the transparency, empowerment, and fluid effectiveness of a seemingly open source venture.
Many will go so far as to say contributions are the primary reason a design system exists. To me, that takes things too far. You can build, support, and evolve a toolkit of visual style and UI components for a massive community without taking a single contribution. Not that you should, but you could.
Nevertheless, contributions are essential. But why are they essential? Turns out, there’s many reasons. This post explores eight themes from interviews and discussions over the years. Skill development, adaptation, inclusiveness, and alignment begin as honorable mentions. Deeper topics follow as ownership, representation and productivity. Ultimately, the article finishes in an unexpected yet encouraging place: advocacy. …
Operating a design system shares much in common with operating any product venture, from developing to supporting to marketing it. With marketing comes communications, spreading messages far and wide to engage designers and developers how they want to be engaged. Addressing their problems. Using the tools and places they observe and participate in.
Marketing communications tools aren’t new. Yet, for design systems, those tools help us structure our heretofore loose thinking. Zooming out, a design system can review target audiences, channels, and messages, compose a strategy using message matrices, and envision campaigns to launch a major release or manage change. …
I really like using Jira. I value the order it brings to the complicated chaos of making, curating, and contributing to design systems. I’m no Jira admin, and I ain’t no certified scrummaster. That said, I’ve brought enough order to design system chaos using Jira to share the durable approaches I’ve learned.
Others have their feelings about Jira, too. I don’t know how your enterprise uses Jira. I don’t know how your team wants to manage tasks. Every team is different: what’s been good for my teams may not work well for your teams. Most of my clients use Jira, but there are some that don’t. …
Everyday digital interfaces include a rich variety of images, visualizations, and other pictures. However, more than anything else, they are made of words. Oh so many words. As we equip teams to design and code usable, consistent, beautiful interfaces using systems, it’s essential that words depend on a strong foundation of typography.
I’ll admit, I am not a typography expert. I lack a graphic design degree. I’m never the person choosing a font, scaling type, or finessing letter spacing. As a result, I’ve always been reluctant to write about typography.
On the other hand, I am a pattern hunter. Over the years, I’ve contributed to many design systems that set a foundation for typography. Each traversed of steps and decisions to set a foundation and apply it to an emerging library of interface components. …