Newfangled works with independent agencies to create lead development web platforms for their clients.

Newfangled works with independent agencies to create lead development web platforms for their clients.

Web design has changed.      Have you?



Introduction

Design is in flux. Thank goodness that's always been true. The web began a major paradigm shift for design — a print-to-web transition that, remarkably, is ongoing for plenty of designers. You might think that anyone still making the print-to-web transition is a lost cause, too far behind to ever catch up. But I don't know. Maybe they'll be OK. Maybe it's the rest of us who have gotten comfortable with "web design" over the last decade that will struggle continuing to transition. Because it's not over yet. The internet has given us the gift of perpetual change, batteries not included. That means it's our job to recharge and press on. That's what I want to talk about here. Are you with me? Good. Get comfortable.

I want to start with a more recent development — this idea of modular content — and how it is changing our design practice, and then work my way back to some of the things that have become "fundamental" to web design. If you're not angry with me by the end, then I've probably not done this right ;)

And yeah, it's going to be long. What else is new?

 

Modular dis-Content

Modular content is the web design industry's response to the need for two things: (1) greater creative freedom without (2) "design phase" template bloat. Rather than being the template to end all templates (though I like the sound of that), it's an approach that affords an enormous amount of design and content flexibility on any page, which liberates all of us from the long, drawn-out template-buffet of the pre-production "design phase." Because there's so little you cannot do with it, you no longer have to try to think of everything you might want to do and create as many unique boxes that commit you to doing those things months before you actually start using your website. For years now, that's essentially what the "prototyping" and "design" phases have been about. And for some of that time, I've been pushing on the idea that there really is no "design phase" — it's all design. Creating a prototype is design. Creating mood boards is design. Creating template layouts is design. Programming all of that is design. Etc. Well, modular content makes that a whole lot easier to swallow because it forces us to think in design system terms from the moment we begin considering our content strategy, not just when we're ready to "add the pretty." In fact, we're showing our clients how modular content works and giving them a sandbox to play with it on day one — before we prototype anything — so that an understanding of how it works and what it can do will shape every strategic and design decision they make.

But you know all this already because you read January's article on modular content, right?

I thought that modular content would reduce template bloat. I figured that with such a powerful and expansive set of tools, we designers would no longer feel the need to create so many different templates. I was hoping that we would stop worrying and learn to love the CMS. Unfortunately, this hasn't happened. Not yet, anyway.

Instead, I'm seeing the exact opposite of what I expected. The unexpected has come in two varieties:

  1. More gimme more
  2. If it's gonna be this kind of party, I'm gonna…

More gimme more

I'm seeing a lot of "oh yes, we're modular now, but we're doing these two or three things just a bit differently and adding this one other thing." So, in other words, template bloat as usual. What's surprising is how the appetite for "something different" persists despite being absolutely unnecessary. We've just been granted access to the most sumptuous buffet ever and yet we cannot help but feel it'd be just a bit more splendid if we ordered a few other dishes off the menu, oh and can I have the dressing on the side?

The whole idea behind modular content is to reduce the need for differentiating between content types on the basis of unique page templates to contain them. If every page can be flexibly arranged using a variety of media, there's little need for programming a different structure or container for the various forms of content we're likely to create. Things like blog posts, articles, case studies, etc. used to need their own, dedicated template. Now, they don't. Right there, we went from three different pages that needed to be visualized and programmed differently to one. Except I've yet to see that level of consolidation. There's always something we must have that forces our developer friends to create a unique template that adds to the modular tool set or makes some exception to it.

If it's gonna be this kind of party, I'm gonna…

But how is this not overkill? Just plain old, run-of-the-mill getting carried away with ourselves? What is a webpage but text and media? How much complexity are we willing to add to that basic recipe before we realize that we're ________. Well, insert whichever metaphor is most effective there. Bringing a bazooka to a bar fight. Sleeping in cargo pants. Going to Taco Town. You get the idea. With modular content, we can make our pages as complex as we want, but most of the time, what we really need is just a column of text and the occasional image.

But let's say that we do need something more complex. Say, for a landing page for a new product or service. That's where modular content really shines. It's meant to make it easy for us to create that complex page without running into limitations or "no's" from our friendly neighborhood developers. Need a page with full-bleed slideshows, rows of text, videos with text wrapping around them, three column text areas, and CTA's embedded within text areas? Easy. As long as we've got the time. But modular content is still a system, which means that it's going to have some global rules behind it. This is a good thing. It preserves consistency of design and use. But unless we understand that, we end up with Taco Town, or actually, I'm going to go with some other town. For example…

