Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Content First — Design Last

How does one design and develop for the responsive web? A lot of methodologies out there try to tackle this problem, but all of them rely on the same classic website development process. It boils down to the following: design and then develop. Let’s go nuts and flip this outdated methodology on its head.

Before we start flipping things around, let’s take a quick stroll down memory lane, just so we know where we’ve come from and where we are now.

Further Reading on SmashingMag:

History Link

It’s 1989, and Tim Berners-Lee, the man with the plan, conjures up HTML while working at CERN. It’s a language to link content across documents.

After four years, the web went public, in 1993. It took a couple of years for someone to create the first columned layout using a table — at which point, something changed. I imagine this as being a turning point in web development. It was the moment when design could be moved to the front of the development process. You could now design a web page, slice it up and present it on the web.

Luckily, we regained our sanity and ditched tables for layout. We proudly moved to semantic HTML, but we held on to our design-first approach. Let’s take a closer look at semantic HTML.

Semantic HTML Link

Semantic HTML is about picking the right HTML element to describe a given piece of information, rather than using HTML to define the way the information should look. If you’re a front-end developer, you’ve probably been doing this for the past couple of years. Great, keep it up!

In my opinion, writing semantic HTML is one of the key aspects of being a good front-end developer. It’s something I value greatly.

Because of that, it’s been a topic I’ve discussed a lot with colleagues who have valued it less or simply did not understand. To resolve these debates once and for all, I tried to give them a glimpse of the thought process behind my HTML writing.

I searched for a straightforward website online and derived its HTML structure (without looking at the existing HTML, which would have been cheating). Then, I turned my HTML thought process into a step-by-step visualization. For many of my colleagues, this visualization turned out to be a real eye-opener. These couple of visuals created mutual understanding of what a front-end developer does and why semantic HTML is important. Also, interestingly, it revealed that not all front-end developers view semantic HTML in the same light.

Below is the website I used in the thought process experiment.


I’ve laid out the thought process below. On the left side is my view of the website. On the right is the written HTML as rendered in the browser. OK, let’s do this!

  1. In my opinion, this landing page serves as an umbrella for all subpages. So, I’ll wrap the logo in an h1. I’ll add an img tag as well, so that the logo displays when printed.
  2. All right, next up is the menu. I’m putting it at the top because this is a landing page. Also, let’s handle caps with CSS text-transform. I’ll wrap the menu in a nav and add a mandatory header called “Navigation” inside. Also, we’ll add an ordinary unordered list, with anchors as links to the other pages.
  3. Is this image showing a train actually content? And should we, therefore, use an img tag? Or is it aesthetic, meaning we should handle it in CSS using background-image? I’m going with aesthetic, which means it won’t end up in the HTML outline.
  4. What type of content is that white text below the image? What should I name it? How about “Introduction” — I’m not 100% sure, though. I’ll add an “Introduction” heading and hide it with CSS later on. This heading might be useful for screenreaders as well.
  5. Wait a minute! That blue “Join us today” button is related to the introductory paragraph (“… if you joined us”). Also, it’s not a button but a link. I’m setting myself up for a CSS positioning nightmare.
  6. At this point, I don’t know what to do with the “Book an event” button. It’s not related to “Join us today,” that’s for sure. It’s a button without context. I’ll just skip it for now.
  7. Finally, some straightforward content: headings, paragraphs and links. To position them, we might need to wrap some of these in a div later on.
  8. On to the events! Let’s go for an ordered list because shuffling the dates would be confusing. We’ll use the time element for dates and times. Let’s wrap a link around the subheading.
  9. Now we know where the “Book an event” button should go. People need to know about upcoming events before they can book one — makes sense. So, we’ll put the button with the events making our CSS positioning nightmare even worse.

Below is the resulting HTML.

<h1><img src=""/>Greater Dunnellon Historical Society</h1>



      <li><a href="/">Home</a></li>




   <p>We’ve come together … if you joined us.</p>

   <a href="/">Join us today</a>

   <h2>A commitment to our history</h2>

   <p>The Greater Dunnellon … in its heyday.</p>

   <h3>Learn about Dunnelon's history</h3>

   <p>Dunnellon was platted … South Williams Street.</p>

   <a href="/">More history</a>

   <h3>Your next event at the depot</h3>

   <p>The depot provides … are also available.</p>

   <a href="/">Make a reservation</a>


      <h2>Upcoming events</h2>



            <h3><a href="/">Museum open Tuesdays</a></h3>

            <time>01/21/2015 from 11:00 am</time> to <time>4:00 pm</time>

            <p>Learn, teach and share history with Boomtown Sam!</p>




      <a href="/">Book an event</a>



A lot of attributes have been left out to keep the HTML compact.

You probably noticed that I’ve made a lot of assumptions in order to come up with the HTML structure above. The introductory paragraph heading, the banner image and the call-to-action buttons — these were all places where I assumed something and added to or altered information on the page.

I’ve also made assumptions about where to position things on the page. In deriving semantic meaning from textual data, I’ve assumed that the visual designer intended to give information on the right side a lower priority than information on the left. Based of these assumptions, “Upcoming events” ended up below “A commitment to our history.” I put the navigation above “Introduction,” although it might have been better the other way around.

