Here's what my workspace looks like right now:

That's my brother Ian working beside me. And that's my bulldog, Ziggy.

Great question. Visual exploration is crucial, especially in the early stages of the design process. I just wrote about tactics for establishing visual design direction in my book. Here's the issue:

Historically, visual designers have gone about this by creating full comps — often many comps — to feel out the aesthetic values of the organization. Throw some comps against the wall and see what sticks. As you might imagine, generating a slew of comps from scratch takes an immense amount of time and effort, and unfortunately much of that work finds itself on the cutting room floor. There must be a more efficient way.

In a successful pattern-based process, you're able to get a sense of what aesthetics the stakeholders value and what they don't value without having to do a ton of work. Using exercises like The 20-second gut test and creating artifacts like style tiles and element collages can help the client get a feel for the aesthetic direction without having to burn a bunch of time developing a slew of full comps.

There's no substitute for real collaboration and communication. Artifacts like style tiles and element collages won't be effective if they're not coupled with real conversations about the goals of the project and aesthetic values of the organization. In short: more talking, less blind comping.

Hmmm, interesting. It's hard to comment on your specific scenario, but from a broader perspective I'd say it's why I gravitate towards relative units like ems and rems over fixed pixel units.

When I first started designing mobile web experiences in 2010, I quickly learned that a pixel is not a pixel is not a pixel. Mobile Safari would render something wildly different than Android 2.1 (yes that far back) which would render something way different than Blackberry 6.0 (yes really that far back). When I switched from px to em-based units, those differences normalized.

So my advice would be to explore using relative units to see if that helps your situation. And remember, do websites need to look the same in every browser? Click here to find out.

I haven't looked at the actual spec, but from what I've read on the subject it seems really exciting! I think the most exciting thing about them is that they're live variables, versus precompiled variables like Sass. That means you can dynamically change values during runtime to accomplish some really cool stuff.

Obviously, these custom properties can help maintain stylistic consistency across a site, but it seems like they can do more than that. Jake Archibald recently talked about how to use these properties to more thoughtfully load in CSS partials. That's just one example, but I have a feeling we're just scratching the surface of what can be accomplished with them.

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!

Thanks a bunch! It was so great to have Anna as a co-host. She's a seasoned podcasting vet and has been thinking about style guides for ages. And it helped that all of our guests were incredible.

I'm also happy we decided to keep it "small batch" so we didn't feel the obligation to make hundreds of episodes where we're simply rehashing the same concepts over and over again. It was a great experience.

I have a small role advising a company called Brand AI that makes a living brand style guide that hooks into tools. The cool thing is that you change a color value centrally and it will update in tools like Sketch, PowerPoint, Photoshop, and more while also spitting out a new Sass file for web developers. I like the idea of having centrally managed styles. I'd be curious to hear if they have plans to integrate with native mobile platforms and other tools as well, but the general concept is there!

I invested in a good chair. And since I work from home, I find myself getting up from my desk quite a bit to tend to things other than a computer screen. At my old job I used to have a standup desk, which was a lot of fun. I also used to use programs that deactivated my computer screens at regular intervals (sorry I can't find a link anywhere) that would force me to stand up and leave my work area for a while.

I'd say focus on principles rather than tools. We all have opinions and weapons of choice (I've been enjoying Atom as well!), but at the end of the day tools come and go, while principles tend to last much longer.

To be honest, I don't focus too much on responsive typography, so I'll defer to Jason Pamental's great book on the topic.

Of course I think that typography is very important, but I think you can get a good typographic look and feel without necessarily applying the fibonacci sequence or anything like that.

Hey Taron, Thanks for your question.

For example, bumping the default font size from 14px to 16px would break a lot of pages. Changing the grid width from 960px to a fluid grid or even a wider grid will break a lot of pages.

Yeah I mean those are big changes that impact the entirety of the experience. Making changes of that scope will no doubt take time, thought, and effort. But I'd say those types of changes should rarely happen. If you find yourself making such significant changes frequently, I'd say there's probably something bigger going on that's worth exploring.

I just wrote about Pitching Patterns in my book.

I've found it's a bit easier to sell these concepts to the teams actually doing the work. People tend to appreciate working faster and smarter. But for the people holding the pursestrings, you may need to approach things differently. Tie the benefits of a pattern-driven process in with financial savings, and you'll be more likely to convince them to bite on it.