slideshow.png

Welcome to Tinsel Town

Modular content makes it possible for a designer to put slideshows anywhere. We could put one at the top of our page that goes edge to edge. We could put one someplace further down that is half the page's width and sits to the left of a body of text. We could put one in the middle of a column of text on the left and a video on the right. That's probably a bad idea, but we can do it. But no matter where we put that slideshow, it's going to work by the same fundamental rules. It's controls will be the same. It's transition animations will be the same.

This is because the slideshow is a centralized media object. How it works has been programmed once. Modular content assumes that we'll decide where to use it and what it contains later. But it doesn't let us change the rules every time we use it. That would be more work for us, and more work for our users who would now have to re-learn how it works every time they encounter it. This is the same principle that makes for one "headline" style in a website's typography so that we can wrap some text in a "headline" tag and always know it's going to be black 14pt Helvetica.

Makes sense, right? You'd think.

Just the other day, I looked at a website design that had three slideshows styled completely differently (meaning different controls, different ways of previewing thumbnails of upcoming images, different chrome) — and intended to work completely differently (meaning some contained mixed media and some actually opened images in lightbox overlays once you clicked them) — on the same page. On the saaaaame page! Look, your webpage isn't a truckstop Christmas tree, so stop treating it that way. Media ain't tinsel, but it sure can be just as tacky if you let it. The point is, this is all not good. It's not good for design. It's not good for usability. It's not a good use of anyone's time. And, more importantly, it's a misunderstanding of the system beneath modular content.

I've seen the same thing with virtually every other element that can be styled on a page. Here are just a few examples:

  • Multiple forms of text link styling in the same body paragraph. Why on Earth. Do you hate your users?
  • Different video players with different chrome, controls and logic on the same page.
  • Different padding, rules, and type styling for rows of text on the same page.

It goes on and on. I thought modular content was all the "more" we needed but apparently more is the new more.

And here's the thing: It's not "clients" who are driving us to Taco Town — this is not at all a Clients from Hell-style rant — it's us. Designers. We think that more is going to impress our clients, which is Un-strategic Weak Myopic Design 101. Clients want the right thing, not the fanciest thing.

I realize I'm being a bit snarky. And to be fair, I do think I understand why this is happening. Part of it is psychological, of course. That's why Taco Town is funny — we can all relate to wanting more even when more is absurd. Once you get more, it's no longer more, so then you want more. It's worth noting that the diners don't want a pancake-dipped, pizza-wrapped, triple-layer taco; it's the marketers who think that's what they want.

But the other part has to do with method. We've got an entirely new way of creating content on the web, but we're still using our very old way of visualizing it. That's not doing us any favors. We'll never stop template bloat until we stop templates. Templates gonna bloat.

So, the solution. I think it comes in two forms: (1) a change in method, which will probably prompt (2) a change in materials.

 

It's time for a new method

Prototype → Mood Boards → Layouts → Production

That is the process we've followed for years. We'd document our information architecture decisions in the prototype and our visual language decisions in the mood boards, and then merge them together and document that with page layouts created in Photoshop. Then we'd hand all of that over to the developers, who would use our documentation to build the website. In general, it's a pretty good process. It allows everyone to do the right kind of thinking at the right times and make decisions that support future decisions in a logical sequence. This is especially true of isolating IA in prototyping and visual language in mood boards, so I'm not going to suggest we change that. It's in the "layouts" step that we're typically running into the most problems, and I think that has to do with "layouts" being a mostly outmoded concept. As I've already pointed out, modular content obviates the need for most of the differentiated templates we used to create.

lookynoclicky.png

But even before modular content entered the conversation, the "layouts" phase still introduced plenty of problems. Procedurally, the idea was to follow a "narrowing funnel" of decision-making. So, you'd start with one of the more complex templates from the prototype — one that contained the greatest diversity of visual elements — and use it to put the visual language of the mood boards to work. For an e-commerce site, for example, this is typically a product detail page. Creating a layout for it gives you the opportunity to work out all kinds of details — typography, iconography, buttons, forms, sorting tools, and the like — as well as the site's global elements, like the header, main navigation area, sidebars, and footer. If you can get your client's approval on a template like that, you'll have done most of the heavy design lifting, and later templates will inherit many of the decisions made there. That's the idea, anyway.

