The Cantina team is constantly discussing emerging tools & methodologies and occasionally these in-house conversations are so informative (and entertaining) we like to share them with a larger audience here on the blog. This particular session begins with reactions to a timely article by Brad Frost writing about the effectiveness of atomic design principles and thoughtful CSS architecture. The Cantina team goes on to discuss the role of tools and people in bridging the gap between user interface design and front-end development.
Reading Brad Frost's CSS Architecture for Design Systems. It seems to be a really good example of carrying atomic design principles into CSS implementation at scale.
That’s great, Sam. For me, it fits where I’ve wanted to go (namespace + BEM), and I like the addition of the type label in the class. Of course, the trick is to think in components, which in turn means designing a system base-up. If you’re able to work with atomic design principles, this all seems like it will hang together nicely.
I continue to be interested in how a UI is architected because I can ideally bring some of those structural concepts into an atomic design process. If I know the front-end taxonomy it helps me create design outputs tailored to the dev team’s environment.
Sam, you might want to look at functional CSS as well, if that’s your interest. I don’t think most places have the discipline to use it effectively at scale, but it’s a lot friendlier for defining atomic classes. The thing I like about BEM is that it emphasizes a compartmentalized namespace, so you can at least be assured that all the muckery is contained in the CSS, where it belongs.
A quote from the article… "The overwhelming majority of (this) organization’s developers don’t specialize in frontend development but rather focus on application programming, data, and logic.” That same focus is true for 90% of the client teams we work with. I feel like we often end up consulting on front-end architecture best practices either in code or as part of the design delivery.
Totally agree.
As a designer, I personally want to find better ways to speak that language and advocate for those architectural concepts (without actually writing the code).
The discipline issue is multifaceted. The problem of developers writing CSS without an eye on the big picture is definitely something we see, but we also run up against designers failing to work within the overall system. There also needs to better process and workflows between tools like Sketch and the static design system artifact, as well as from that phase to front-end implementation tools.
I am very interested in the next gen of prototyping tools. It seems like a lot of them are thinking in these terms, documenting design specifications and assisting in the transition to code.
They’re getting there, but sometimes in odd ways. Most tools still follow the workflow of “do your design in Sketch, then import your stuff into our tool for the next step"
As someone who doesn't write code it is exciting to see the tools grow - at another level though it’s still just another version of drawing a picture of the real thing.
That’s totally true. We’ve put deep divides between the parts of the process and then spend a lot of time trying to glue them back together to get a coherent end product.
Designing right in the browser reduces deliverables overall, but I do think these tools have their place. It’s just critical to be cognizant of the big picture and the true medium of delivery.
Designing within the constraints of the medium is difficult, but that’s the nature of the beast. Also, tools are fine, but it’s people and strong practices that make all the difference. Great digital experiences are built on strong design systems and a maintainable front-end architecture. It takes smart people and effective practices to create both.