I've also found it's helpful for the organization to feel the pain of an inconsistent experience. That's why I think conducting an interface inventory is a great idea. You don't need to be a designer to understand having 150 button styles is probably a bad idea.

And even if they say no, do it anyways. Ask forgiveness, not permission.

I'm in the midst of these conversations with a few clients right now.

I see the relationship between the over-arching design system and each implementation as a two-way street. The global design system obviously influences each implementation of it, but each instance should also influence the global system.

How do you apply atomic design to a UI that is going to have a different look/feel basic on a new theme?

Yep, I think you have it right that there would be a global.css stylesheet and a theme.css file to go along with it. Snook's SMACSS addresses this pretty well.

Do your group all your skins in with your component styles?

One thing we've done is build some functionality into the pattern library that allows you to toggle the themes. Have some form of dropdown or radio button that swaps out each theme's styles so you can see what each theme-flavored component looks like.

Or bigger picture, how do you decide what the default style looks like?

I would take a step back, extract the shared properties, and bake those properties into the system. If for instance one implementation uses a bunch of crazy textures and drop shadows on their buttons, then great! But those don't necessarily need to be included in the global styles. If however, the properties are more structural in nature (flexed items, absolute positioning, etc) then those should probably be addressed in the global styles.

Hey Maxwell, thanks for having me! This is a ton of fun.

how many specific talks do you have and how do you tailor each to their respective audiences? (if applicable :)

Great question, and I don't really have a great answer. My talks seem like ever-evolving blobs of content, and topics tend to bleed into each other quite a bit. As much as I'd love to have a handful of done-and-dusted talks that I could automatically deliver, it never seems to work that way. I do try to pepper in audience-specific references when I can, but I often find it's helpful to introduce audiences to ideas that may be bigger than their specific industries.

I dig your mantra, "Work hard. Don't be an asshole. Share what you know."... specific to the latter, how do you notice yourself sharing what you know? (i.e. website, twitter, blog, other...) And on the opposite end of that, where do you recommend people to follow you for the latest and greatest?

Thanks! I try to share as much as humanly possible, and lately that's taken quite a few different forms. I'm writing my book in the open, I tweet a lot, I blog a lot (a little less so lately because I'm writing the book), I help make resourcesites, I helped make a podcast, I shareexamples, I sharetools, I sharetalks.

My philosophy is that it's not about the work you do, but rather what you enable other people to do. It's been so incredibly fortunate to learn from the creative exhaust of others, so I want to do what I can to contribute. It's so incredibly inspiring to see people take my little nuggets of ideas and turn them into truly incredible things.

You're no doubt busy!... where do you find the majority of your time/work being spent as of late? (design, writing, speaking, consulting, workshops...)

All of the above :) I'm currently in the middle of a client project while scampering around the world giving talks, workshops, consultation, amongst other things. I try to fit writing my book in between all of that, which I've found to be challenging.

Of course E. 1999 Eternal!

This probably comes as no surprise to anyone, but I'm a big advocate of progressive enhancement as a sound principle to follow in order to create for this incredibly-diverse Web landscape.

That being said, there's a time and place for everything. I won't say there's never a sound use case for rendering things on the client-side, but I think "render everything on the client-side" is dangerous as a default mentality.

Thankfully, I see things trending towards server-side-rendered, "isomorphic" JavaScript. That means we can make use of all the benefits of server-side rendering while still taking advantage of the dynamic aspects of client-side manipulation.

I think there are a lot of benefits of using ems and rems (see this answer. Having seen a lot of situations normalize across devices because of relative units, I still think there are accessibility benefits from using them. That being said, maybe every browser has advanced enough where it's no longer an issue. I dunno!

Interesting! I have not seen this before. I won't cast too strong an opinion on it just because I haven't had a chance to read about it, but generally speaking it seems like a lateral move. Styles and style modifications need to be articulated somewhere, and whether it's classes or custom attributes doesn't really matter. Or maybe it does; I dunno!

If teams find this way useful, then I'd say go for it. But I'd say to tread lightly simply because it's a pretty big departure from current conventions. I'm not saying that all new things are bad, but it would be worth weighing pros and cons before adopting a new approach like this.

Ha! Good question. I do a lot of traveling so my schedule tends to be all over the board. But if I'm lucky enough to be home for a week, I'll try to get up at 6:30AM, head to the coffee shop to do some writing before my workday starts around 10. I used to be a late-night worker, but that's changed in recent months. No idea why!

SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL SALTED CARAMEL . I have a picture of one on my bedroom ceiling above my bed.