It was, of course, quite common to have worked your way through a precedent-setting template like this one only to receive feedback on a later template that called the entire color scheme into question. All of the sudden, the funnel image falls apart. What tends to take shape is a long and not-so-narrowing cycle of how about now? how about now? how about now? This is painfully slow and labor-intensive because we have to go back to our Photoshop files, make changes, save an image of them, and then show them to our clients. And then, of course, ask, how about now? Every time we ask that, we're really asking our clients to imagine whether or not what we're showing them is the best solution. But nobody is good at this! Nobody really knows if what they're looking at is a good solution until they start using it.

Styleguides

Starting with the most visually complex template is almost the right idea, because it's an attempt to establish a system for the website's visual language. The language itself — in the form of typography, color palette, textures, and imagery — has been worked through in mood boards. But now we need to turn it into a system. Starting that with real content, whether it's a product or an existing article, makes a lot of sense because it will take that language and put it to work on something real.

It's what we do next that matters most.

Instead of forcing our clients to approve that template and then moving on to another one, our next step should be to create a comprehensive styleguide. Using the prototype as its source it would document every form the website's content could take. It would show the full typographical system (headlines, sub-headlines, body, block quotes, links, etc.), how page content could be arranged, image sizes and aspect ratios, padding and margin rules around page elements, buttons, form elements, avatars, and any other visual component of a page. A styleguide is extensive. It could look like a webpage, just like a mood board can at first glance, but closer inspection would reveal that it is more of conceptual schematic than a visualization of how an actual page might take shape. What's important is that it articulates a system for the website's visual language and its logic, but leaves specific arrangement commitments for later.

styleguide2.png

Approval of the styleguide might require a few template-specific extrapolations, especially because the modular content system isn't going to replace the need for unique templates for content that — like a product — has specialized field sets that need to be parsed and/or tied in with other areas of the site. So you might need to show one or two images of how this system might look on a specific type of page to get sign-off on the system. But the point is to avoid doing that for every page on the site in order to get to "design approval" and begin production.

Following this process means that once production has begun, you won't have "designed" every possible detail. But the idea that you can do that — by creating a heap of template layouts before production begins — is an illusion, anyway. I have never worked on a website project where something pretty important hasn't come to light only after the client has started to use their new site and contribute to the QA process. It's that old David Kelley insight again: you never learn anything until you start showing it to people. It doesn't matter how smart you are. So following a process that is structured on the basis of capturing everything before production isn't just naive, it's disingenuous. You're going to spend the time getting it right, but it's most efficiently spent when everyone is looking at the actual thing, not pictures of it.

Pattern Libraries

Once you have gotten it right — and yes, if this is new it's going to be an uncomfortable synthesis of production and design — you can finally document the visual language in the form of a pattern library. The difference between a styleguide and a pattern library is that a styleguide is a visual document — it can live in Photoshop and stay there if that's your preference — but a pattern library is an organized collection of all of those visual elements in the form of the code that is used on your site. The folks over at MailChimp explain it well:

"[A pattern library] is a byproduct of our move to a responsive, nimble, and intuitive app. Constant iteration requires both an efficient workflow and a well defined collection of atomic elements that can assemble new UIs quickly without accruing new technical or design debt."

While a styleguide is the best possible map to carry in to production, a pattern library is the best possible map to document the actual path you took and hand it off to everyone who's going to need to navigate it later. It's an investment in the future growth of your website. Think of it as if a restaurant included a list of every ingredient needed to make every dish on the menu, but instead of words and pictures, it included the actual food. Impossible IRL; possible on the web. Now, some people use "styleguide" and "pattern library" interchangeably. Yelp's styleguide, for example, is in a form that I'd call a pattern library — because it's clickable and contains actual code snippets, whereas a styleguide could be a purely visual document. But ultimately, the semantics don't matter that much. The point is that this documentation exists at all, which makes me hopeful. So, in other words, the future is now, guys, and it's pretty tight. The only thing holding it back is people like us who are still stuck in our Adobe caves.

patternlibrary.png

Granted, something like this works especially well for a site or environment like Mailchimp that executes much of its visual language with markup techniques rather than images that need to be sliced up and referenced in the code, and that also uses a minimalistic visual language. That being said, the capabilities of CSS and SVG code are beyond incredible at this point. There's little that you might create in Photoshop or Illustrator that they can't do, and better. The advantage to using Semantic SVG is that the imagery on your page can be as responsive as the rest of your page. Don't believe me? Have a look at Iconic. Of course, it's code, which is typically on the other side of that designer/developer line we designers like to keep so straight and narrow. Now, tools like Iconic do the heavy lifting for you, so you don't have to go full developer yet. But this pattern library and Semantic SVG stuff should make us think a bit more critically about our materials.

 

