On October 18, I gave a presentation at BarCamp Nashville called “Rethinking How We Design for the Responsive Web.” Below, you will find my slides as well as a draft of my presentation.
“Rethinking How We Design for the Responsive Web”
In his 2010 “A List Apart” article, Ethan Marcotte identified Responsive Web Design as a combination of fluid grids, flexible images, and media queries for the progressive enhancement of our work on the web. Progressive Enhancement, to review, is simply the idea of starting with a basic, cross-browser, device-compatible foundation, and then adding to it for the benefit of visiting user-agents that can handle the improved experience.
In this same article, he also tells us that while these technical ingredients are critical, Responsive Web Design also requires a different way of thinking.
At the time that article was written, Mobile browsing was expected to outpace desktop browsing within 3-5 years. 4 years later, right on schedule, here we are. More importantly than this fact, is the research that shows that there is no one device owns more than 20% of the market share, and the number of devices with the capability to access the internet is growing constantly. We have virtually no way to predict how the websites we create are going to be viewed, interacted with… experienced.
And yet, in 2014, so many of us are approaching designing for the responsive web in the exact same way that we design for print.
We start with a blank, fixed width, photoshop document. Generally, somewhere between 980px-1200px wide. Some of us, in an attempt to account for the unpredictability of our users, have then been so forward thinking as to create another blank, fixed-width photoshop document with a width of, oh, I don’t know, let’s say 320px wide. ( This was the width of the first 3 generations of the iPhone). Some even go so far as to design for even more specific breakpoints, tablet sizes, Android device sizes, etc. Let me be clear, these numbers – are arbitrary. Responsive web design is all about creating websites that adapt to their environment. The content should define breakpoints. In Ethan Marcotte’s book, Reponsive Web Design, an expansion on his A List Apart article, he implores us “What if we focused on the needs of a specific design instead of a hypothetical device use case? What if we built layouts that simply worked everywhere?” Devices are growing, shrinking and changing simultaneously, and unpredictably. Starting with a design for a desktop browser and then trying to squeeze and stack elements to fit them into a width almost 25% of that size – is ludicrous. We have to build experiences that will grow, shrink and change along with the technology that allows us to interact with them. After years of working the way our design school educations taught us before responsive web design had made it into their curriculums, isn’t it time we start rethinking the way we design for the responsive web?
Today, I want to talk about a couple of different design theories that can help us adapt our processes for a more appropriate, effective, and long-term solution to responsive web design. To drop a couple of buzzwords that you’ve probably all heard before, we’re going to dive a little deeper into “Mobile-first Web Design” and “Atomic Web Design.”
Mobile First Web Design is simply the idea that rather than starting by designing for the desktop browser and scaling down, “gracefully degrading” our website designs, we start with the lowest (smallest) common denominator and build up, “progressively enhancing” our websites, adding features and functions as we go. This is something that should happen in the planning stage of creating a website. I am not talking about starting with a 320px wide photoshop document and then moving to a 1200px wide photoshop document. This is about strategy, sitemapping, and planning hierarchy. The web is everywhere that we are, and we need to think about how to provide the best user experience regardless of the point of entry. The best way that can start to design “Mobile-First” is by designing “Content First.” We should be thinking about how the content should be presented, and going from there. We don’t start in photoshop. We don’t start the visual designing at all until the content questions are answered. Until a structural hierarchy is established that can inform the way that the end user should experience the website – from the smallest screen and the lowest resolution, to the largest, most feature rich device.
I’ve created an example for today so that we can walk through what this process might actually look like. This website, while based on an actual client project, is purely hypothetical. In fact, we’ll call the product, “Product,” and the company, “Hypothetical Company.” So let’s say that “Hypothetical Company” has developed a digital product for a specific type of aircraft. The company has now asked us to create a website to advertise and distribute the product. Right off the bat, we’ve identified the two main top-level goals of this project. Advertise, and Distribute. We’ll want to provide product information, features and benefits, and an e-commerce solution that allows users to purchase, and download, the digital product. The client has provided us with a description of the product, a detailed list of features, a screenshot tour of the digital product in action, and a product brochure that they would like available as a downloadable file. They have also requested that the product be available both for purchase, and as a 90-day free trial.
We know that our top-level goals are to advertise and distribute the product. Let’s think a bit about the content we need to present, and how we can best accomplish these goals.
First, we’ll need to identify the company. Then the product. We’ll need to, briefly and immediately, establish what the product is, and how customers lives will be improved by purchasing it. We’ll need to encourage the customer to buy it, or at least try it.
Then, in case our audience is not convinced, we’ll delve a little deeper in features and benefits. We’ll show the customers specifically how the product will improve their lives.
Once we’ve done this, it’s probably a good idea to include another call-to-action. Maybe a softer sell… just try it.
So,
1) Who are we?
2) What’s the product?
3) What does it do?
4) Buy It/Try It
5) More info – features and benefits
6) Try It
In addition to these 6 points, we’ll still need to include supplemental information such as the Screenshot Tour and Contact Info. This information will live in the main nav, and will also be accessible in the footer. Now, we have content in hand and have established a rough content hierarchy based on that information.
I know we’re kind of breezing through this, but I want to get through a brief overview of the entire process. Obviously, content development and structural hierarchy require and deserve a lot more time then this. They are the foundations upon which a successful website is built. In fact, they are the walls and the roof also. That said, in the interest of time, I’m going move along.
Once content has been developed, and a clear content hierarchy has been established, we can start thinking about how things should look. Themes, fonts, colors, “look and feel” if you will, etc. Atomic Web Design, a methodology presented by Brad Frost last year, is a way for us to create full design systems for our websites. The thought process behind Atomic Web Design revolves around something like this:
“All matter is comprised of atoms. Those atomic units bond together to form molecules, which in turn combine into more complex organisms to ultimately create all matter in our universe. Similarly, interfaces are made up of smaller components. This means we can break entire interfaces down into fundamental building blocks and work up from there“ – Brad Frost
Take a simple webform for example. We’ll give it 4 fields, Name, Phone, Email, and Message, along with a submit button. For the sake of this example, I’ll break down the form in the following way. [SLIDE OF FORM] The atoms are the labels, fields, submit button and container. These atoms combine to form a molecule, or in this case, a form. [FORM SLIDE] By designing this way, we are creating a design system that will inherently provide consistency, flexibility, and the ability to “work our way up” through the design process.
Generally, HTML tags (such as a form label, field, or button) are the atoms. Atoms are also a good place to start defining our color palettes, typography and transitions.
Molecules are a group of atoms bonded together to create a something useful. Molecules can then be combined to create organisms, or, “a relatively complex section of an interface.” For instance, a site header would be considered an organism, comprised of a logo, navigation, search bar and container.
We’ll have multiple organisms on a page, in HTML5, these are generally sections.
I’ve created this site for the purpose of this presentation: Let’s take a look at the homepage and identify some organisms
Of course, we’ve already identified the header as an organism.
Additionally, we have the Introduction Section, Features Section, and Footer.
The Introduction Section is comprised of several atoms. The atoms here are a Headline, or H1 tag (product name), subhead or H2 tag (by company), description, and two buttons. Together, these atoms form a molecule that will give some introductory product information and options to purchase or opt for a free trial. This molecule, coupled with the large image background, and the additional molecule for the secondary headline, “Performance Calculation Software for a Specific Brand of Aircraft” form the organism that is the Introduction Section.
Now we don’t have to walk through the entire page, but I do want to talk about something about the next section, the Features Organism. This section is made up of six identical molecules, which are each made up of three identical atoms, the headline, paragraph and container. By using atomic design, we have inherently created a solution that automates the recreation of identical elements. I can also use these predefined atoms in internal pages as well which will, without even trying, establish consistency throughout the site. First, let’s take a step back and look at how atomic design works in the earlier stages.
This is how we can to create responsive websites at an atomic level. We identify different elements that we know will be present on the site. We identify high-level options like typography, color, shadows, etc. We identify different elements – how we will treat Headlines, subheads, paragraph text, photos, buttons etc. We break the site down into it singular atoms, create a design system based on those elements and then build it up from there. We combine these atoms into molecules, molecules into organisms, organisms into templates, and templates into pages. As we combine these elements and build our website, we start small. Our atoms and molecules are design deliverables for client approval. Our sites are built modularly and our breakpoints are device agnostic – based wholly on what makes sense within the constraints of the content. Clients are better able to understand that we cannot define our designs based on specific devices because this is how the visual conversation starts. Team members who are less well versed in web development begin to see the steps laid out in front of them, and have a better understanding of what building a website means today. Our websites are more likely to be future-proof, accounting for a myriad of unprecedented shapes and sizes.
This is not an easy shift to make. It means no longer seeing a picture of the website before it’s built. It means we don’t use a photoshop file like a puzzle box top to reference which piece goes where. What it does mean, is that we are making thoughtful, effective decisions to provide a superior experience to the end-user.