Assumptions are dangerous, not only because one could assume incorrectly, but also because somebody else will most likely assume differently. In this case, if you and I had independently written an HTML tree based on the design above, it would have been a miracle if they turned out the same.

HTML is about giving meaning to information. We should not end up with different descriptions of the same information. It seems that design clouds the meaning of the content and creates room for interpretation and assumption.

Content First Link

A content-first5 approach teaches us that visual design should always be based on actual content. Only with real content can we decide how best to present it to users. We’ll get to what “real” means in a minute.

With a content-first approach, we move from designing without content to designing based on content — a very important distinction. Remember the definition of semantic HTML: giving meaning to content.


Semantic HTML has no relation to appearance — that’s what CSS is for. Why put off the HTML until after the design phase if it doesn’t depend on the appearance? Let’s move it to the front and describe our content before designing it.


It’s a small change, but it makes a big difference. With this change, all assumption is taken out of the equation. We now know how our content will be structured. And before even drawing a pixel, we’ve got ourselves a website.

Do you hear that? That’s the sound of screenreader users celebrating.

Flipping It Link

Let’s go back to the slides. This time, we’ll do it the other way around. We’ll use the HTML that we’ve just written and imagine a designer using it for their visual design.

(View large version7)

It’s difficult to imagine the call-to-action buttons ending up where they were in the original design. In terms of visuals but also content, this new setup makes a lot more sense.

When we were basing the HTML on the initial visual design, we could use the visuals for one viewport only. By turning things around and basing the design on the HTML, we can use the HTML for all possible viewports and contexts.

Reality Calling Link

If I’ve piqued your interest, you might be wondering how to implement this approach in an actual project. Depending on the project, your team and your client, it might look something like the following.

Because we’re doing things content-first, we need to get our hands on the client’s content. Mark Boulton8 rightly points out that content-first is not about waiting for the final content before doing anything. When we talk about content-first, we mean that we want to know the structure of the content that we’re designing for. Having the final content already in hand would be fantastic, but most of the time it simply is not. In “Structure First. Content Always9,” Boulton says:

You can create good experiences without knowing the content. What you can’t do is create good experiences without knowing your content structure.

In my experience, this is true, and making sure everyone knows what “content first” means is important. So, make sure everyone understands that you’re talking about structure and that you don’t mean to pause the project and wait for the client to deliver the final content.

Before we start writing HTML, we need to determine what content to present on the page and how to prioritize it. This is where a priority guide comes in handy. Together with your client, write down all of the content types of your web pages on sticky notes, and then order them chronologically along the y-axis. For example, you could have a “product detail” sticky and a “post a review” sticky, and because someone would need to know about a product before reviewing it, “product detail” should come first. Your client might deem the “post a review” box to be more important, but that importance could be visualized later using color and composition, not by changing the order of content.

I find that clients are pretty good at this exercise, maybe because they are used to writing documents such as quotes and writing papers that must adhere to a certain hierarchy and chronological order to make sense. As I said, this exercise makes them really think about what’s important. Also, if there are multiple stakeholders, it shows how each is motivated and which stakeholders have the most influence.

We’ve set up our content types; let’s talk about content structure. Structuring content is exactly what HTML is good for. Let’s go for it. We’ve got our content types, and we understand semantic HTML, so let’s start adding structure to the various content types. This could be easy or challenging, depending on how high-level your content types are.

A basic “post a review” form could be pretty straightforward:




      <label><input type="radio"/> 1</label>

      <label><input type="radio"/> 2</label>

      <label><input type="radio"/> 3</label>

      <label><input type="radio"/> 4</label>

      <label><input type="radio"/> 5</label>




   <button type="submit">Send</button>


A lot of attributes have been left out to keep the HTML compact.

The “product detail” sticky might be a bit more challenging. In its most minimal form, it could be just a “title,” “image” and “short paragraph.” But your client might also want things in there like “product specifications,” “ordering options,” “related products,” etc. These other content types require further discussion and prioritization. In the end, you might conclude that “post a review” is actually a part of “product detail” because people will be posting a review of the product described in “product detail.”


   <h1>MacBook Pro</h1>

   <img src="macbook-pro.jpg"/>

   <p>A groundbreaking Retina display. All-flash architecture. Fourth-generation Intel processors. Remarkably thin and light 13‑inch and 15‑inch designs. Together, these features take the notebook to a place it’s never been. And they’ll do the same for everything you create with it.</p>

      <h1>Post a Review</h1>

       <!-- 'post review' module here -->



A lot of attributes have been left out to keep the HTML compact.

These content types don’t stand on their own. They should be contained in an overall content hierarchy, as we saw in the series of images related to semantic HTML earlier. Together with this hierarchy, your content types should create a nice and correct HTML5 sectioning outline10. To test this, you can copy your HTML to the HTML5 Outliner11.

Below is an example of an initial web page setup.


Now, we could have also done a bit of content choreography12 to make sure each bit of content receives the right amount of attention from the user. In his excellent book Responsive Design Workflow13, Stephan Hay14 advises us to set up content reference wireframes at this point. In my opinion this would be a bit too early — it’s best to wait a bit longer on the composition, because color, typography and functionality will affect the way attention is distributed across the page.

Let’s continue with our basic HTML web page. Don’t show it to your client yet; mix in their brand identity first. Add their logo, and convert their typography rules and color schemes to CSS. This will make it easier for your client to identify with the content — the content will look less anonymous and more like their own.


