Episode Transcript

Ethan:

Hi, this is a Responsive Web Design Podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, well I’m incredibly excited that my guest happens to be… Oh, it’s Karen McGrane. Hi Karen, what’s goin’ on?

Karen:

Hey, Ethan. Do I have to do all the talking?

Ethan:

Well, sadly, you know, it’s sort of a fifty-fifty thing this week unfortunately.

But before we get started, I’d like to take a moment to thank our sponsor, Media Temple. They’re an LA-based provider of web and cloud hosting solutions that caters to web developers and designers like you and I, as well as to creative agencies and large enterprises. Now, they’ve been around since 1998, so there’s a pretty good chance you’ve heard of them. I mean, heck, one of my earliest sites was hosted on Media Temple. They offer 24/7, award-winning support, that’s based right here in the U.S., available online or over the phone. And Media Temple has one of the highest customer loyalty rates in the industry. They’re incredibly proud of their focus on the digital design community and offer a whole suite of products that are just tailored to its needs. If this all sounds good to you, you can use the code RESPONSIVE when you sign up, and if you do that, you’ll get 33% off the first three months of shared or Wordpress hosting. That’s available at mediatemple.net. Once again, from Karen and I, we’d like to thank Media Temple for sponsoring the podcast. Thanks so much.

No, but I think we wanted to sort of sit down and chat about, well, a whole host of things, but I think one of the things that we’ve been especially excited about is patterns. I hear they’re the new thing in responsive design.

Karen:

Someone should write a book about that.

Ethan:

Yeah, yeah. No, massive, massive opportunity in the market. I think, you know, responsive design patterns and principles, these are things that are just near and dear to the heart of the youth of America today, so let’s chat about them. But it’s interesting because I know at least in conversations I’ve been having with clients lately, and I think the same is true for you Karen, this is a weird thing that’s been bubbling up pretty frequently, just how do we actually talk about an interface that’s not page-focused?

Karen:

Exactly. I think there’s this enthusiasm for moving beyond the page, for not creating templates. But I think when the rubber hits the road, there’s still a lot of questions about what does that actually mean, what are we designing, how do we create a website from these components, how do our team members work together to use these patterns?

When you’re staring down the barrel of a CMS replatforming and a website redesign, that can easily spiral out to be a three, four-year, eleventy-bajillion-dollar project in which everyone gets fired in the end.

Ethan:

Right. You mentioned actually that this has come up pretty recently. Can you give me an example of how these conversations tend to play out for you?

Karen:

Sure. So, let’s look at hypothetical client example…

Ethan:

Hypothetical.

Karen:

…In which a team recognizes that they need a new content management system. Pretty common theme in my world. And that team might also recognize that the website needs a redesign. So, maybe it’s responsive, maybe it’s not, maybe it just needs some attention, some love and care. And when you’re staring down the barrel of a CMS replatforming and a website redesign, that can easily spiral out to be a three, four-year, eleventy-bajillion-dollar project in which everyone gets fired in the end.

Ethan:

[laughs]

Karen:

[laughs] So, how are responsive design patterns going to help us solve that problem, Ethan?

There’s a little bit of a disconnect between how those front-end patterns are informed by the content strategy and by the CMS and the back-end structures.

Ethan:

That is a fantastic question, because I think, broadly speaking, most of the conversation around patterns, that I’ve been seeing anyway—this is showing my professional biases—but it tends to be seen as development effort or design effort, right? Like, this is something that a designer at the start of a redesign process might do a visual inventory of the existing interface and sort of pull out all of the distinct modules and patterns that kind of build the existing design to essentially get a catalog of what they’re going to need to support in the new existing interface.

And then at the end of the process, right after they finish this beautiful new redesign, they’re building, again, another visual inventory to sort of talk about, “Okay, here’s what we’ve built, here’s what we’ve designed, all the new modules and patterns that have gone into your new responsive site.”

We’ve talked a little bit about this, but I think there’s a little bit of a disconnect between how those front-end patterns are informed by the content strategy and by the CMS and the back-end structures, and I think that’s a really interesting question that people are just starting to talk about right now.

Karen:

Yeah, philosophically I guess I would say two things about that.

The first is that I am concerned when I see people talking about design patterns and style guides as if they exist on some plane completely devoid of any discussion of content. So, we’re creating little tiny styles, little tiny templates, but there’s still the sense that, “Oh, well people can just pour whatever content they want in there!” Like, “Look, there’s a title field! Look, there’s some text! Put some text in there! Hey, you can stick an image in there!” And while I will wholeheartedly suggest that there’s a lot of value for front-end designers and developers having a library of reusable snippets or styles that they can draw from, I personally think that the content modeling piece—so the intersection between what are the types of content we’re producing, what are the underlying structures, even down to character count—that to me is the real value of doing this work.