It's Time for New Materials

What I find the most interesting about pattern libraries is that they show how important it is to differentiate between the materials we use for creative purposes, and the materials we use for documentation.

A pattern library is a form of documentation. It's a resource that retains its value during and after a project, which, I think, is pretty different from how we web designers have typically thought of our Photoshop files. In my experience, the PSD has been mostly a container for creation, and sometimes a form of documentation, but even then, it's usually meant to inform a developer, who will then turn its layers into something we can actually use. Once that happens, the PSD is left behind. It becomes a relic — a sketch of something that fully exists now in a very different form. So let's consider Photoshop then, as a creative environment and as a documentation format. And I'll beg your pardon in advance; there's a bit of a rant here.

Photoshop?

So many designers like to think of themselves as leaders. Some even call themselves "change agents." Really? Show me the change. I think we like the idea of change more than change itself. We like associating ourselves with the sexy aesthetic of futurity, but then we go back to our caves and do old things the old way.

Boooo! You cry. I know, you're about to send me a link to Ethan Marcotte's website, or Brad Frost's, or Scott Jehl's — pretty much you just want me to read the entire A Book Apart library — and you're right, they're out there, and they're great, and they're nailing it. But they are the few.

You show me one designer actually embracing change, and I'll show you five who send developers InDesign or Illustrator documents. You show me one designer doing something novel, and I'll show you five who take screenshots of other websites and paste them into their comps. I'm not kidding. I see that stuff all_the_time. Still. Honestly, if you're creating things for the screen in InDesign or Illustrator, I would rather you just use pencil and paper. Hand that sketch to a developer and there will be far less moaning and groaning than there will be when they can't even open your file. And really, lots of designers use pencil and paper for ideation because it's fast and doesn't waylay them in layer-land when what they really want to do is get into real production.

But, that doesn't mean Photoshop is a bad tool for creative purposes, it just means that it tends to keep designers within its "walls" for far too long. So, when it comes to creation, if you're going to be committed to some piece of software, Photoshop should probably be it. It's meant for screen-y things, after all.

But, is Photoshop the best documentation tool? More and more, I'm thinking no. Insofar as I find myself asking "what happens when…" and not finding an answer in its layers and notes, I find Photoshop to be lacking in some pretty-essential-to-interactive-design ways. If you want to show me what happens when a design's context is a very tiny screen — or a very, very large one — you have to create a whole new document or layer group with its own dimensions and then recreate all your visual elements. You may or may not have the time or patience to do that.

But speaking from experience, my five-to-one-designer-complaint ratio doesn't carry over here. I'd love to say that for every designer that has thought through responsiveness in every context and documented it, there are five that either do a partial job or don't at all. But it's worse than that. Typically, it's a one or two that have thought it all through — thanks to getting input from everyone and making responsive a starting point, not an afterward — and painstakingly documented it in several annotated, layered documents (and I adore those designers, truly), five that haven't at all or have completely missed the point of responsiveness and have dreamed up some truly wacky "mobile site" that bears no logical relationship to the "desktop site," and one who respects her time enough to ideate in Photoshop and then document it using actual markup.

Uh oh. Designers and code. I'm gonna go there.

So back to my favorite designer ever. Right, I said "markup." Which means she actually learned some "code." Like, the most basic HTML and CSS and maybe even a little Javascript. She went over to Treehouse and made a tiny investment in her own future and sanity or Codeacademy and got it for free for goodness sake. So, look, we're not talking about hacking into the mainframe or anything here. We're talking about markup.

So am I saying designers should be developers? No. I think there's a pretty important difference between designers gaining some code literacy and designers becoming developers. It's a subtle difference, yes, but it's a meaningful one. What I'm suggesting is this: (1) Designers who explore and learn some markup will quickly find that it improves their work, regardless of whether they practice any coding professionally. Understanding how visual things are described and manifest on the web — the logic and system beneath the typography, colors, and shapes that we love — will enable us to produce more thoughtful, useful, and realistic work. (2) Designers who can document their work in markup form will find that the integrity of their designs will be better preserved, and that they will help to accelerate the production process as they move more and more of their creative practice out of Photoshop and into markup. Neither of these things mean that designers should become developers. The larger the team a designer finds herself on, the more likely it will be that she can be specialized, both in role and practice. But when that team is smaller — or when a designer is working alone — code is unavoidable. There's no reason to fear code. It doesn't threaten design. What threatens design is incompetency, and continuing to use antiquated tools and resist learning how the thing you're designing for actually works is the fastest route to it.

