This introduction of fluid grids, flexible images and media queries has changed the way we’ve designed our websites quite dramatically. We’ve been re-sizing our browser windows ever since.
Starting off as a trend, Responsive Web Design has fast become the hot-topic of our industry and has now become the norm.
Over the past few years I have worked on several RWD projects. In almost all of these projects I have used a different design process, produced different deliverables and encountered many different problems.
Based on these experiences, and given that RWD is now becoming the norm, my workflow has had to adapt. Here are five areas in which I believe designers are required to step up in order to adapt to the responsive web.
1. Design with real content
Ever designed a module within a website using the trusty Lorem Ipsum, only for the copywriter/client to write twice as much content, or not enough, and your beautiful design is tarnished? And it’s too late.
I’m sure this is a familiar story to most of us, I’ve lost count of the number of times this has happened to me.
Imagine how much easier our lives would be if we had the site’s content up front? It sounds logical, but I bet this rarely happens to most of us. Come on, be honest.
Before a pencil has been picked up, or Photoshop has been opened, there needs to be a content strategy in place. Whether the output of that is the final content which will be used in the live site or not, you need a good idea of the content which will be used in the final site. What is the point in designing something when you don’t know what content will be used?
Once you have the content, you can start to build content reference wireframes. A term coined by Stephen Hay in his book Responsive Design Workflow, content reference wireframes use basic rectangular blocks to create a layout of content. Thus referencing where each piece of content will sit.
This technique is ideal for showing the basic layout of your main templates. You can show where the navigation, sub-navigation, footer and secondary modules will sit around the main body of the page. Without getting into any level of detail, you are designing the framework into which you will layer detail later down the line.
This is the time in the process that you should start to think about your responsive breakpoints. Taking the content which you have received from the content strategy, you can build a simple one-column layout for mobile devices. This is best done in the browser, using basic HTML, but more on that later.
By restricting your design to one column, you can begin to think about the hierarchy of the content on the page. What is the most important piece of the information on the page? Where should the main CTA sit? Does reading the content from top-to-bottom makes sense?
Once you have the order of information in a place you are happy with, increase the width of your canvas until the content feels stretched and uncomfortable, and jot down the width. This will be your first breakpoint.
Adjust the layout of your page to suit this new width, by adding a column for the sidebar for example, and repeat.
2. Design ‘in-browser’
Another key consideration for RWD is to ditch the flat visuals and Photoshop comps. They confuse the process too much by creating this idealistic view of how the site would look at multiple specific browser widths.
But they rarely end up that way. The final build nearly always looks different. Whether its the padding or spacing around elements, the way in which the type is rendered or the quality of the imagery, the final output rarely looks as good as the visuals the client signed off earlier in the project.
The problem with the visuals is that they look too good. The images are crisp, the typography is aliased and smooth, the use of drop shadows and blend modes make the design look like a work of art. We need to lower the client’s expectations before they sign the designs off.
The trick to doing this is to build a responsive prototype, using HTML & CSS values. Design in the medium in which the final product will be built. And present it in the browser. Show the client how it looks at various widths and on different devices.
Don’t worry if you’re not a whizz at front-end development, there are new tools emerging that help designers create responsive prototypes, such as Macaw, Webflow and Adobe Edge Reflow. Or you can ask a developer to help you out, but I recommend that you learn at least the basics. It will help you understand how your beautiful design will be built.
One of the benefits to designing this way is the reduction in the time it takes to make changes. Suppose you had 20 Photoshop (or Fireworks, as I prefer) comps, each of which had three resolutions (let’s say desktop, tablet and mobile), and you needed to update the button style or a link in the navigation.
That would mean going through 60 pages just to change one style. I’ve been there. It’s not very nice.
But by defining a CSS class you can make this update once, and it updates across all of your pages. I know this is quite an extreme example, but it will still save you time in the long run.
You will also be able to test your devices at various screen sizes. Most of the tools mentioned above come with preset viewports built in, but if you can export your designs out and get them into an actual browser, then you can really get a better feel of the mobile experience you are designing.
3. Develop a pattern library
One of the key outputs to nearly all of the RWD projects I have worked on is a style guide. These would include key styles for the project and interactive states of all modules. It would even include a bit in there about the responsive framework.
But there’s a new breed of beast evolving here, that of the pattern library. Anna Debenham has written a great article about getting started with pattern libraries for A List Apart. This is where you would define each of the common UX patterns used throughout your site, revealing notes and code snippets along the way.
Now I would normally put these together in Fireworks, using symbols and styles for common components and modules. But for a responsive design you would need to illustrate how each module would adapt between the breakpoints you have defined. This takes quite some time to do in Fireworks.
And because we are designing a prototype in HTML & CSS, it would be a shame not to build the pattern library in the same way, right?
Brad Frost has a great theory around ‘Atomic Web Design‘, where by he uses some scientific terminology to define aspects of his web designs. Atoms are the basic brand styling which form the foundations of your design. Things like colours, fonts and icons. These are then applied to basic HTML elements to form ‘molecules’. Think of a search button. Molecules are then formulated to create ‘organisms’. In this example we could add a form input and label to our button.
These are then combined with other organisms to form ‘templates’ e.g. a header (we lose the scientific terminology here but you get the point). And then these templates help form pages. And voila! You have an Atomic Web Design.
We can use this theory to form the structure of a pattern library. Begin with the brand styles. Apply these to the core HTML elements. Form some common patterns using these elements. And so on.
You’re making your pattern library tell a story of your project – how you’ve taken the client’s brand and created a new online presence for them. You should include notes and code snippets along the way for developers to access and for the client to understand your design.
The pattern library is fast becoming a vital output for responsive web designs, as we make the shift from designing pages to designing a system of components.
4. Make it universally usable
The thing about designing a responsive website is that you cannot predict each user’s experience, especially when it comes to the mobile experience.
There are literally hundreds of different possible scenarios of how a user could be using your website. This comes down to the number of smartphones and tablets out there with their varying screen sizes, resolutions and input types. They could even be using their televisions.
Your design is going to have to totally universal and adapt to whatever surroundings it is placed.
Here are a few little hints and tips I like to keep in mind when designing responsive experiences.
4.1 The rule of thumb
Because a lot of mobile devices are touchscreen nowadays, we need to be mindful of the size of the interactive elements within our interfaces.
There are slightly conflicting reports on what the ideal hit area should be. Apple says it’s 44px. Microsoft says 34px [source].
I always use 48px as the ‘rule of thumb’ when designing my interactive elements. And then leave at least 6px spacing around each hit area, normally derived my 12px baseline.
In the day and age of flat designs and larger type sizes, many sites nowadays are maintaining these slightly oversized hit areas for their desktop experiences.
These over-sized elements should also be used in forms to help keep them simple and mobile friendly. As a designer, I like to design my own over-sized form fields, to fit in with the styling of the site.
But one recommendation I would make is to use the native controls where possible on mobile experiences. The keyboards and drop out menus have been optimised to the device in which you are using. And it would be a shame to waste your time designing something which is already integrated, wouldn’t it? Not to mention the dev overhead of adding a custom form UI.
Oh, one more thing on the point of interactive elements. Ditch the hover states for mobile experiences. Please.
Think of this as a progressive enhancement feature for desktop. A little bit of polish you could add to enhance the experience. There is nothing more frustrating in my opinion than having to tap something twice on your touchscreen device to get somewhere. All because of a fancy hover state.
4.2 Navigation
One of the biggest challenges when designing a responsive website is how to handle the site’s navigation. Now there are quite a few ways to do this, and depending on how many breakpoints you introduce, some may be more complicated than others.
Jump links
Possibly one of the simplest and most universal techniques for mobile navigation, the jump link menu is essentially an anchor link which jumps the user down to the menu in the footer of the page.
This is great because it requires no javascript or any other added scripts to implement, making it universal across all browsers and devices. It also serves as a neat little fall back to some of the other techniques described below.
Drop-down
Another common mobile navigation pattern is that of the drop-down menu, where the menu icon reveals the navigation below using a sliding animation. This technique uses javascript to position the menu below the button and then hide it until it is requested by the user.
Some of the items within the navigation could even use an accordion to hide any child elements it may have. This allows the user to drill down through the levels of navigation, thus skipping each of the landing pages.
Off-canvas
The off-canvas method is possibly the most popular technique being used in RWD as we begin to make our sites more ‘app-based’. Pioneered by Facebook on their mobile apps, the off-canvas method allows the designer to position the site’s navigation off the edge of the viewport and slide it in upon the user’s request.
Some sites, such as Teehan+Lax and Squarespace, use this technique as the only method for navigation across all experiences. This, I believe, is the start of a big trend in RWD.
4.3 Task-orientated mobile layouts
Another key consideration when designing your mobile layouts is surfacing any key calls to action nearer the top of the page. And yes, I’m going to say it, above the fold.
It has been widely discussed recently that there is no ‘fold’ in web design, and the explosion of new devices and their varying resolutions has made it even more difficult to predict where the fold will be on a given web page. We could, however, determine a ‘safe area’ based on the smallest viewport size.
Because mobile users are generally on the move and have limited time and bandwidth, it is important that we surface any major CTAs nearer the top of our screens, with supporting content placed beneath.
A key example of this is mobile e-commerce design, where many product pages contain the product name, price, thumbnail images and CTA to buy all above the fold, along with the site’s navigation. The secondary content, such as product features and specifications are then played out below.
A good way to achieve this is through a careful content strategy and thinking of the top area of the screen as an app. Think about what the user is there to do and surface the relevant links within the initial view.
5. Keep performance in mind
We can never predict who the next user of our website will be, what device they will be using and on what connection. That is why we need to design our responsive websites with performance in mind.
Nobody likes to wait around, especially on the web. If your web site doesn’t load within a few seconds, you’ve just lost your user. They’ve already moved on.
Improving the performance and reliability of your site helps build the user’s trust. If they have a good experience and your site looks good, they’re bound to return. The key here is to keep your web pages as lightweight as possible.
Over 60% of the file size of most web pages are down to images alone. The rest of the file size is made up of scripts, style sheets and other media types.
Now the easiest way to bring your file sizes down is to export them out for the web from your chosen graphics application. But this isn’t enough. Especially if you use PNG files with transparency.
Websites such as TinyPNG help reduce the weight of your files by stripping out additional data and reducing the number of colours used in the image. Sites like these are a godsend and should be an essential part of your web design toolkit.
Responsive images
As well as reducing the file size of your images, sometimes it is necessary to serve up different images to different devices, or at different breakpoints, in this case.
The reason for this being is that we don’t want to be serving up huge images that are hundreds of kilobytes in file size to a mobile device which has a data limit and a poor 3G connection, do we?
There are many scripts out there that help you do this, such as Scott Jehl’s Picturefill, and Adaptive Images, depending on your site’s needs and server-side capabilities. But let’s not worry about that. What we as designers need to worry about is specifying how our images will adapt to different breakpoints and devices and documenting this. Ideally in our style guide or pattern library.
Cut the script
Another large chunk of our website’s file weight is down to the various scripts we use in our sites, such as Javascript and additional CSS stylesheets.
You’re probably all thinking “Surely this is something for developers to worry about?”, and you’re right to an extent. If we are to adopt a true mobile-first approach then our CSS should be written that way, with any stylesheets for larger breakpoints only containing the overrides from the mobile style sheet.
Something we should always keep in mind as designers is the amount of ‘animations’ we use in our designs. And by animation I mean anything that moves and requires scripting, as this is a big factor in bulking up the file size of our script files.
If you are designing mobile-first, then it’s best to keep things simple and static to begin with. And if you feel the need to add a nice slide here and there, then you can add it in and see for yourself the effect it has on your site’s performance.
Serve in small chunks
A good way to reduce the file size and improve the performance of your mobile users is to cut your content up into little chunks and provide this content upon request.
I’m not saying you need to segment all of your content, just the secondary content that you would normally place in the right hand column or in an overlay. You know the stuff.
There are plenty of progressive disclosure techniques that can help this, for example the ‘load on scroll’ technique that many social networks use in their news feeds. A similar techniques is to place a ‘load more’ link at the bottom of the feed, so that users can load more content if they want (instead of accidentally loading more when they reach the bottom of the page).
Another useful way to serve up more detailed or secondary information would be to place it on another page for mobile experiences. This could be as simple as a ‘find out more’ link which on click takes you to a new page with more information included. And a nice clear ‘back’ link, of course.
Conclusion
So gone are the days when all a designer used to worry about was the juxtaposition of content, the colours used and the typography styles of their web pages. We are no longer in a world where designers hired simply to ‘colour in’ detailed wireframes in a typical waterfall-style project.
We’ve now got to consider so much more. We have to begin to understand how our sites are being built, and the process around prioritising our content to suit the user. And the the only way to truly understand this is to roll our sleeves up and get learning.
As our industry tries to keep up with the explosion of web-enabled devices being released, there is always something new to learn about in the world of the ‘responsive web’.
I’ve only listed five topics here, but there are so much more to consider. And there may even be even more by the time you come to read this.
It’s time to broaden our horizons as designers, learn some of the stuff in which our developer and user experience cousins preach, and become better all-rounded individuals. And make the web a better place. On every device.
Our Festival of Marketing event in November is a two day celebration of the modern marketing industry, featuring speakers from brands including LEGO, Tesco, Barclays, FT.com and more.