It’s a different way of thinking about how those patterns or those components actually get built that treats them as if they’re part of the very fundamental nature of the site as opposed to just a reference guide.

And then second, I think that when I hear people talk about creating these sorts of patterns, there is the sense that it’s a style guide, like a document. People talk about creating a living style guide, a living document that is going to be managed and maintained over time, but it’s still seen as essentially a reference tool. And what I have seen with many organizations that have thought about this in just a terribly smart and forward-looking way is that they treat it as if those patterns, those components are actually physically built into the content management system, like the very framework by which you are constructing the site on the back-end is based on assembling those components. So team members, once they get this built for ordinary pages—I mean, I’m not talking about complex one-off pages here. But you want to construct a page, you don’t use Photoshop, you don’t prototype in the browser, you just go directly into the publishing system, swack together those components in a way that makes sense, and put a link to staging… Works for people? Okay great, the page is live within hours or days. That is so much more maintainable because if you want to update those components, if you want to make a change to something, you do it on the back end and it actually rolls out to every page on the website; you don’t have to test all those changes to the website, you can just test it in a couple places. So, it’s a different way of thinking about how those patterns or those components actually get built that treats them as if they’re part of the very fundamental nature of the site as opposed to just a reference guide.

Style guides or pattern libraries are often seen as a deliverable specifically for the people who are going to be extending just the interface. Just for front-end developers, maybe for front-end designers.

Ethan:

Yeah, no, I think that’s really important because I think that style guides or pattern libraries or whatever you want to call them, I think, at least in the design community—and I’ve definitely been guilty of this—they’re often seen as a deliverable specifically for the people who are going to be extending just the interface. Just for front-end developers, maybe for front-end designers to kind of get a catalog of all the different interface bits that go into being stitched together to build this responsive UI.

I think, to your point, there’s this big challenge with creating those documents as living documents, things that will maintain their state and maintain their usefulness even as the design gets updated. So there’s this whole marketplace of these small tools to kind of help automate that process so that creating a style guide isn’t this manual and copy/paste job, where you might pepper your CSS with some meaningful comments so that a tool can kind of go through and say, “Okay, well this chunk of styles kind of relates to this particular module, so I’m going to introduce an entry for that in the style guide.”

Which is just kind of interesting, because we’re basically building these lightweight content management systems to manage our front-end patterns when, I think to what you’re saying, the CMS should ultimately be kind of the arbiter of what these patterns look like and how they actually perform, and then essentially managing them all in the same place.

Wow, I’m reconstructing a little relational database to show information that’s in my content management system. I’m really angry at our industry right now.

Karen:

When I think about how much of web design and development is creating alternate systems to track and manage things that are in the CMS… It’s true, I mean all the giant spreadsheets that I make are essentially just a picture, a snapshot of what’s in the CMS. Sometimes those things get so complex. Like I’m working on one project right now where the giant spreadsheet is really kind of turning into a little relational database, and you realize, “Wow, I’m reconstructing a little relational database to show information that’s in my content management system. I’m really angry at our industry right now.”

What’s really exciting to me, is thinking about these not as just reference documents for designers and developers, but how could anybody at any point in this organization see it as an extension of your company’s visual language?

Ethan:

[laughs] Yeah, we definitely don’t have enough interfaces for things to be built automatically. Yeah, no, I think it’s really interesting because, to me at least—so there’s style guides and pattern libraries, which again, historically they’re really kind of designed for the web team, front-end engineers and designers. But I think what’s been happening more and more is organizations have been trying to broaden the scope a little bit of what these documents can actually do and actually creating design guidelines that sit on top of them. Like Salesforce has that Lightning design system they’ve published, Google has its Material interface guidelines, and they contain a whole bunch of front-end design patterns, but on top of that I think these are really seen as documents that could be accessible to the entire company. Like this is effectively a document that’s a platform for you to maintain and extend your organization’s visual language. This isn’t just a copy and paste document, this is really something that’s talking about what it is that we consider to be good design for our organization, and kind of by extension, how do we define good design for a new pattern that we might want to introduce in this system? That’s what’s really exciting to me, is thinking about these not as just reference documents for designers and developers, but how could anybody at any point in this organization see it as an extension of your company’s visual language? So, yeah, just broadening the audience a little bit.

When it comes time for me to start thinking about responsive design patterns, most of the hard work has been done usually on your end, by looking at the underlying content model that we’re trying to support.

Karen:

