If you work in the web industry on large or complicated projects, you’ve most likely heard the phrase “We’ll just hardcode it” thrown around. Usually, it’s in response to a one-off flashy element for a single page. This is almost always a bad sign.
This impulse generally comes up after the initial discovery period when everyone is excited and tossing out all ideas. In an effort to trim those ideas down for a tight timeline or budget constraint, we’re all tempted to ignore our better judgment in favor of something we know will really wow the client. In that situation, sustainability is almost always the first thing cut.
No surprises here: flashy things are cool. Long term sustainability is not.
But when teams do opt for a less sustainable option, and even if they feel like they have done their due diligence to explain the pros and cons to the client, the client is still always shocked when they want to add a new page and have to go through the design team again.
Because that’s ridiculous, of course. It’s our responsibility as people who make things for the web not to let that happen, and that job starts with the Content and UX teams on day 1.
A Focus on Modularity
There are a lot of aspects that go into designing sustainably, one of which is modularity. At its core, Modularity is a focus on building standardized units so that we can more quickly put together a variety of formations for a variety of different needs.
A focus on modularity keeps the code clean, allows for faster updates and iterations, and creates predictable systems so that we can spend more time focusing on bigger issues. Think of it like lego blocks: if you had to re-build each block every time you built a castle, you’d spend all day on building a single wall. With the blocks already built, you’re able to focus on how many turrets you want, or how long the drawbridge should be. You know, the fun stuff.
But this isn’t a new idea. There’s a lot of really smart people that have been saying for years that the future of digital design is in modular systems. If you haven’t already, I’d check out Brad Frost’s Atomic Design, Pattern Lab, Eric Bidelman’s talk on Web Components, and Dave Rupert’s Responsive Deliverables.
It Doesn’t Just “Become Sustainable” in Code
The downside of all the talk about modularity? It’s discussed a lot in development circles, and not nearly as much between designers or content strategists.
Often strategists view it as a development responsibility, but it’s time to start taking on some of that responsibility ourselves. Not only is it more efficient from a workflow standpoint, but as strategists, we can leverage our standpoint between the client and the users to plan for long-term growth.
We already have the unique position of translating the human part of the equation into what we build. With our insight into the user’s needs, we can bring a lot of value into designing how we build the system too. After all, no true modular system just becomes modular halfway through.
How to Do It
Doing content strategy and information architecture in a modular way is actually very systematic. There are four main steps: assessing the user needs and content types, defining each content type by it’s elements, narrowing down repeatable blocks, then building and testing the system. I’d encourage you to keep the pieces that resonate with you or chime in with your own strategies. Every project is different.
Starting With Content
Every project starts with at least some level of Content Strategy. At its most simplistic level, Content Strategy is evaluating what content will be on the site and how it will be consumed by the end user. You may be lucky and working with a Content Strategist, or you may be responsible for doing the Content Strategy, but this approach works in either scenario.
After auditing the existing content, evaluating business and user goals, and planning for new content, the Content Strategist will typically put together a prioritized list of what types of things need to be on each page of the site, called a page table or content template. Here you’ll have a list of content items like “Aspirational Imagery” or “1 Paragraph of copy describing why Company X is a great place to work.”
For example, I’ve created a fictional page table for this exercise.
This speaks the client’s language, it’s easy to understand, and gives a clear outline of what type of content is needed. This prevents us from having last minute surprise content and also prevents us from designing and building elements that no one writes content for.
The problem is: there is still a long way between this and a working development requirements doc. There’s really nothing modular about a page table, because it’s focus is on human needs, not page structure or systems design.
Building a predictable system to meet these varied and complex content needs requires an act of translation. The first step is to start with breaking down and defining each of these content types by their basic elements.
From Page Tables to Elements
Listing elements primarily involves writing quick technical definitions of what each content type requires. This is the easy part. It’s important to cover every element required to build each piece of content, including titles, instructional copy, and buttons.
Ex. “Careers CTA” would have the elements: Title, 1 Sentence Description, Button
I’ve listed these out in column C below.
While each step in this process is designed to be sequential, you may need to revisit these answers along the way. As long as you consider fallout in columns D and E, it’s fair to expect this to be tweaked.
From Elements to Blocks
Once each element is listed out, it’s time to do some pattern matching. Any grouping that lists on multiple pages we’ll consider a “block.” For example, if the newsletter signup needs to appear on three different pages and look the same on each page, that is one block.
Pick a color to assign to each block. It’s not pretty, but makes the next step much easier. Leave any block that only appears on one page in black.
From here, we know we need a WYSIWYG block on each one of these pages. We also know that we need a Contact block on two of the pages (Home, About Us), but on the About Us page that block needs one additional piece of information: a photo. Make a note of it in the notes column.
While you’re going through, you also need to consider if any content types can be combined. For example, on the About Us page, the “Our History” text area and “Our Mission” text area can most likely be combined into one WYSIWYG. It’s less sustainable to break these out into two sections because it will be harder for the client to manage long term. It may help you to remember if you merge the two cells into one, shown below.
Continue until you’ve gone through every piece of content in the page tables. Now is a good time to audit the amount of blocks, and see if you can trim it even further, or unify similar ones.
From Blocks to Templates
When you have all of the blocks listed in column D, you can start assessing the amount of templates needed, as well as which pages can share templates.
We have some clear similarities here between a few of the pages. “About Us” and “Careers” have the same blocks listed, so it’s reasonable that they could share the same template. “Our History” has almost the same blocks, with the addition of a testimonial block. We could consider building the testimonial block into every page and making it be optional, which wouldn’t require us to build another template. Or, if we know it will only ever be on this page, we could modify the template for this page only. This would be a great place to consult your developer on what they would prefer.
At this point, you can get a concrete count of exactly how many unique templates you will need, development knows exactly what tools they will need to build, and we have a solid roadmap with which to guide the rest of the creative process.
Speaking of development, if you haven’t already, now is a good time to sit down with your developer and go through all of the work so far. Solicit feedback, answer questions. You’re in this together, even if the bulk of their work hasn’t started yet.
From Templates to Wireframes
Here’s the tricky part. We’ve started building a comprehensive system, which is exciting. But sharing blocks with the same stylings across so many pages can feel restricting on a large site, and it requires a lot of careful design consideration from the start. For wireframes, this mostly affects the structure of the blocks and how they work relative to their surrounding components. In comps, you have to make sure the colors and typography can work visually on any page. That’s a tall order if you’re used to designing on a page by page basis.
You quickly learn that the more common blocks need to be designed very simply, and the more unique or page-specific ones can be more adventurous. You don’t want a situation where the design system fails because you weren’t thinking broadly enough.
But, of course, there will be occasional design exceptions. For example, say the Contact block is full width on every page, except for the Home page, in which it is only half width. Maybe it’s a higher priority on the homepage, so our only option is to put it in a half width space. If the design requires that, it’s important to assess how valuable that really is to the end user, and if it’s worth development writing an exception for it. If it is, make sure to make a note of it in your master block list.
Testing Your System
The block list doesn’t end with the wireframes: this is a core tenant of your project through launch. Both the visual designer and the development team should be basing their work off of this. Not all of your initial assumptions will have been right, but that’s what testing, iteration, and QA are for.
It’s certainly not easy to design for this complex scenario, and it’s also not easy to explain to a client why you can’t just change the font size for the contact box on just this one page. Part of being a good strategist is being able to sell it, and to show the long term value of sustainability to the client. And once you’re familiar enough with this process that it saves you time, it certainly wouldn’t hurt if you spend that extra time on some cool flashy stuff.
A Quick Note on Style Guides
It’s important to write a thorough front-end style guide after the site is built to document both the modular system and the visual system. Websites are living organisms; when something new comes up, you want to know that you can handle it with the design and development patterns you’ve established. It’s also important to be able to explain the system to any new designer or developer that begins work on this project, so comprehensive documentation is key. If you’re looking for resources on writing a solid guide, a great place to start is styleguides.io.
By spending a little extra time in strategy enforcing modularity, you’ll be able to spend more time focusing on the big complicated pieces of a project. You’ll avoid maintenance frustrations with messy code or multiple styles for similar elements, and you can assemble future templates faster with less design input. There’s also the unintended benefit of internal team communication: both strategists and developers can become much better at their respective jobs when they learn from one another. The end result is a stronger site and a stronger team.
Have your own systems for modularity in the strategy phase? Hit me up on Twitter and I’d love to learn about them.