At the other end of this rant is a simple premise: Change is required of us. For designers, this is what change looks like. We have to let go of all the trappings of design that we've held dear for so long — pixel perfection, layouts, templates, even Photoshop — and learn to love the new tools of the trade. There can be no bystanding. Remember that Seinfeld bit, about how some people just want to hang out in the area where work is bein' done but not actually do the work themselves? That.

So, are we designers or are we JPEG-makers? Some food for thought.

 

Postscript

Practicality is a drag. It's the thing that keeps a frustratingly wide gap between recognizing things you could do better and being able to say "we don't do that anymore." Sometimes, no matter how quickly you can acknowledge the need for change, actually bringing about that change has to be a bit slower. If you want to redo the plumbing, you have to turn off the water. Except most of us can't turn off the water, can we? We've got to keep working. That's why, no matter how cutting edge a company may appear, look closely enough and you'll find the old-school. I guarantee it. It's there somewhere. I say all of this to offset any pressure I may have put on you, or any unreasonable expectation I may have set, or any impression I may have given you that we have it all figured out. To the contrary. I'm writing this like a first-year teacher — just one week ahead of the lesson plan, if you know what I mean. In many ways, we're doing things that are absolutely on the forefront, but in other ways, we're still catching up. So, hi. I'm Chris, and I don't have a time machine.

But I'm encouraged, because if there's one thing I've learned from spending so much time figuring out how to do this stuff better, it's that we all are. These are just my notes from the field. I hope they're of some use to you.

Comments

Darjan | April 2, 2014 5:56 PM
Thanks for the follow up on your earlier post. Had me thinking a lot at that time about the change in the design process of the websites. I think the styleguide is a great way to do it, i would just like to add the "branding" part to it. Good branding already has a system and i think it has to work well with the website too so having a styleguide that connects with it would have a strong visual story.

Today i see a lot of visual page builders/composers and there are a lot of templates with options that are blown out with customisable modules that you need to setup for each page.

They should be setup only once and then locked. Just like the brand book guidelines etc. You don't play with those. Each of those sites with the clients having too much freedom with their websites/modules have become really bad.

They should rather focus on content creating and we need to give them couple of modules/choices that bring that present that content as best as possible. Locking stuff for them may be a bit templateish, but we need to keep the control to a point where there is no damage made.
Ben Weeks | March 22, 2014 8:17 PM
"It's time for a new method
Prototype ? Mood Boards ? Layouts ? Production"