So, let me ask you, let’s say you were confronted with the hypothetical challenge of working with an organization that wanted to replatform their CMS, redesign their website. Where would you tell them to start? Like, what’s the state of the art given that what we’re recommending isn’t, “Let’s do a top-down redesign of your web pages starting with the home page,” but rather a bottom-up look at your underlying content structures and the design patterns that will inform them?

Ethan:

Well, I think if I could answer that question, my rent check would be paid for the next year or two. But no, I think, at least for me, I’m not sure I have a clear answer for that. But I think the beginnings of an answer, like the work we did for The Toast and the work that we’ve done with a couple other clients recently, at least when it comes time for me to start thinking about responsive design patterns, most of the hard work has been done usually on your end, by looking at the underlying content model that we’re trying to support.

The benefit for that, at least for me when the design language starts to be part of the conversation, is that it’s so much easier to actually name the interface, actually walk through the patterns and see how it actually ties to the underlying content model, and make recommendations for not just class names in the HTML and thinking about how the mechanics of the layout are going to work.

But it gives you a lot more flexibility in trying to make recommendations into like conditional loading, for example. The one example I keep coming back to is The Guardian, where they have all these wonderful examples of certain bits of content that are only loaded or brought into the design based on how wide the layout happens to be at that point, and they’re able to do that because the content structures are decoupled to an extent that they had so much more flexibility on the front end to make recommendations about how the design could adapt at different breakpoints.

Karen:

You know I’m the web’s biggest fan of conditional loading.

My starting point is always with the underlying structure of the content and the definition of what the CMS needs to do—not from an actual tool or package standpoint.

Ethan:

Well, yes. Threw that in there just for you. But yeah, it’s like those conversations on the modeling side, from a content standpoint, really set you up for a lot more flexibility and success on the patterning front, on the front-end. So, the starting point isn’t breakpoints in CSS or grid systems in Photoshop. Really, like you said, it has to begin a level below that. I don’t know, what’s your take? Where’s the real starting point?

Karen:

Well, I guess for me, my starting point is always with the underlying structure of the content and the definition of what the CMS needs to do—not from an actual tool or package standpoint. I think people too often jump to thinking that decision number one needs to be let’s pick which platform we’re going to build on—and while that’s obviously a very important decision, it’s not the one that should be driving the cart, I guess. It should be informed by your understanding of what your content patterns are, what your content model is, what the author experience is that you need to support. So what are your rules for workflow or roles and permissions, things like that. So, understanding as an organization what you want to do and what you want to support from that perspective completely independent of the platform is actually a really healthy and smart way to start.

And it’s not like I’m saying spend the next two years of your life sorting this out before you even get into that decision-making, but just spending even a few weeks having some planning discussions around particularly the underlying content structures. So, where do we want to reuse content? Where are the places on the site today where we’re copying and pasting content from one page to another? Where are we maintaining duplicate versions of content that could be handled through database magic? You often see people have, “Oh, we’ve got 400 versions of this page, all of which have these three pieces of information that are slightly different.” Well, maybe that’s not the most efficient way to handle things. It was probably the fastest way for you to solve for that problem in the short-term, but in the long-term as you’re planning how you want to handle things, maybe you need the capacity to set that up as a container that has just those three little bits of text stored in a structured way.

What’s really exciting to me is how the work that I would recommend from a content structure standpoint intersects with what you’re talking about for these design patterns.

That process of naming parts of your design and naming parts of your interface is a much more collaborative process.

Ethan:

Yeah. I think the one thing that I’m hearing from you is that it’s very much a conversation with many voices, right? Like this is a discussion that has to come internally from the organization to understand the different models they’re currently supporting and the ones that they want to support going forward. That’s at least, on the design patterns front, really been just a recent part of that whole practice. When people hear modular design, more often than not they tend to hear something like atomic design, that one methodology that Brad Frost coined for breaking the content and the interface down into these discrete chunks of reusable snippets of code and design.

The more sustainable way of doing that—and I think we’ve talked about this on the show a little bit—is to work with the organization to kind of come up with a system for naming these parts of the design that actually works for that organization. Trent Walton had this really great blog entry a couple months ago about how in projects that he’s worked on, that atomic design classification has actually introduced—I don’t know, there’s probably a better phrase than “organizational friction,” but I haven’t had enough coffee yet… Like, that metaphor of talking about certain parts of the design as either atoms or elements or organisms is great for front-end designers and developers, but when you’re actually talking with a larger team of non-technical actors, it doesn’t always scale. There’s often a bit of a disconnect between what the metaphor means and what the interface actually does in the context of the larger design system.

