💾 Archived View for themizarkshow.cities.yesterweb.org › blog › 05112022.gmi captured on 2022-06-03 at 23:04:54. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
a framework, not a religion
Figma's "config 2022" conference ended today. It was a 24hr design festival online for free, and they seriously did have talks going on ALL throughout that timeframe. I set alarms for some at 2am that I didn't bother to wake up for. But I did get up at 6am to catch some others!
In the aftermath of that conference, I have been watching a few of their recorded webinar sessions with actual users (called "In The File"). While I really wanted to write something about why I disagree with the whole democritization of design idea that one of them discussed, the one that instead drew my attention today was called "Building a Design System for Designers."
In The File with Figma Customers (Playlist)
"Building A Design System for Designers"
My first beef? This is not what the talk was about! It was about how the Honeywell design system team got fedup with Sketch + Abstract + InVision, and switched to Figma to do all of the those things plus more.
My second, and main, beef though? Some off-handed comments about how their initial work on a design system focused on Atomic Design, which was too confusing, time consuming, and frustrating so they abandoned it (I guess) for whatever framework they now use. In the Q&A session, someone asked what had happened with atomic design that made them abandon it, and we got some better answers.
The TL:DR; version I would present from watching and then rewatching that section of the video, is this: they treated it like a religion and the strict adherance to it as such bogged everything down and became self-serving.
My response to their mistakes begins now.
---
One of the biggest mistakes you can make is to start by focusing on all of your atoms first, then moving to molecules, organisms, templates, and finally pages. Doing this will take forever, create a ton of rework, and frustrate everyone involved.
Instead, build a list of priorities based on the first project you can impliment your budding design system on.
By focusing on those top priorities and getting something useful into production ASAP, you will naturally find the necessary gaps and have a good idea of their priority order. My usual MVP's consist for a few simple things: colors, fonts, icons, grids, and your brand's logos.
You will need those components across everything you do, no matter the size or scope. And for a developer, getting these assets built will make everything down the road so much easier.
As you start to use your new system in a project, pull the components your making back into the system once you get approvals. Item's that will often come first are your molecules; buttons, tags, form fields, and the like.
No one outside the design system team really needs to know about "atomic design" but it's a great way to organize and reference your work when discussing it within your team.
---
I've built pattern libraries and design systems for clients at my old agency and from within several different corporations. Atomic Design is a great framework to organize this type of work by. However, it's not something to be shared or taught to those outside of the design system work. It makes our lives easier by giving us ways to organize files and discuss how the blocks we work with can be reused, recombined, and remixed.
Making it your all-consuming design philosophy is the wrong path. It leads to splintering factions, new denominations, and unnecessary conflict. Atomic Design is just a way to organize huge files full of components & variants.
Nothing more. Nothing less.
05.11.2022 / milwaukee, wi