Teaching Web Design: The Redline Document


I’ve been teaching web design for the last 8 years at Bradley University. In the course, I focus on web standards and the design process with my students. I’d like to share an idea I had some time ago and have been using for the last several semesters with some pretty good success. This concept is called, “The Redline Document”. I’ll explain it in just a moment, but first a little background.

In producing a website design, there are replicable steps you should take in order to ensure success, this is a “Process”, if you will. This process should be sharable, transferrable to others on your team and easy to implement. Eventually, the steps should become like second nature to you and your team members. Hopefully, at some point, anyone on your team will be able to step in and take over at virtually any step in the process. It’s crucial for any company that produces creative and technical solutions to adhere to a process in order to build a business and elevate beyond the status of simply being a “job shop” or “making ends meet”. At the Iona Group, we use such a process called “The 4D Process”. You can learn more about it here.

I teach an abbreviated form of the process we use at The Iona Group to my students in my course at Bradley. This simplified process is easy to grasp after a couple quick projects and works great for students, as it allows for a lot of input over the course of the effort. This works for academic settings where the instructor or peers need to offer critique at key project milestones, but it also transfers well to the professional world where you may distributing the workload and looking for stakeholder approvals. In client work, I strongly believe it is best to engage the clients early and often in decisions that affect the project. Each successive step in the process should be a minor reveal, not a massive “AHA!”, IMHO.

Some example design phase deliverables in a web design project would be as follows (I’m skipping past the strategy and definition dleiverables in this post, maybe we’ll cover those some other time):

  • Sketch
  • Wireframe
  • Moodboard
  • Mockup

Those would be documents you could share with your client and get feedback, critique, suggestions, and other stakeholder input. There is one deliverable missing from that list that I have coined “The Redline“. The Redline is not a document shared with the client, but rather a document used internally to ensure the designer, developers, copywriters and SEO experts are all on the same page when it comes to hierarchy, standards implementation and the details of templating the website. This document also serves a valuable purpose to junior level team members in how to structure their efforts. It’s basically a webpage equivalent to an engineer’s CAD drawing of an engine or other mechanical part. In our class we create the Redline document after the mockup phase, but it’s easy to see that there could be a lot of value in creating a Redline as part of the wireframing process. This document works well in a web design class setting to help teach students about page structure, semantics and design hierarchy.

This document also reinforces an oft quoted Zeldman-ism:

Content precedes design. Design in the absence of content is not design, it’s decoration.

I have produced these documents in the past using a printout and a fine-point red Sharpie marker, but the example here was made using Omnigraffle Pro. So, let’s see an example of “The Redline” (click the image for a larger view):

Essentially every element on the page is bounded by a red box, and in each box, the HTML tag that will be used in the creation of the page’s structure is clearly listed. Yes, I realize this should be elementary for an advanced web designer; and yes, once you become adequately skilled you may not need this document. However, for a junior level developer, or for a distributed team that relies heavily on standards based SEO and proper marked up pages, this document has a high amount of value. What benefits does it bring to such a team? Consider these:

  • Prevents HTML “Writer’s Block” – There is no question that junior web designers struggle at where to start once they open a text editor. How will the nav bar be structured? How about that sidebar? What constitutes an H2, an H3, etc?
  • Puts Proper Emphasis On Page Structure – One of the very best ways to SEO optimize is to start out with good bones. By looking at how your content is placed in the page you can make sure that tag weight won’t interfere with proper indexing or page accessibility. Sure, it’s great to have a website with a pretty face, but without good bones, you’re never going to have a design that truly performs. The Redline forces you to think critically about how your page content and structure live together.
  • Separates Design Strategy from Design Production – Let’s face it. Thinking is expensive. You may only have a couple of high end designers capable of producing scalable, SEO friendly standards based designs. You probably have a much larger base of coders capable of writing HTML with some guidance. This allows the team to divide and conquer, with individuals adding value where they can really shine.
  • Eliminates Divitis Before It Begins – Unfocused HTML writing results in poorly formed markup. No question about it. Writing without a plan is a recipe for disaster. This document is that plan.
  • Documents the Design for Historical Purposes/Recordkeeping – As a website ages, the pages get edited, content maintenance systems get patched, templates are tweaked, etc. a website can get rickety. The redline document allows a team member to perform a development/design soft reset down the road. If you want to rollback the site later to the SEO optimized version that everyone agreed on, unless you have pristine document history or version control systems in place you may have difficulty reinstating the original template. The redline will at least allow you to recreate it with minimal fuss.
  • Reduces Coding Time – No question about it, it’s easier to “restructure your page” semantically via diagrams than it is to rewrite HTML time and time again. Just like wireframes help short-circuit the “Photoshop Mockup Death Spiral”, this document helps accelerate the development phase.
  • Establishes and Document Naming Convention for Classes and Elements Ahead of Time – When adding the ids and classes to the document, you are in essence documenting the framework for the CSS and the JavaScript to be integrated with the designs. This really will make sure a distributed team is all on the same page (pun intended).
  • Empowers the Design Team To Help Developers Adhere to Standards – I’m not naming names, but I have come into a number of situations where backend developers have been entrusted to write the markup for the web designs they have been provided. These developers mean well, and can write great SQL and business logic, but page templating isn’t there thing. As anyone knows, a poorly structured DOM is going to produce invalid HTML pages. Invalid HTML documents are NOT going to be cross browser compatible.

So, there you go. I hope this info helps you either learn web design for the first time, or maybe even enhance the process you are using at work to help maximize productivity and increase your overall web design quality. Are you using a similar document in your process? I’d like to hear about how you are implementing planning documents like this to jumpstart your designs.

Posted on


4 comments

  1. Powerserve May 15

    We also use the 4D process, but since we’ve used it for so long it’s second nature, so we don’t document the process step by step any longer.

    Our designers are also our developers, a.k.a. he who designs it builds it. So as we design sites, we’re already planning out how to build the site out. This allows us to quickly convert from designing to building without explaining site functionality or features to another person. Plus our designers also manage their other projects, so it allows all of us to move as fast as our clients can keep up.

    Granted, I think we’re more of the exception than the rule, but being able to wear multiple hats allows us to keep on our toes and stay productive.

    Thanks for the excellent post!

  2. gulfesolutions Jun 14

    Thats very nice keep the good work up……..

  3. Peter Jul 2

    In the design proces we skip the mockup and often also the wireframe, most clients who had no experince with building a website were always saying wrong things when we used this technique. Now we design the homepage and we discus this with the client.

  4. Richard Dec 6

    Hello, Chad.. just fond your article and find it very interesting. I’ve been teaching web design for 15 years and take my students thought the whole build process. I like the idea of getting them to think through the structure. WHilst we teach semantics etc a lot of this goes out of the window as they develop their first project.
    We are also looking for cross university projects to bring together back-end, front-end, designers, marketers etc from around the University to work on ‘real’ projects. We will have to look at the 4D process. We currently use Kelly Goto’s book which serves well along with the process outlined by Usability.gov.

    Keep up the good work. Richard

Leave a reply