He cited a couple other examples of other people talking about that same challenge. But I think folks like Charlotte Jackson and Alla Kholmatova, they’ve written a couple of really great articles for A List Apart talking about how that process of naming parts of your design and naming parts of your interface is a much more collaborative process. So working with people to kind of break apart an interface in design review, cut it up with scissors and actually come up with a taxonomy for how these patterns need to be named in a way that’s going to make them meaningful to the people that are actually working with them. Yeah, that’s something that’s really exciting to me.

The real value comes from an organization having those conversations for themselves, not inheriting the styles and the language that are imposed on them by atomic design or, frankly, even something like Bootstrap.

Karen:

Yeah, I think you and I have seen people ask questions about, “How do you make a decision between what’s an atom and what’s a molecule and what’s an organism?” I guess it’s like you can feel their pain, because they’re spending a lot of time trying to parse out an aspect of a metaphor that is not actually giving them a lot of value. The real value comes from an organization having those conversations for themselves, not inheriting the styles and the language that are imposed on them by atomic design or, frankly, even something like Bootstrap, but rather saying for themselves, “What is this? What’s its purpose? How do we expect to use that?”

This leads to what I think is a related point, which is that—as you say—this process needs to have lots of voices, I would also say that this process needs to have a lot of buy-in. So, unfortunately it’s not something that one well-meaning but rogue developer can impose on a broader organization. It’s something that, as a lot of people have noted, the need to have almost executive-level support for your processes, like have CEO buy-in in what you’re doing, is what will drive the success of an initiative like this.

Ethan:

I couldn’t agree more, but one of the things I’ve been hearing, at least on the style guide standpoint, is how do you actually justify the cost of that visual patterning exercise to higher-ups? Maybe there are some lessons to be learned there from your end, from the content strategy and modeling standpoint. How do you actually justify the process of going through that exercise with people that are higher up in your organization?

It’s much faster and more maintainable to think of what you’re building as a component-driven system rather than as everybody doing a one-off.

Karen:

Well, I genuinely always believe that no executive cares about anything other than the value to the business. So, things like inconsistency in button styles may not be the motivating factor to the CEO that we in the web design world might like it to be.

Which is not to say that you can’t frame the goals for an initiative like this to be grounded in the value that the business will receive. I think we’ve talked to any number of people who have said that doing a pattern library and component-driven development is faster, it’s more consistent, it’s more maintainable. I remember talking to Niko Vijayaratnam from BBC News who said that this kind of system really focuses people on the fact that new patterns cost time and money, bespoke design is expensive. And even last week, talking to the guys from KLM, I think they wrapped up with some advice saying doing these kind of patterns really gets a lot of value for the organization. It’s much faster and more maintainable to think of what you’re building as a component-driven system rather than as everybody doing a one-off. So, I think you really, really have to frame it as not a problem with inconsistency in the brand identity—I mean, that’s a problem, but it’s not a problem that actually has a cost to the business. If you can frame it as something where, “Our development is going to be faster and more maintainable and we’re going to save money or make more money over the long term,” that’s what I think sells it to executives.

In larger organizations, where digital teams might be fragmented either organizationally or geographically, you’ve got people in different buildings in different parts of the country or different parts of the world making decisions about what the UI needs to do.

Ethan:

Yeah, I couldn’t agree more. And especially in larger organizations, where digital teams might be fragmented either organizationally or geographically, you’ve got people in different buildings in different parts of the country or different parts of the world making decisions about what the UI needs to do for their lines of business or for the product that they’re maintaining. I do think there can be some real savings from actually consolidating a lot of those decisions in some sort of document that documents, “Okay, well this is what the visual language says we should be doing with this particular challenge.”

I think we heard that from Livia Labate when we talked to her about Marriott, right? They recognized that there were going to be certain design patterns that they were going to need to solve at an organizational level and a more centralized way, but then they set up some broader principles to empower basically different parts of the company to make some of those decisions for themselves with some really effective Marriott-level parameters in place. I thought that kind of decentralized model was actually pretty compelling.

If selling the vision of personalization is what helps me get them a much more maintainable content store, then to me that’s a win-win.

Karen:

I liked what Liv had to say about how difficult it was to make a case for unifying the brand identity, but that they managed to bundle this work in with their larger responsive program. So, it wasn’t that they sold this, at least within Marriott, as a project unto itself, but rather framed it as this is just the right way to do it, like, “We have to do this work in order to achieve what our actual goal is.”

