Having implemented this component specs format across about 5 clients in 2 years, it's really time for a blog post. What I really want? Build a
@figma
widget/plugin for it. Sigh, just don't have the time.
Since the "Measuring design system success" cheatsheet I made is making the rounds, I'll add my basic narration included to introduce collaborators to it...
(1/12)
All my clients are struggling collectively, describing it as "Designers don't know how to use Figma Autolayout."
That's NOT the problem. The problem is that "Designers don't understand the box model and hierarchically nested layout techniques."
The problem is UI design craft.
Don't get me wrong. I 🧡
@figma
and value the experimentation they're doing to add more and more.
But I can sense it. It's happening. Their UI is "Adobe Creative Suite"ing. And that carries a usability cost.
So, I don't get it.
@figma
Dev Mode is adding a ton of changes, including enabling a designer to annotate a design. It's all very rich, live, and fancy. It would seem a direct substitute of my EightShapes Specs plugin.
But...it's not. At all.
Coming next week: New features in Dev Mode to bring design + dev closer.
Annotations (!!), improvements to diffing, plugins, and the VS Code extension.
What's shipping January 31 as Dev Mode moves out of free beta →
I get asked enough "How do you use Jira for Design Systems?" that I've screenshotted a tutorial of it all. Is there interest in a Medium post about it?
Why bar charts are better than donut/pie charts:
1. What proportion is green or orange?
2. What are the top three bars?
3. Is red > purple?
4. Is red+green+purple > blue?
I sense a Medium article coming on. Something like...
Design Systems Should Enable, Not Govern
Don't be a Standards Team. Be a Tools Team that Applies and Amplifies Standards.
OMG,
@skougs
admits Atlassian's design system hasn't shipped a new component in 18 months. What the what? They've been focusing on other problems: doc, people, etc. That's BOLD! Design systems ≠ component library.
Finishing Friday with some visual refinements of the automated Anatomy and Props views of the Figma Specs plugin I've been working on. Feeling excited!
Available starting today, you can upgrade your use of the EightShapes Specs plugin to display Tokens Studio tokens within Anatomy, Props and Layout sections. Enjoy!
Looks like
@eightshapes
Visual Difference
@figma
plugin that
@kevinmpowell
and I made was approved!
You can use it to create snapshots of Figma objects to visually compare later as those objects change.
I had a very positive experience recalibrating my "ESDS" (EightShapes Design System) color system I use for public workshops using
@githubprimer
's Prism tool.
How teams I work with treat spec as an artifact informing ALL outputs across disciplines and tools. Output work often begins before Specs are done, but all use Spec as an artifact indicating sourc of truth.
As I prep conference talks, I'm revisiting my materials from last year, recalling the effort. Yet now it's a 1 second command to run the plugin and get something more detailed and accurate.
I still get excited every time I run it.
Hey design system pros: while I agree that Google Material, Atlassian, Spectrum, and Shopify Polaris are great examples, can you work harder when "auditing public DSs" for ideas?
Too many pros audit the same four or five, call it a day, and miss out on great stuff out there.
Although I've done 100s, there are some design system interview questions that I ask that still yield the best responses that I'm eager to hear. What are yours?
When building libraries for many platforms, handoffs across teams remain but developers lack tight relationships with designer(s) to understand requirements. Specs fill that void.
Just published a
@figma
Specs plugin version 2 enhancing some basics and fixing a few errors.
#nervous
Didn't realize the plugin is loaded into current file memory such that users must refresh the file to use the new plugin version.
#unexpected
Hey all you
@figma
autolayout nerds out there, wrapping is no joke. There's much to think about. Varying heights and widths, overflowing content, visual attributes outside boundaries...
You know, for a field – Design Systems – dedicated to practices of shared vocabulary and naming things, we are laughably inconsistent and incapable to norm on basic terminology.
As Figma strengthens, design systems are sharing an API across design and dev.
To realize this, cross-disciplinary teams must identify what to include, when to fit API into a workflow, where to author together, and how to change together.
I'm all for collaboration and inclusiveness in design activities, and work hard to get everyone's voice heard. Yet, across all my roles: designer, architect, manager, leader, business owner, consultant, one reality remains true:
Design is not a democracy.
Oh my goodness let the requests fly! Fix YOUR defect. Add a feature I want. Help me. Train us. Review that we used the system correctly. Link our library. On and on and on.
It's time to invest in a support process that's not handwavingly trivial.
I think I could make a full day workshop on architecting UI component API (names, anatomy, props, layout composition, …).
And if I called it API it’d scare designers even though it’s a valuable skillset to have.
Ok, it's out there: EightShapes Specs plugin with a (for now, basic) UI to configure what sections are produced and to manage what's already there.
Hope this is another step forward preparing for more fun stuff, and that you find it valuable.🎉
Without a strong token foundation, objectives like dark mode, consistent API and multi-brand theming remain out of reach. Then
@figma
variables hit. A moment to reimagine your token taxonomy may be coming.
Component Specifications: What to include, where it goes, and why it matters more now
My latest on
@medium
to complement the community file we released and plugin that's described in a separate post.
Testing isn’t just create an instance, change a label, swap some properties, resize an edge, “Done!” Seriously, ten seconds and you release it?
This article digs into using visual test cases to validate a Figma component.
Space in Design Systems, far and away the most popular thing I've written (140K views, 37K reads) is 3.5 yrs old, now wrong in places, and lacks 50%+ of what I coach on the topic. Time for a 2nd edition?
Like if interested, comment with requests.
Occassionally but increasingly I wonder "Is my
@figma
usage actually the product, such that over time my behaviors will be recorded and automated so as to eventually AI myself out of a job?"
This Figjam AI launch is just another small step...
Did you know... the biggest value you get out of a design system's tokens isn't the tooling or actual variables, but the establishment of a recognized space in which style decisions are modeled and maintained?
Watching a
@shaunbent
talk
@intodsconf
, design system nerds take away details.
Me? "Oh, pretitle as an element / zone name where you could put an eyebrow OR badge is an interestingly flexible take!"
What UI component libraries published on the Figma community do you think are built with the highest level of quality?
I'm using many as test cases for my plugin, and I'm seeing... varying quality in labeling, construction, layout, etc. 👀
Getting excited yet anxious as the moment approaches (as soon as this weekend?) that launches the first paid feature of the Specs plugin: displaying applied Token Studio tokens.
I'm getting interest from a few folks to give a conference talk on how I use
@asana
to manage design systems work.
How interested would you be to attend such a talk, buy a training course and/or read a
@Medium
post?
This glimpse into the Atlassian Design System through an interview with
@jenniesyip
includes a treasure trove of ways to think about scaling and leading your system towards a brighter future.
Design systems don't arise because there's a vacuum into which you inject UI components.
Design systems arise because many people making UI components together aren't making them sustainably at robust quality, and making the right components at the right sizes.
Wash, rinse, repeat: the toughest thing about design systems isn't "making it" (as in, component code, sketch files, etc). It's integrating into the design process and code stacks across those that adopt it. THAT's the system that's a challenge.
Starting to think about the ideal format – and, uggghhh, all the logic needed – to automate, suggest, and organize Accessibility specs using a plugin.
Hat tip to the
@w3c_wai
ARIA Authoring Practices Guide content, which I'd love to integrate.
I see you, oh naming taxonomy, founded upon a color system originating from
@MiroHQ
sticky note colors... 🤣 (left is Naming Tokens, right is Naming Components)
Having done the "Upgrade your (poorly architected) tokens to a robust, durable design token taxonomy" project three times in a year, I'm getting close to writing up my (now Airtable+Figjam infused) process of getting from as-is to to-be taxonomy.
I'll admit my (very strongly opinionated) bias: I see design systems as the best bridge of design and front end engineering in the business. So I cringe when I see strong separation of design here, code there in doc. The narratives are threaded, not separate!
While I ❤️ dev mode, component playground shouldn't be buried there.
@figma
, all my current clients are building many-library ecosystems and discoverability / visibility is the MAIN problem to solve.
Here's all your existing bits that'd – if combined – would go a long way.
As I work on enhancing my plugin for wrapping autolayout, I'm a bit 😕 why
@figma
didn't incorporate the browser's longstanding box model color system.
I can easily understand a range of reasons why. I just like persisting the familiar meaning of orange, yellow, green and blue.
In helping design teams upgrade Figma files and libraries for variables over styles, I'm finding the problem isn't "What's detached where?" but instead "What attributes are overridden where?"
That's a different model that Figma doesn't track and is actually a bigger problem.
Really energized by research that's hopefully going to lead to writing and workshops on Architecting Components. Lots of thinking about choices we make to decide a component's composition and configuration.
I've been working on the Specs plugin to add comparison features while (completely refactoring) the comparison engine overall.
I'm excited to be seeing 3x performance gains (15s -> 5s) on my longest running beast: Github Primer's Comment box.
Can't wait to get this out there!
Just launched an EightShapes Specs plugin option for displaying anatomy specs in tabular format. It's available free during the beta period.
This hopefully unlocks other potential features in the future, too (props table, component metadata, ...).
I am 💛
@figma
's autolayout improvements, and know that more's to come I'm sure.
I also remain surprised at how long such specificity has been available in CSS (10 years? more?) and unavailable in design tools.
Listening to a
@dscc_tor
commenter refer to "options" and "decisions" tokens. I fear I am responsible for those terms even though I've long moved on to different terms like generic, semantic, and component-level tokens.
I pondered with
@danmall
earlier this week: if/when our tools (Figma, Storybook, etc) continue to improve, how much to separate design system documentation websites recede in importance?
Are we approaching a point where we manage content flowed into tools instead?
I am delighted, awkwardly, when I'm in a client call, another consultant presents the "Team Models" diagrams, and they haven't connected who I am to what that is.
I wonder if
@brad_frost
is ever in calls when people don't know who he is and start teaching Atomic Design.
Working on component specs templates for the Figma community file that will compliment the Specs Figma plugin.
Inspirations come from work with teammates and the
@WalterStephanie
blog. More to come!
Yesterday, a client was stuck on explicit levels of
@brad_frost
's excellent Atomic model. I encouraged them to go from explicitly:
"Is this a molecule or not?"
to:
"(Bigger) Components are made of elements. Many are nested (smaller) components, making a dependency tree."
Audi's done well using Storybook as a broader design system doc site (acknowledging they also have other brand/system sites too).
Do you know of other publicly visible design systems that broaden Storybook to be a doc site like this?
Finally, after nearly a year, I'm writing again, this time on Testing Figma Components. Component usability, in particular, is in the eye of the beholder. Feels good to get back to writing again.
Fact: Making a system is hard.
Fact: Sustaining a system is harder.
Fact: Shepherding an ecosystem through a generational (breaking) upgrade has proven the hardest and at times soul sucking experience.
@clarity_conf
Having been a component grouping skeptic for my whole design system life (I'm a "flat lister"), I found it interesting to compare component groups of
@adobe
's Spectrum and
@ShopifyUX
's Polaris.
Lesson learned the hard way: space ≠ size.
In CSS, space includes padding, margin, left, right, top and bottom; size is height, width, and their variants. Space leads to size and vice versa, but they aren't the same thing.
How is it 2023 and I'm making this slide distinguishing specifications (made for people MAKING a library) from docs / guidelines (made for people USING a library)?