While your client would be able to relate to the version shown above, they would probably have a hard time getting enthusiastic about it. In my experience, the client will be impressed with the amount of work done but will feel uncomfortable not knowing what the result will look like. I recently renovated my house, and I have to admit, after totally stripping it, taking down walls and removing old plumbing and electricity, I seriously doubted whether it would come together in the end. That’s when I understood how my clients feel.

You need to manage that feeling or else they’ll panic and fall back to the classic web development pattern, demanding design up front.

The version above is the “minimum viable web page.” It contains, if all has gone according to plan, the core content that your client’s users will be coming to the web page for.

If you’ve been using actual content, then even if all hell breaks loose, you could put this online as is. It wouldn’t be perfect, but the brand would be recognizable, and users would be able to access the information.

For now, hell is not breaking loose. So let’s move to the content choreography. Start resizing the browser window and view the page on some different devices. You’ll notice that on a wider viewport the line lengths will become uncomfortable to read. An ideal line contains between 45 and 75 characters15. So, you can regard points where it’s longer or shorter than that as indicators to tweak the layout or font size.

You have two options here: either make the adjustments live in the browser or boot up your favorite design tool. In my experience, designing in the browser is useful for tweaking things such as font size and color, while composition experiments are easier to do in Sketch or Photoshop or using pen and paper.

Tweaking CSS values in the browser might be tempting, but taking a screenshot and making some quick adjustments outside of the browser is usually faster. I find this results in more interesting design choices. When sketching, try to imagine how your solution would scale or break in smaller and bigger viewports and how your design choices relate to the content’s order and importance.

When you’re happy with the sketches, transform the result to CSS.


Now that we have set up the base version of the web page, we can start testing and iterating. Do some quick usability tests, which you can easily do by following the Don’t Make Me Think16 methodology. Sometimes creating a small prototype for this is easier than using the production version.

While tweaking the web page for each context, we can look into adding functionality and presentation styles based on contextual measurements17. For instance, in small viewports, we could move the menu out of view. Or when the user is viewing the web page late at night in a dimly lit environment18, we could load a style sheet with inverted colors. If enough real estate is available, we could turn an address into a Google Map.


If you look closely, you’ll notice that all of these enhancements are layered on top of the content. They only change the way the content is presented and interacted with; they never change the content (or priority of content) itself. This fits perfectly with a strategy of progressive enhancement: Start with the content, and work from there.

We’ll finish up this section with a short note about web applications. The methodology explained above is for content-driven web pages — pages that are and should be accessible to everyone in all contexts. Not all web applications fit this description. Many use HTML to describe the interface instead of the content. In these cases, this methodology might not be the best fit.

Advantages Over Design-First Approach Link

I’ve compiled a list of the challenges overcome and the advantages gained by this approach. Not to say that this approach does not introduce new challenges, but those new challenges mostly have to do with managing client expectations and team communication.

To the list!

  • Content — and, therefore, HTML — is the only constant across all devices. How you present your content and how users interact with it will differ between devices, but the content will remain the same. Starting with content means starting with everyone.
  • Describing content with HTML is not only about lists, paragraphs and headings. It’s also about choosing between buttons and links, dropdown and radio buttons, tables and definition lists. It’s about outlining all functionality with HTML first.
  • With the content nailed down, there’s less confusion about what things actually are. Something could look like a button in a visual design but in reality be a hyperlink. This creates miscommunication in a team, which is easily prevented by writing HTML first.
  • Because we’ve layered design on top of HTML, we have created an opportunity for the team to work together. Developers can work on implementing the HTML, while designers can think of compositions for various viewports and contexts. No more deliverable dependencies means no more tiny secret waterfalls.
  • This methodology enables designers to work concurrently with their developer buddies, allowing them to quickly test things in the browser. Some design problems might be easier to tackle in CSS. As Paul Boag explains19: “Developers might suggest ideas that you might have dismissed as impossible.”
  • It’s now clear what content should be generated or be manageable via the CMS. Hidden skip links, headers and labels are no longer hidden — all content is right there in plain sight. Design choices can now make content implicit, but that does not mean the content won’t end up in the HTML, because we’ve already written it. In my experience, none of these implicit content items end up in the CMS because they aren’t visible to everyone. By starting with HTML, this is easily resolved.
  • If you and the client have pinned down what content you want to communicate to users, that will very likely not change during the development process. A change would only happen if user research uncovers some previously unknown facts that warrant a change in course.
  • Content creates focus. By focusing on content and functionality early on in the process, you’re less likely to end up in a “red or blue?” discussion with the client. Too often clients are tempted to focus on details when they should be thinking of the big picture. With this layered setup, the focus starts with the big picture and then moves to the details during the project.
  • Having the HTML early on enables you to build the minimum viable product first. In later stages of the project, you can progressively enhance it to further improve the user experience. If you introduce usability testing in the project (which you should), you can use the results to decide what to enhance first. An asynchronous search filtering system might be cool, but your users might value other functionality more. Harry Roberts reminds us20 that “good enough” today is better than “perfect” tomorrow.
  • As we saw with the call-to-action buttons in the semantic HTML exercise, spotting user experience problems is easier when you’re working with content as the foundation.
  • Once you’ve finished the HTML, you can immediately start testing the content with visually impaired users. Most of the additional layering will be for the sighted.
  • Starting with content enables you to more easily define your HTML5 sectioning outline, to pick micro-formats21 or micro-data22 and to apply WAI-ARIA rules23. This results in better accessibility and makes the pages easier to index by search bots.
  • This approach entails going from a robust stable base to a very detailed flexible end product. By staying away from highly detailed solutions early on, you decrease the risk of putting a lot of hours into unneeded functionality. For example, you could build synchronous search first, and then later on in the project, if your user base turns out to heavily favor search, you could layer asynchronous search and filtering on top of it.
  • A correctly written HTML tree provides natural hooks for JavaScript later on. Content under headings could be made visible in large viewports and then presented in an accordion in smaller ones.
  • No longer are you creating pretty pictures of web pages. The focus has moved to quick sketches and tiny prototypes to solve design challenges, and the results are quickly transformed in CSS and moved to the browser. We’re throwing away fewer deliverables, which means we’re working more efficiently.

