Hi there! I'm the person that coined the term "atomic design". I created this vocabulary as a way for people (well, myself really) to think of UIs as thoughtful, hierarchical systems. I hope the general mental model is helpful even if the specific labels I chose aren't appealing. As I say in my book:

“Atomic design” as a buzzword encapsulates the concepts of modular design and development, which becomes a useful shorthand for convincing stakeholders and talking with colleagues. But atomic design is not rigid dogma. Ultimately, whatever taxonomy you choose to work with should help you and your organization communicate more effectively in order to craft an amazing UI design system.

Hey Rachel! Thanks so much for all you do. And holy smokes do you do a lot. Besides being fit and eating well (I'll have to try these things one day), what are other productivity tips you swear by? Again, I'm so impressed by how much quality stuff you output!

That's a great question. I attempted to answer a similar question here. Here's the relevant part:

Quick example: one thing I always struggle with is stuff like this: section { margin-bottom: 2em; }. In most cases, I want there to be some room in between major sections of the site. Except when I don't. Sometimes there are cases where I want the sections to be flush together (say if I'm applying background colors to the sections). I could hard-code , but that would become unruly pretty quick. A better option would be to make a modifier for the pattern called .section--flush or something along those lines. That way the pattern becomes more versatile and can address similar scenarios in the future.

So to answer your question, I typically add a modifier to a pattern that allows me to adjust the spacing of a component based on its usage. That being said, there's more than one way to skin this cat and I'm sure helper classes and other techniques could also be valuable.

Ha! I've seen the lobotomised owl but have never used it.

Personally, I've been loving Sass's & feature that allows you to nest things quite elegantly. For example:

I think it's a nice pattern that saves you having to repeat yourself.

(Funny thing is though, in the back of my mind I can see myself reading this a year or two from now and wincing at this advice.)

First of all, I think it's amazing you have such ambitious dreams!

I wrote up some advice for people who want to get into the industry, so hopefully some of that is helpful for you.

Regarding your comment about studying design at a university, I'd say that's a fantastic plan. I went to a university and found the experience to be very valuable. However, I don't necessarily think it's a prerequisite for doing great work. Many great designers and developers didn't attend university and are at the top of the field. There's no substitute for getting out there and doing work. That's why I think it's so valuable to set up your own website and play around with it:

The best advice about getting started in web design/development is to buy yourself a domain name and create your own website. Your own website is the ultimate playground, where you can have fun, experiment and break things. You don’t have to worry about doing things right, impressing anyone, disappointing clients, or anything. It’s the ultimate freedom.

Also, I think it's helpful to ask around to see if people could use some design/development help. Some of my earliest work was for friends and family, and I think projects like that are a great way to dive in and get some experience under your belt.

Again, I think formal studies can be helpful for the right people, but don't think it's the only way to be successful. Work hard and have some fun!

Ha, that's a tough question! I dunno, really. JavaScript seems to be getting more robust and capable all the time, so I'd anticipate a that part of the frontend universe to continue to explode with all sorts of new developments.

And also, I think there are so many techniques and technologies out there right now that we have yet to really sink our teeth into. While there have been some opinions that we need to slow down, I personally think all these tools are really exciting. No one person can get their head around every Web technology available, but I'm looking forward to continue seeing people latch onto some nascent and/or obscure technique and do something amazing with it.

So the future is unknown, but I think so long as we continue to embrace sound principles we'll be alright!

"Someone who makes things for the Web." That's probably how I would define "web designer." What "making things" actually means will no doubt vary from person to person, and that's OK.

I recently talked about the notion of frontend design to highlight my own experiences as someone who's had a hard time fitting into any one bucket on a team. But some people do have clearly defined boundaries in their skill set; I call those people "bricks". But there are other people who straddle the line between a bunch of disciplines; I call them "mortar" people. Both bricks and mortar are necessary to build a stable wall, so whether you are a brick person (i.e. love doing backend work and don't want anything to do with UI code) or you're a mortar person (i.e. love UX design, semantic markup, and color theory), I hope you're able to thrive and excel in your work.

Oh jeez. I tend to avoid conversations about grids. I don't really feel strongly one way or the other on grid systems. If grids work really well for your team or you have a tool you gravitate towards, then cool! Go for it.

Personally, Don't Overthink It Grids by Chris Coyier really resonated with me. In my own work, I tend to establish a few layout patterns that lets me do what I need to do. I want to put things side by side, in thirds, in quarters. Sometimes I'll have a two-thirds/one-third thing going on. But yeah that's about it. I don't tend to apply any crazy grid systems to my work. To be quite honest, I still don't understand them, and this is as somebody that basically lives at web design conferences.

While I'm not a treasure trove of knowledge when it comes to grids, I will say to check out Rachel Andrew's new book, Get Ready for CSS Grid Layout. And if you're interested in responsive grid systems, I've rounded up a bunch of them here.

That's a great question, and of course the answer is "it depends."

I'd probably advise against inline styles, ids, and the like. I probably would advise having a conversation with the team about what you're trying to accomplish, and adapting the pattern to accommodate the variation.

Design systems are a living, breathing entity, so constant tweaks, extensions, and improvements should be encouraged. If the design system isn't doing what you need, I don't think the answer is to go rogue and make exceptions. That's a fast track to making the design system obsolete. The better approach would be to make the system more flexible so it works across the board.

Quick example: one thing I always struggle with is stuff like this: section { margin-bottom: 2em; }. In most cases, I want there to be some room in between major sections of the site. Except when I don't. Sometimes there are cases where I want the sections to be flush together (say if I'm applying background colors to the sections). I could hard-code <section style="margin-bottom: 0;">, but that would become unruly pretty quick. A better option would be to make a modifier for the pattern called .section--flush or something along those lines. That way the pattern becomes more versatile and can address similar scenarios in the future.

If you do have to go the hacky route for whatever reason, I'd recommend following Harry Robert's advice about having a shame.css file or something where you can put all your knowingly-hacky code. It's a place you can put things and say "heeeeeey, so I know this goes against the design system and is all sorts of hacky, but the deadline is looming and I needed to get this done!" With any luck, you'll be able to revisit that issue down the road and solve it properly.

Good luck!

Yep, I'm still doing client work! I'm currently working with a client that's been around a long time and has the chance to build something from the ground up for the first time in a long time. Part of my role is helping them actually make the thing, but the other part involves helping their team evolve their process. It's been so much fun to help the team collaborate more effectively and establish a solid, pattern-driven process!