Is that the new method or the old one? If it's the old, what's the new?
Dan | March 21, 2014 3:01 PM
I think you're getting at this but isn't the biggest advantage to not being "waylayed in layer-land" that it acknowledges the reality of revisions and what it's like to deal with them? Once something is coded, it usually goes through a series of revisions before it's put live. I guess that's at the heart of your Kelley reference, but you didn't mention iterative or agile at all...
Christopher Butler | March 21, 2014 1:31 PM
Sam: I guess that's one way of looking at it, albeit slightly cynical (unless I'm still not getting your point). I'd probably challenge it on the basis of two points. (1) The designers who worry about protecting their work from the client are rarely the ones who create content management systems. In fact, it's been my experience that designers tend to feel at odds with the CMS because of creative limitations — hence my framing of modular content as supporting creativity. (2) On the other hand, I think a better historical understanding of why the CMS itself exists is because it offers stability and scalability to the user ("client" or not), not as a layer of protection over the designer's work. Again, my experience has been — and honestly, I haven't seen this in years — that designers were more interested in leaving their mark on global elements of a website precisely because those were the things that the CMS didn't give users access to (e.g. website chrome). But good designers have caught on to the fact that good website design is not container design. It's not about designing packaging for content that needs to be preserved. It is about designing a framework for their clients to use. So, I guess ultimately, I see modular content as better for designers and better for clients and not creating a zero-sum game between making and serving. I think it supports both.
Sam | March 21, 2014 12:19 PM
Yeah, I think it's still confusing to me too. Here's the progression I think...
Designers used to protect their work from the client. (keep it like I made it)
Designers then protected their work from users of the CMS. (do what you want within this framework)
Designers now (with the processes you suggest above) are protecting the AUDIENCE from the users of the CMS (I've thought of every scenario, here are the patterns).
I think the difference is that the designer is moving from defending what they "make" (as an absolute) to ensuring that the audience is able to receive an idea, regardless of the action of the CMS users. The designer takes measures to ensure that the audience is well served, despite the actions of the CMS user.
Like I said, I'm not sure if this is good or bad, but it strikes me a shift from making to serving. IDK.
Christopher Butler | March 21, 2014 10:08 AM
Andy: I think there are a few possible band names available in this post. I hope "The JPG-Makers" isn't already taken ;)

Evan: You know what? What you said about consensus is really a perfect assessment of how this stuff works. It reminds me of the late nineties/early 2000s when minidiscs were available. I adored them. I thought they were the perfect format. Higher quality than CDs, smaller, un-scratchable, players that made direct recording easy. I was studying film then, and everyone used them to do onsite sound recording. BUT, they never caught on. The consensus remained that CDs were better long enough for MP3s to catch on. And really, it wasn't the MP3 format that caught on — it was the player and the marketplace that did that. So you're right. Modular content is catching on not for any under-the-hood reasons, but for experiential reasons. It addresses the needs of the process, both before and after launch.

Perla: I think that depends upon their capabilities and comfort level with markup. If a designer can translate their sketch or PSD into an actual browser-viewable page, that would be great. Getting to that point means that everything that looked cool in the PSD has been put to the reality test insofar as it's possible to do. The next question, of course, is whether it's feasible to manage and how might that work. But that's what I had in mind. Iterating from there is far less time consuming than going back to the PSD every time you want to make a change, resaving an image (and or images if there are variants — which there always are), and then re-sharing them with your client. If you're asking about actual coding standards, that's probably way too much for the comments — there's so much there! Is that what you meant?

Sam: (1) You're right — creativity isn't the only thing there. It's definitely a selling point, in that modular content gives much more latitude for future decision making, but there are plenty of other points that are compelling. Efficiency, simplicity, ease of use, etc. Your lego analogy is pretty apt. I was thinking about how this modular approach is manifest in other content management systems and it made me realize that legos are great because they're just a simple idea in a huge amount of variety — interlocking blocks. What you do with them is up to you. But in some content management systems, you can only play with the blocks in the lego store. If you want to leave, you leave the blocks — and whatever you built with them — behind. The better approach is to use a tool that lets you take the blocks home with you. Because, as you point out, it's not really about the blocks per se, it's about what you make with them. (2) I'm not sure I get what you mean. Or maybe I've just not encountered what you're describing. Can you explain what you mean by "protecting the end audiences from the content editors"?
Sam | March 21, 2014 8:47 AM
Another excellent post Chris. I'm in full agreement. Two notions:
1. Modular design doesn't explicitly promote "creativity" in my mind. It is true design: elegantly resolving as many scenarios as possible. However, it reminds me of the of the Herbie the Love Bug Lego kit. When assembled, it sort of looked like Herbie, but it was still clearly made up of Lego blocks. And it would never smell like gas (maybe nerd finger sweat, but not gas). That's a vanity sentence to say, how does modular design get us to a solution that is truly whole?
2. I can't help but think there is a punitive element at play here. There's a bit of a movement in the design community that places priority on protecting the end audiences from the content editors. I'm not sure this is necessarily bad, but it is a new element (political, off-objective and possibly stifling) that should be considered. What are your thoughts?
Perla | March 20, 2014 7:06 PM
Thank you! This was a great read, since I'm currently working on my website re-design, currently not responsive boo me! :( , I'll definitely take into to consideration the modular approach into my design.

I also really enjoyed reading the "Photoshop?" section, instead of high fidelity mockups we sometimes use wireframes such as Balsamiq and jump right into implementation. It works for some clients.

Can you elaborate a little more on how designers should document their work in markup? I like to think I'm doing an ok job, but I may be completely off. Maybe you have an article on this already.

Thanks again! :D
Evan Mullins | March 20, 2014 2:05 PM
Spot on! I've really been moving toward modular content without even knowing what to call it. I've been thinking of the whole web design process a LOT lately and working on overhauling it in my agency. I've been stuck on the wireframe stage, because my technical/traditional side wanted to wireframe every template, but my (hm) "other" side wanted to just use styletiles or something. I think this pattern library or styleguide is where it's at. Just show it all on one page and then, instead of templates, using a modular approach - give the client the POWER to place whatever module wherever they want on whichever page they want. It's about designing and then uilding a system that powers it. Thanks for sharing, even though - no, especially since you're just a week ahead of the lesson plan as you say. I think many agencies are in the same boat and reading articles like this really give a sense that as a group we're coming to the same consensus.
Andy Fraser | March 20, 2014 1:19 PM
Thank you for the continued consideration of creative tension between the art and the science. And more importantly, I think I just found our new band name—Truckstop Christmas Tree
Ben Weeks | March 20, 2014 12:19 PM
For more CSS happy icons see Symbolset
http://symbolset.com/
Christopher Butler | March 20, 2014 8:17 AM
Frank: Your comment is more incisive than you may know! I had originally organized this article as a sort of "designer intervention," beginning it with something like, "Hey designers, we need to talk…" and one of my section headings was "You say you love simplicity, but you do not actually love simplicity." I ultimately decided to reframe this so as to offend the least number of readers possible :) But you're right. Synergy, buddy.