Talk To Your Client Link

As with everything, it’s all about communication.

If your client thinks the Web is a 1024 × 768-pixel box — and continues thinking this while you and your team are working on their shiny new website — then you’re going to run into a lot of trouble.

Many clients expect a visual design up front, because that’s what they’re used to getting. They don’t know any better.

Your job — not an easy one — is to explain to them why this is impossible. Enlighten them about the millions of different viewports, interaction methods and feature sets out there, and help them understand that you cannot capture all of that in a static design.

If your client understands the Web, you’ve won half the battle.

(vf, il, al, ml)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23

↑ Back to top Tweet itShare on Facebook

Rik is a Freelance Front-end Engineer living on this 2D plane people call The Netherlands. He tweets and writes about things he finds on the web and things he finds of it. Loves experimenting with HTML, CSS and JavaScript and does some game development on the side.

  1. 1

    In my opinion, writing semantic HTML is one of the key aspects of being a good front-end developer. It’s something I value greatly.

    This! <3

  2. 2

    Christopher Smith

    February 20, 2015 4:07 pm

    None of the links in this article work (and the navigation menu) if you have JavaScript turned off.

    Seems to me that this is a big deal breaker to cause a link tag to not function correctly without JavaScript.

    • 3

      Sorry for the inconvenience Christopher.

      We just pushed an update to the Live-System of the Magazine and during a short transitionphase there were some Javascript hiccups.

      This issue should be solved by now.

    • 4

      Might be a good time to get rid if no script. It’s 2015 not 2005 after all.

      • 5

        We are loading our main stylesheet with Javascript into the head-section after the critical contents are displayed/rendered in order to save on the perceived loading time. We keep this <noscript> element to provide those users who disabled Javascript in their browser with the stylesheet.

  3. 6

    I’ll admit, I didn’t read the entire article, it’s too long. Just because you’re laying out some semantic HTML doesn’t mean you’ve moved the design phase. That is design work. Development is actually writing code. Writing HTML isn’t programming, it is very much a design process.

    Looking at your content and laying it out in semantic HTML, in my opinion, is design work. Whether it’s actually done by a designer or front-end developer is irrelevant.

    The point of starting with content first is right on. Start with the user. Design your application with the user and the content in your mind from the very beginning, once you figure that out, bring the software engineers to make it go. I can’t count the number of times when that process was flipped, where programmers start blasting out code and then a designer is brought in at the end to make it pretty.

    So I’d be very cautious about giving that thought process validity, what you’re talking is still design first then development. It is in some ways an argument of semantics, but it’s one worth having.

    • 7

      “I’ll admit, I didn’t read the entire article, it’s too long”

      This is quite clear after I took the time to read your comment Keith.

      Later on in the article Rik talks about how this approach affects feature development, how it can also aid the responsive design/development process, and how it helps with things like progressive enhancement too.

      • 8

        The headline is “Design Last.” I just disagree that that is what he’s suggesting.

      • 9

        And what does progressive enhancement have to do with what I’m saying? It’s like you’re writing your comment in SEO fashion.

    • 10

      Well said!

    • 11

      “I can’t count the number of times when that process was flipped, where programmers start blasting out code and then a designer is brought in at the end to make it pretty.”

      This is not what I aim to accomplish, and I think if you would have read the entire article (which is pretty long indeed) you would find I am not advocating developers running amok. It’s a team effort.

      • 12

        I didn’t say that you are suggesting that, I’m saying that what you’re saying is different actually isn’t different. I don’t think what you’re suggesting is as new and unique as you think it is. I don’t think what you’ve presented here is actually “Design Last.”

  4. 14

    First, we should understand what is the meaning of semantics in HTML.

    – “Remember the definition of semantic HTML: giving meaning to content.” It is true but we must understand one thing that semantic is from the point of view of document. The principle abstraction is of document. The document has content and now we can give meaning to the content from this perspective. It is the document that has paragraphs and headings. There would be main content and also there would be some content that is related to it but is not a part of the content. Although HTML5 is catering for web applications as well butI would ignore this aspect to simplify the discussion. If we stop thinking in terms of document, then information perhaps could be described better using XML. And precisely because of this, microformats are used to give semantics to the content. Now, the problem is agents cannot understand microformats without really understanding tokens used in it. For example,


    Now, an agent cannot understand it unless it knows about geo, latitude and longitude.

    • 15

      SmashingMagazine is not displaying my example in correct format. I would simplify it.

      class=”geo” > class=”latitude” 54.3 > class=”longitude” 26.7

    • 16

      I think micro formats are an excellent way to enrich your content structure even more.

  5. 17

    This is a fantastic article, and as a FE Dev I found myself nodding in agreement. However, having worked in many different organisations, I think this is a bit of a holy grail, as I suspect the change in methodology would be met with much resistance and suffer from internal politics. I also wonder how it would affect the amount of time taken to deliver a project too, over the more traditional, design first approach as mentioned in the article?

    I’d be interested to know what people’s thoughts on those two points are.

    • 18

      This is exactly what I was thinking when I read this article. The last project I worked on ( internal dev dept – not a design shop ) a month into the project expected a polished, finished product suitable for deployment. It seems this is happening more often as marketer types move into management roles without any tech knowledge at all. It’s so common anymore to hear, “The boss expects this yesterday so why isn’t it done?” ( as I just heard yesterday, no lie )

      I applaud the effort to promote excellent, analytical processes. I just don’t see them holding water within most organizations where mareketing and money rule the order of the day.

    • 19


      The way we consume the web has changed a lot, and in my opinion we’ve not really changed the way we build it. A drastic change might be necessary to cope with new requirements and the web as it is today.

      I never said it was going to be easy ;-)

  6. 20

    This is exactly why I create the first version of my html in MarkDown.

  7. 21

    Oh dear. So many points to make.

    1. The conclusion of this article isn’t actually “design comes last” if you read it. (In fact, I’m not sure what “design” even means in this context, but I’ll come to that), making the title rather misleading (in an attempt at more clicks, no doubt). It’s mostly saying that it’s useful to use HTML as a way of guiding/building the structure of content as part of the early design process. I completely agree.

    2. However, past this point the article retreads the familiar territory of “upping the design fidelity” of a site as the build progresses, and testing as you go along. In my opinion, it’s not possible to properly test an experience which hasn’t used all the tools available to form it. Button wasn’t seen? That’s because colour wasn’t in the equation yet. Content not clear? That’s because the typography hadn’t been set properly yet. What if you enshrine elements of the build by testing, and the introduction of higher fidelity elements makes a nonsense of it? eg. “It was effective in that position when we tested the Low Fid build, therefore the “aesthetic” design shouldn’t move it.”

    As is often the case, it’s assumed that elements of a page can be tested and enhanced in isolation, without affecting comprehension of the rest of the page. This isn’t the case. Changing any element on a page affects the others. Complex web design can never be completely modular.

    3. Going back to a point above, the article appears to be based on a misunderstanding (or misrepresentation) of what “design” actually is. It’s not the layer of aesthetics and graphic design that you bung over the top of an established framework. It’s also not a completely made-up layout based purely on a designer’s personal preferences (although granted, this sometimes happens.) For me, design is a multidisciplinary undertaking which starts with understanding the content and goals of the site (which the HTML process suggested could certainly be part of), continues with adding in the graphic design elements (which ARE aesthetic, but as we all know have a large overlap into what is functional), and ends with a cooperative process between UX, designers and coders (if these happen to be separate people) getting the build right. There are very large areas of overlap between these elements, and the roles are blurred.

    4. A more minor point, but the suggestion that there’s a clear line between “content” imagery and “aesthetic” imagery is clearly nonsense (as I’m sure another Smashing contributor, James Chudley, would agree).

    • 22

      Well said. Steve Jobs said it best, “Most people make the mistake of thinking design is what it looks like. People think it’s this veneer—that the designers are handed this box and told, ‘Make it look good!’ That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.”

      • 23

        That’s industrial design though. The equivalent would be an industrial designer making the first iPad as 3mm and having a one month battery life, then handing it to the engineers and saying “here I promised this to Mr. Jobs, make it happen”.

    • 24

      1. Great! While I was not really going for clicks, I did hope to provoke some response with that title. :)

      2. Color and typography are one of the first things you’ll need to put in there, they’ll probably won’t be final but they give you a starting point to test you’re content and assumptions. The step by step guide where I illustrate the various build steps describe anything but a modular approach, it’s a layered approach and your design/presentation is refined each step of the way.

      3. I think this is a semantic discussion. There’s also Software Design but that’s not what I was talking about either. ;) This might be comparable to the Content First approach where we’re not really talking bout the actual content but the structure of it.

      4. There often is a clear line. The ‘paper’ like background of the panel on the right clearly is aesthetics. But when the line is not clear things get difficult, which in my example is the case. I do not know if the train image is a decorative element or should be part of the content. Of course, working as a team that would be discussed, my point is that by starting with HTML the ambiguity would be removed all together.

      Thanks for your in depth comment!

  8. 25

    Great read! At my first design agency, the concept of building a fully functional site without having themed it yet was a foreign one I had to sell hard. At the time, I called it “live wireframing”. Fortunately, the advent of the CMS made this transition easier because you could start creating data models (articles, bios, etc.) before figuring out exactly how each page would lay out—giving client access to the CMS to keep them productively engaged before the eye candy. We could then work on functionality in sprints, cutting down feature build-out time by not worrying about theme just yet.

    Today, this direction is more of the norm, particularly as atomic design takes hold. As an industry, we’re much more quick to prototype and use that as a means to determine design, than to allow design to kneecap content and UX strategy. Design should still happen early, but the mistake made by designers is to assume design has to be a “page.” It’s great to see our creative teams migrating toward style tiles (e.g.) and circling back on page comps once there is an actual prototyped page to comp—and user needs to satisfy with design as a tool rather than an embellishment.

    • 26

      Anthony, the fact that you’ve used the term “themed” (a website), and talk about design “kneecapping” other processes and being “eyecandy” tells me a lot about your attitude to design (or what I’d call UI graphic design to avoid confusion). I’d be interested to know exactly what you think a designer is, and what their role should be.

    • 27

      Great to read you’ve already got a similar approach implemented in your workflow!

      My goal is to bring the team together and have everyone feel responsible for the end result because they’re not just building they’re contributing ideas. Implementing this methodology in a multi disciplinary team I’ve had very positive reactions from designers. They love they’ve got real content to work with and that the overal structure of the content is crystal clear. I am pro page design though, as each unique page is there for a reason it should be able to present it’s content in the best possible way. By splitting everything up in modules and designing them individually the overall relationship between modules on the website can be lost.

  9. 28

    1. Content creation always should come first.
    2. Design should always come second and should be driven by content.
    3. Development should ALWAYS come third and structure should be based on design and content.

    • 29

      Let’s agree to disagree.

      • 30

        Too often I see poorly written web pages that are semantically great and designed great. The content is horrible. There are thousands of blogs like that. Fortunately, this site is not one of those. This site has great content and poor design.

        • 31

          “structure should be based on design”

          God, no. That thinking led to semantically broken and meaningless divitis. We’ve left that behind, I hope.

  10. 32

    Juan D. Bolaños

    February 21, 2015 12:12 am

    I totally agree with a content first approach, but it’s easier to preach than it is to implement to your Sr. acount and content manager. But to my main question: Where does the UX come into play? I understand focusing on design towards later time and I agree but creating a strong UX before design is always crucial but does that supersede HTML before design or in your opinion HTML trump UX as well. It’s hard to just move 1 piece forward or backword with out thinking of the process as a whole.

    • 33

      I think UX is there all the way.

      Colors impact UX. Content impacts UX. Composition impacts UX. HTML impacts UX. Devices impact UX. It doesn’t end.

      It’s part of the process. You notice your page menu is taking up too much space on smaller screens? Implement a common solution directly or if you want to go for something original build a couple of prototypes and test the resulting user experience.

      All sorts of tests are part of the agile process UX tests should be as well.

  11. 34


    February 21, 2015 12:48 am

    « a mandatory h2 called “Navigation” » not « h1 »

  12. 36

    This is a great article. And thank you so much for mentioning screen readers! However, I have some code comments/suggestions that come along with that.

    The use of labels on the radio buttons is great.

    Could you also programmatically associate the “Review” label with the textarea below it? It should be fine to do it implicitly as you did with the radio buttons, but here is a way to do it explicitly, which I think is more clear.



    Also, could you include ARIA Landmark roles? Here are some resources…in case you haven’t used them before.

    • 37

      Hi Luis! Glad you liked it!

      I’ve left out all the attributes on purpose as that would make the HTML way too complex to quickly scan through. Maybe a small note on this might be in order, I’ll see if I can add that.

  13. 38

    “In my opinion, writing semantic HTML is one of the key aspects of being a good front-end developer. It’s something I value greatly.”

    We should make viral this part of your article..unfortunately not all frontend developers think like this and instead of encouraging clients to follow a more sane process they fallback to outdated practices. Amazing article

    • 39

      With respect, the site is broken on mobile (iphone6).

      Portrait mode/ landscape mode: The top banner does not extend all the way across the screen. Portrait mode: The body has a background artifact.

      The site isn’t responsive (that’s fine), but I also can not zoom out all the way to see the entire page on the home page (portrait mode), but I can on certain other pages. In particular, the home page “Book your event” button is *completely hidden* in portrait mode, unless I happen to manually scroll the page right. Similarly, upcoming events are partially hidden, and therefore unreadable.

      Your sites have to look good on mobile in 2015.

      Consider using a well-tested wordpress template instead.

      • 40

        You missed that the site the article author is using here isn’t one that he himself designed and executed. He wrote above that he chose a straightforward HTML website for a “thought experiment.” It’s not his work, it’s just his example.

        • 41

          Okay, thank you. It’s a long article, and that was not clear (it still is not clear, frankly).

          The author would be more persuasive if he described an actual, live site he developed with these methods. His own personal site is a straightforward blog list (nothing wrong with that, but that could be a standard blog template), and his linked in shows only that site, and his twitter feed, which I assume he is not taking design credit for :-)

          I don’t have time to check more, can you provide an actual site that this person has developed? Why is he an authority?

          thank you.

          • 42

            First, I am no authority. This is my analysis of web development and how I see it. I’ve explained why I see it this way. It is for you to decide if you feel there’s something there you could use in your process. :)

            I’ve been a front-end dev in the web industry for quite some time now, so these views on web development have a strong foundation. I’ve recently started as a Freelancer and before that I worked at Mirabeau we’re we build enterprise level platforms in multi disciplinary teams. Because I am not solely responsible for the sites I’ve worked on it feels wrong to showcase them on my personal website.

            The example site I used nicely reveals some things that could go wrong when setting up HTML based on a visual design. The bigger the site, the more errors come to light. Picking a bigger platform would just have made the article longer.

        • 43

          Hi Lindsay!

          Thanks for clearing up the confusion, I’ve rewritten the text a tiny bit to make it more clear that I am not the author of the site.

  14. 44

    Yes, yes and yes … and maybe ;)

    You mention collaboration between design and dev, so in actual fact, it’s “design during” – which isn’t so catchy ;)

    After two decades of building websites, working with other people who have had the same, your approach is really close to how it pans out for *successful* web builds.

    Even if you approach it the *old* way, design first, without fail (unless the build fails!), it ends up with design compromise at the tail end of a project, wasting days or weeks or even months of time.

    The most successful projects I’ve worked on:

    1. Content discovery
    2. Loose wireframes
    3. Start html/css structure & design
    4. Hand over loose html/css to backend guys so they can hook things on it to get them rolling (altho they will have started ‘bootstrapping’ based on wireframes)
    5. Front-end dev works with designer AND programmers as the project progresses
    6. Success

    In fact, there isn’t really a design first or design last approach, it all runs *together* with constant discussion, amendments, refinements that involve *every* stakeholder.

    • 45

      True, it’s everything together but that would have made the title less memorable. Also it’s a wink to Content-First, Offline-First, API-First, etc. ;-)

      The article itself describes the ‘everything together’ process quite nicely I feel.

    • 46

      This. People tend to gloss over #1 which is what I think happened here.

      I’ve been in situations where this process has gone totally wrong. You get some print “designer” dabbling in web design with no basis of how users actually USE a website so they do what they’re used to. The more I look at it, the more I see that this site looks very printed page / “transcribed” from a psd. Two call to action buttons next to each other? What were they thinking?

      They have upcoming, community events that are open to the public but you can also book the space yourself for an event. Those are 2 separate, discrete things that should have been addressed separately when doing the content strategy and wire framing but I can see how a junior graphic designer with no content strategy might have been led astray.

      As mentioned in the article, it’s easy to make assumptions about the design so we can only speculate. A website is a living, breathing organism but I have to wonder as well if this wasn’t the original design of the site and something dictated by a client? “Can you move the call to action buttons up to the top? We really want emphasize people booking the space!” Or whatever. A lot of times those client changes get dictated in a meeting where the original designer wasn’t even present, which is criminal. In the interest of time, the feedback gets sent back to the “code” team and they make the changes.

      You need someone who not only has a vision for what the site is going to look like and function but have the guts to make some tough conversations to the client and lead your team to greatness. Steve Jobs probably pissed off his team a lot but he had a vision, something I think a lot of people in client services tends to lack. “Yes sir, yes madam, we can make your logo bigger even if it means that deemphasizing the important things on the page…”

  15. 47

    Great article!

  16. 48

    This is probably the most important article I’ve read on Smashing ever. I’ve been trying to push Content-First at work for some time now (for the most time without using the term as such) – without much success. My arguments have not been nearly as precise and elaborate as this article. All points hit the nail on the head – well done.
    So many misnomers could be avoided if everyone just developed Content-First…

  17. 49

    Great article with lots to think about, thank you.

    One question, how come the logo is wrapped in an h1? Wouldn’t it be more suitable inside a header element? My reasoning:

    According to w3 “These elements[h1-h6] represent headings for their sections.”. Is an image really a heading? Isn’t it more of a branding feature and navigational link? Wouldn’t a more fitting heading for the page be “Home”, “Community Events”, “About Us”, etc?

    And “The element represents a group of introductory or navigational aids.” (which IMO perfectly describes the logo + nav as the logo almost always is a link to the home page)

    I’m no expert though so would like to hear your thoughts on the matter.

    • 50

      Charles Deukett

      February 22, 2015 9:44 pm

      I was also wondering about the use of the H1 tag in this example. I would say for a single page website using the logo/company name as the heading would be OK, but what about creating a template for a website with multiple pages. Every page would have the same main heading? would it be more useful to have a pages main article heading as the H1? in the example above something like A commitment to our history. Just been a bit unsure about this in the past. But great article!

    • 51

      Thanks Josh!

      On homepages I usually wrap the logo in an H1, this does not mean content pages also need to have the logo in an H1 (each page can be unique). On content pages I use the page title for that. My reasoning is that the homepage services more as a entry to all content pages related to the brand.

      This is the exact reason why we should start with HTML/content instead of design as you interpreted it differently than I did. :-)

  18. 52

    Is this The Rik’s Guide To The Lorem Ipsum Elimination? It seems so. And quite good at that even!

  19. 53

    Shouldn’t the headings be and not ? The idea behind articles is that they are modular and you should be able to remove them from the current page and pop them anywhere and retain semantic context.

  20. 55

    First of all the content should be created around the keywords and not the keywords from the content. then the designing should be done . And at the end development should take place.

  21. 56

    now that you got semantic markup, how about taking it a bit further with a valid one? (alt attribute on image as an example would be a good start)

  22. 57

    I’m all on board for a collaborative team approach, iterative, and informed. Also content-first is critical because what you want to communicate needs to anchor other decisions.

    As in all things of complexity, there are many facets. So not one single methodology works in all cases, and yet there is always something to be learned by the many methodologies discussed.

    What I see between the lines here is a lack of Visual Innovation and Creativity, as though it simply emerges from this approach. At least, I’m not convinced of it by way of the example.

    Breaking down the Historical Society example is taking a very Visually Innovative and Creative style and showing how to apply semantics as well as how the semantics can influence design. This to me is the stronger approach of the two examples. I don’t see how this design would have emerged by following the methodology of the second example.

    The second example where you’re demonstrating building up from semantics, there is never a view of the final page design. The last image demonstrates nowhere near the visual depth or detail as the first example.

    Where there is no aspirational visual, I don’t see those visualizations emerging from this process. There is a tendency to hunker down and get further steeped into the technology at hand and caters to limiting innovation. Your concluding fifth bullet is spot-on, but I would add context saying “throughout the project” and not strictly as a means of establishing visual direction.

    I don’t suggest that a visual once-created must be pixel-perfectly implemented, however, having a visual which sets the direction gives context for what is to follow. It should continuously be worked on and adjusted as the team learns more throughout the project, and this would include the learnings through semantics. Learning sooner than later will benefit the team.

  23. 58

    Lindsey Stanek

    February 24, 2015 7:00 pm


    This is how I’ve been trying to approach my projects lately, and this is chock-full of great advice!
    Yay semantics! :)

  24. 59

    Liam Fitzgerald

    February 25, 2015 1:24 pm

    Excellent article Rik! I’ve been using this approach for a few months now (glad to know I’m not crazy or alone in this methodology!!!). It’s not always an easy sell to a client but what it does is make the client think about the content from the very start of the project. Too many times I’ve seen clients get dazzled by the eye-candy and waste precious time obsessing over minor presentational details while their site is a collection of “lorem ipsum” content. And quite often when presented with an early design comp clients just see all of the placeholder content spaces as just boxes that need to be filled, a mere afterthought.

  25. 60

    Christopher Mollard

    February 25, 2015 7:22 pm

    I agree that the content of a site should shape it’s design, however I don’t believe that design comes last in the process. From a front-end developers point of view I think building a site using the process you described makes perfect sense, however you need to have a vision for what the site will look like and so design is still at the beginning. The actually process is constantly iterative and allows for a review based on all three elements: content – html – design.

  26. 61

    Small point, I think you misunderstand what ‘Book An Event’ means.

    It seems to me to mean ‘book your own event at the venue’ and is unrelated to other events booked there. Therefore no knowledge of other events is required in order to use that button. In that light it seems fine for that the button to be a prominent call to action along with Join Us Today and not tied to the list of other events.

    That aside this was a good read. I’m a Rails developer and I often build out basic functionality in whatever non-pretty (but semantic) way necessary to validate an idea then bring design to the table afterwards. If the function and structure is valid then good design will only make it even better.

    • 62

      I think you’re probably right! That’s interesting. I’ve presented this information to 100+ people the past couple years and nobody noticed :-)

      Thanks for the insight!

      • 63

        Randy Picolet

        March 1, 2015 2:42 pm

        Except maybe the dates of the already booked events. Depends on the content that will appear in response to the button… Hard to tell.

        Which is why we need to iterate, to explore the details at multiple layers of abstraction, depending on the overall complexity: domain/document model, use cases/stories, UI structure/wire frames, layout and styles, and probably some code. For a simple website like the example used here, your suggested approach seems good, but for more complex content and usage, I would probably work up/refine a domain model and user stories with each iteration, even if no one else on

        • 64

          Randy Picolet

          March 1, 2015 2:45 pm

          on the team cared, and use those to drive the discussions.

  27. 65

    Mohammad Faizan Atiq

    March 4, 2015 8:02 am

    Great article! i agree with the writer that we have to change the way we design the stuff. The content-first approach gives us the edge to see the plan in a working prototype which the client can also experience rather than just bunch of images which needs to be updated every time a client demands.

  28. 66

    Hopefully there is someone reading this.

    I completely agree with what you have said here and this is what I have been doing since I was 9. It is also what I will most likely be doing when I am much older.

    Leaving that aside, I would like to ask you something. What is designing first? In this, you have shown a design in psd or img of some kind, you have then stripped it to its bare bones and wrote it up as html and then, you have simply added the design again so that it makes better sense.

    Is there a difference other than that the designing last aspect makes it better instead of the first design being the best version of the design?

  29. 67

    We need to understanding the entire process is design, not just pretty pictures. Everyone has a part in the finished product.

  30. 68

    I’ve found your article very helpful in laying down the base of how I want my (illustration) website to work. Being visual, I tend to get wrapped up in the bells and whistles. This was a good reminder that the people for whom my site is being designed for need a straightforward approach, meaning a quick, structured connection to content.

  31. 69

    Quoting from the article you said “The methodology explained above is for content-driven web pages — pages that are and should be accessible to everyone in all contexts” does this mean that this approach is suitable only for blogs and brochure sites, or can I use it when developing a web app as well? Say, a shopping cart app or something.

    • 70

      Rik Schennink

      July 11, 2015 1:21 pm

      It’s sort of a grey area, some web apps benefit from this approach greatly, some are so heavy on the experience level that it might become difficult to break them down into their content structures. I’d say a shopping cart can be easily described with HTML. But it might be a bit more difficult (and maybe less useful) to do for something like Adobe Kuler.


↑ Back to top