And I’ll say that I see similar parallels in doing a lot of the content modeling and structural content taxonomy work that I tend to do. A lot of organizations, like if I go in and try to sell them on a taxonomy and structured content, nobody wants to buy that. That’s not the sell that makes the executives’ eyes light up. But right now, everybody is hot on personalization, they’re hot on contextual or behavioral targeting. They want the ability to tailor the experience, to target the experience to particular characteristics of the user or what they know about where the user in the transaction flow. So, I can tell them—and it’s true—I can definitely go in and explain, “Hey, if that’s your goal, you’re not going to able to achieve that goal, and you’re certainly not going to be able to achieve that goal at scale unless you do this structural content work.” And the value that your organization will get goes beyond your personalization dreams, but if selling the vision of personalization is what helps me get them a much more maintainable content store, then to me that’s a win-win.

Ethan:

I’m picking up what you’re putting down, I think that sounds great. And at least from my end, more and more of my clients are actually starting to realize that—this is maybe a little deep in the weeds—their definition of mobile has been historically a little bit narrow. As people are getting a little bit more focused on developing markets or the fact that the web in general is just kind of like a shaky delivery medium, having patterns in a single, central repository that can actually talk to, “Okay, well here’s what the top shelf mobile experience is going to be, but also here’s what the bottom shelf mobile experience is going to be,” has actually been pretty effective for them as well.

Karen, as we’re starting to think about patterns and how they’re sort of associated with underlying content models, do you have any advice for people who might be starting a responsive redesign today? What are a couple things that you’d like them to keep in mind?

We’ve talked to lots of organizations that said having a componentized system in place made the responsive redesign a snap because a lot of the decisions had already been made, and then it was more about assembling the LEGO blocks.

Karen:

My advice would definitely be to start with the content model and the design patterns. So, even if you position that as the first step in a longer initiative to redesign the website or replatform the CMS, I think the initial process should be to start the conversation with the organization around what is our content model, what are our content types, how do we plan to support content reuse, what do we need to plan for as far as a taxonomy or other metadata? And then similarly, how do we start the conversation with the organization around what sorts of styles, patterns, and components we need to support? Having that in place upfront will make the redesign go more smoothly.

I think we’ve talked to lots of organizations that said having a componentized system in place made the responsive redesign a snap because a lot of the decisions had already been made, and then it was more about assembling the LEGO blocks than it was about starting from a blank canvas. But it will also make CMS conversations easier. Or I might even so far as to say if you have a content model in place and you have some of these design patterns in place, you can use that to inform your CMS development and wind up with something that actually builds those components into the back-end, which will get you so much more value over the long term.

Ethan:

I like everything you’re saying, that sounds great.

It’s incredibly important that not just the layout of these modules, but also the function and name of these modules should be as transparent as possible to everybody in your organization.

Karen:

Well how about you, Ethan? What kind of advice do you have for someone facing a problem like this?

Ethan:

Well, I’d echo everything you said, but I’d say that when you’re actually building the design system—I’ll come back to my earlier point about naming—I think it’s incredibly important that not just the layout of these modules, but also the function and name of these modules should be as transparent as possible to everybody in your organization. So that’s why I’d urge folks to take a hard look at defaulting to existing metaphors, like atomic design or Bootstrap or what have you, and really focusing on what does this element or this pattern actually mean to our organization? Where does it fit in the larger visual vocabulary? So walking through some of those exercises that Charlotte or that Alla have popularized I think is a really great exercise.

From there, though, I think it’s worth looking ahead to how the design system is going to be maintained at scale. Again, don’t think of this document as a snapshot of the interface at launch. This is really like the first citizen of your design; this is going to be a repository of all the parts of your visual language that go into your new responsive design and ideally it should change and adapt as that responsive design does. So this brings in a whole bunch of questions of maintenance, not just how do you actually build the thing but also who governs it. Who makes decisions about what new patterns get incorporated, how patterns change over time? Is that made within a single design systems team, are different lines of business making these decisions? And if so, how do these get documented and shared? Jina Bolton wrote this really wonderful article about the different models that they’ve tried at Salesforce for maintaining their design system and I think that’s a really interesting problem to me, is thinking about how is this document going to be part of our overall visual look and how do we preserve it in time? So, I think that’s where I’m standing right now.

Karen:

Well Ethan, it is always a pleasure to get to talk to you, sometimes while we’re recording.

Ethan:

[laughs] I do love our little chats, especially when, yeah, that red button gets pushed. So, thanks for your time, Karen.

Karen:

Well, I’d like to then say to anybody out there, if you are facing challenges like this, don’t hesitate to contact me and Ethan. You can go to responsivewebdesign.com and there’s a little form you can fill out. And I’d also like to say thanks to our sponsor, Media Temple. We’re really grateful to have them sponsoring the podcast this quarter, and you can go to mediatemple.net and find out a little bit more about them. And with that, we will be back next week.