Erica: Good question. I'm definitely not suggesting that we never show our clients a layout ever again. As I mentioned, there are going to be plenty of scenarios where showing specific page layouts is still going to make sense. What I'm trying to change is the practice where we show a layout for every page because every page has its own template — these issues are tough to decouple, which is why this article pairs with the one about modular content. I think the way forward is to offer better tools that liberate us (and our clients) from the template, and then our design practice should follow suit. That being said, just the other day I was chatting with some of our team about a project we're working on now, and one of our Project Managers voiced the same concern you did — that the client is likely to be confused by seeing a styleguide. You and he are likely correct, and it's important that we remain sensitive to the client experience of the design process. In that case, we have an opportunity to show a styleguide and explain how it works and how it should be responded to. That will probably be made much easier if we can also show a page layout along with the styleguide, so our client can see how this system can manifest in a page. When it comes to many of our other "pages," though — and this speaks to how we approach IA in the prototype just as much as the creative production process — I think we need to embrace the modular approach and consider these pages as hypotheticals, or possible arrangements of content based upon the latitude the tools provide. Another stray thought: the images we use to show design to our clients set expectations, as you point out, but they also track decision making. That's where things can get out of hand — erode our and the client's sense of progress, increase tension, spend budget, etc. — but then, many of those decisions are remade once the thing is used anyway! So why not get into that sooner? We're not going to change the fact that anyone might see something in use and then reconsider a choice they'd made earlier, when all they had access to was a static image — when they say, "oh, could we tighten the space here" or, "can we change this color" or "can we change this font?" But responding to these requests by updating a PSD, exporting an image, posting it somewhere, and then waiting for feedback is way too slow. Why not just tweak it in the browser? Inspect the element, tweak the CSS, show the client, and then, if they like what they see, commit the changes in the CSS? It's a really simple thing to do, but it requires that we embrace a much more flexible process (as well as get more comfortable with markup). Thanks for reading!
erica m | March 20, 2014 6:55 AM
I've been working in design for over a decade and you really spoke to so many of the pain points I've experienced. Thank you!

One question: If you don't show layouts to a client, then how do you satisfy their need to "see" what thier site is going to look like? I think many people who don't work in design would struggle with not being able to see some kind of mockup and react to it and I would think that a stylesheet could confuse them. Maybe I misread you? Would love to hear your thoughts on this, Chris.

And thanks again for such a rousing call to arms :D
WP Learner | March 19, 2014 10:08 PM
I love your last article about modular design. I used your concept to build my new website. The idea of pattern libraries and style guides are great to help developing a consistent design throughout the website. And I will try to implement these in future designs as well. Keep up the good work!
Frank | March 19, 2014 6:43 AM
Talk about opening a can of worms! I think you've blown one up completely. This is a great post and I'm still making sense of all of what you have to say.

It feels like you're really talking about simplicity. We say we love simplicity and then we write books about it. LOL. You're pointing out that the tools we make that are supposed to offer simplicity we end up using to make things more complicated again. There's so much to that. I'm going to be thinking about it all day, especially the next time I open Photoshop... which will probably be in the next fifteen minutes!

"Do you hate your users?"

That should be OSHA-level required signage in design offices. Like did you wash your hands at a restaurant.

↑ top