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.

Design Process In The Responsive Age

You cannot plan for and design a responsive, content-focused, mobile-first website the same way you’ve been creating websites for years—you just can’t. If your goal is to produce something that is not fixed-width and serves smaller devices just the styles they require, why would you use a dated process that contradicts those goals?

I’d like to walk you through some problems caused by using old processes with responsive design. Let’s look into an evolving design process we’ve been using with some promising new deliverables and tools. This should provide a starting point for you to freshen up your own process and bring it into the responsive age.

Further Reading on SmashingMag: Link

The Problem Link

The issues caused when trying to force new results from an old process are significant yet, strangely enough, not immediately obvious. We’ve all just gotten used to them, like the annoying quirk we didn’t realize we had, until someone points it out. And from that point forward, it drives you crazy.

Design Process In the Responsive Age

For example, when we create a desktop-sized, fixed-width site layout in Photoshop and hand it to a developer to interpret into HTML/CSS, we are asking the developer to make a lot of design decisions—possibly without even realizing it. Below is just a small sample:

  • How should the layout adjust for smaller-sized devices? (It sure would be nice to have a hierarchy of important page elements based on their purpose, huh?)
  • What is the hierarchy of the content? (Gee, all that “Lorem Ipsum” doesn’t make it obvious?)
  • How does the navigation respond to smaller screens? (How do I handle ten links with five child pages each revealed on hover with a 320×480 touch device?!)

This can cause major problems if the developer doesn’t feel confident in the visual arena. Even designers/developers who feel comfortable making those calls can get in hot water. In the end, the developer is often forced to make assumptions where plans were not made clear beforehand—sometimes days before feedback from designer or client becomes available. Sometimes it works, sometimes it doesn’t.

Work More or Work Efficiently? Link

It’s easy to resort to working more to resolve these new challenges. What comes naturally? Do a desktop and mobile-sized wireframe, then turn around and design a desktop and mobile-sized layout. This sort of solves the problem. You and your developer have more to work with, at least. However, what about all the device widths in-between—you’ll have to cover those as well, right?

At this point, you wake up and realize you’re stuck in a familiar loop of ever-increasing deliverables and ever-shrinking profits. Using this old process to tackle new problems doesn’t really solve any of them, and it’s going to kill you from lack of sleep, make you poor from lack of profit, or both.

There are some good ideas floating around dealing with new processes. Some smart folks4 are of the very sensible opinion that the only answer is to design in the browser. However, other smart folks have admitted for the quiet rest of us that it’s really, really hard to design freely in the browser—at least with current tools.

Of the emerging new process ideas, those that involve responsive HTML/CSS prototypes5 look very promising. I’m planning to investigate these further. However, there are some definite challenges with this approach, not the least of which is the time it takes to create them when the site content is complex. Most of the examples I’ve seen are fairly generic, which doesn’t translate well to real projects.

Currently, we are successfully using a different approach. It attempts to optimize content, design, and development time, finding a budget-friendly balance of appropriate direction from all disciplines—something that is effective, lean and uses quick, widely-accessible tools.

Solution: The Priority Guide Link

I used to call this my “mobile-sized content prototype wireframe thingy.” For obvious reasons, however, I was encouraged to change the name by pretty much everyone I know. I liked the specificity of the name, but brevity won out. So, I settled on: Priority Guide.

Essentially, with the priority guide, we create a single deliverable that provides direction for content-focused design and mobile-first development in something resembling a wireframe.

Image of several screens from the Dress Responsively Site priority guide.6
Download a PDF of the guide.7

By nature, a mobile-sized approach is narrow and forces more of a single column layout. The single column, in turn, causes a linear display of content and features. This linear display makes priority and hierarchy much more apparent than a desktop-sized wireframe, especially if you attempt to use a draft of real content instead of greek text—hence the content prototype8.

At that point, armed with just this priority guide, the designer sets off to create something beautiful. The designer cranks up trusty ol’ Photoshop and begins a new layout at a traditional desktop resolution—just like you may have done for the past ten years. For a good web designer (outfitted with his super-duper powers of visualization), it is a snap to make design decisions for a desktop resolution while looking at a mobile plan. That’s just how their minds work.

Homepage design for Dress Responsively site.9
Download a hi-res JPG of the final design.10

Once the design work is done, the handoff to the developer consists of the completed desktop-sized design and the original mobile-sized wireframe.

Don’t Let the Simplicity Fool You Link

This approach may sound simple—which is part of the beauty of it—, but it also provides some real benefits:

  • The developer is provided a sort of bookended direction, both desktop and mobile. Two guides to follow, each offering unique information. Some interpretation still has to be made, which isn’t a bad thing, but there is far less guess work.
  • The designer is given a wireframe that provides hierarchy but does not dictate desktop-sized layout, where ample real estate allows for more creative room to breathe—designers need to be given their freedom, lest they shrivel up into sad, hollow, hipster-jean-wearing shells of themselves.
  • From the prototype and their linear approach, hierarchy can be understood fairly quickly, and the foundation for mobile-first markup and style is implied but flexible.
  • All of this is done in a two-deliverable process, like before, so it saves time and budget. Any method you get better results in the same amount of time (or less) is a good thing.

A Note About Context Link

Any conversation concerning mobile web draws questions of context. Is there a “mobile context”? If one does exist, do users actually have different expectations of a website’s content while they are mobile? And, if users do have different expectations, how do we address them? Whew.

In short, those questions aren’t what this article is about. These issues are being11 discussed12 in depth13 elsewhere14. I believe that questions of context can be answered very differently, depending on the project. I’ll leave it to you and your team to apply due diligence in addressing context.

What I will suggest, however, is that you tread very carefully when making assumptions about your users and limiting content as a result. Though a mobile context may exist, you can’t make those assumptions based on screen size alone. People surf the web on their phones from their couches, and they have all the time—and expectation—to access all of your site’s content as they sit and watch TV. This is why we believe in a responsive web design approach that acts as a safety net15 where little to no content is abridged from the experience of the user. This is the approach reflected in the above article—plan for all content in all contexts.

Tools To Consider Link

Style Tiles Link

Designer Samantha Warren just recently presented her concept of Style Tiles16 at SXSW. She was featured just days later on A List Apart17 discussing the same concept. We love it. It’s one of those concepts that makes you slap your forehead, wondering why you didn’t think of it sooner. It makes sense for web design in general, even more so in responsive design where client delieverables are much more tricky. We are already planning to integrate this into our workflow. We envision this deliverable being presented to a client during the wireframing process, so progress concerning style and layout can be made separately but concurrently.

Keynote for Wireframes Link

I’ve been loving Keynote for wireframes lately—it’s even great for mobile-sized content prototype wireframe thingies. If you haven’t tried it, give it a shot. It’s quick, easy to learn, and easy to share. A really interesting article was written recently about designing in Keynote. I’m not sure I’m ready to go that far. However, it’s a fantastic wireframing and planning tool, and there are some great kits to get you started. We’ve been using this one18 from Travis Isaacs.

Conclusion Link

If you gain nothing more from this article, let me remind you what you already know: don’t be afraid to try new things. No process is a silver bullet—the same is true of tools and deliverables. If the ideas above don’t fit your project, scrap them and try others. However, you must evolve your design process to account for the evolution of the web and users. If you hope to solve new problems, you’re going to need a new approach.

You must also address the very human issue of communication. Earlier and more frequent collaboration among team members and the client must become the rule in your workflow, not the exception. Content, design, and development team members must review and collaborate regularly at every stage in the creation process until the site is live. We can’t ‘throw it over the wall’ anymore—at least, not if we want our sites to be excellent. There are simply too many moving parts now. Go forth and collaborate.

(jc) (fi)

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

↑ Back to top Tweet itShare on Facebook

Drew is the Director of Content Strategy for Sparkbox in Dayton, OH. They run a two-day Responsive Web Design conference: Build Responsively Workshop. Feel free to check out the presentations from the workshop, the live example project website itself, or invite us to present in your fair city. You can connect with him on Twitter: @drewtclemens.

  1. 1

    Steve Fisher

    May 30, 2012 9:56 am

    Just to throw this in to the conversation but I produced a small site that is related to this topic back in December 2011.

  2. 2

    I’m curious, how do you handle planning for interaction design?

    • 3

      Good question, Jay. The example above doesn’t speak much to that, as the example site was fairly simple. I’m not satisfied with it, but I’d say my solution so far has been additional callouts in the Keynote file (things like the pink bursts shown above). This does break down, however, when interactivity gets more complex. At that point, I’d say you’d need to add things such as keynote animation and transitions to really get the point across… which is one of the nice things about using Keynote. But then it must be presented as a Keynote presentation, and can’t be shared as a PDF, etc.

  3. 4

    I’ve been doing a lot of thinking, research, and experimentation into this kind of workflow lately (the boss is always talking about them kids and their fancy phones) and have found the whole process to be immensely more complex and time-consuming than it is often made to seem. While ideas like “mobile first” and “content focused” are great principles, I think they obscure the fact that mobile web design and development is a dramatically different challenge.

    Mobile web design involves learning and internalizing an entirely different set of rules and limitations, which can be a tough pill to swallow just as we’re enjoying the freedom of modern browsers and technologies. These are much trickier rules than we’re used to, however. Instead of “don’t use transparency, limit yourself to web-safe fonts” etc, we now have to accept the “assume nothing” reality of mobile browser capabilities. Creating a mobile-first layout that focuses on content and hierarchy is not enough for a design to be mobile friendly, it has to somehow strike a balance between browser limitation and content parity, with testing on multiple devices every step of the way.

    Until we’ve internalized and accepted all the quirks and limitations of every blackberry, android, and iphone, (or, more miraculously, mobile browser support becomes less fragmented), creating a truly mobile-friendly web site is a lot of time, effort, and headache for 10% of your visitors (obviously depending on your site’s analytics). Which is not to say it shouldn’t be done, just that it’s a complicated risk-reward analysis.

  4. 5

    Viljami Salminen

    May 31, 2012 12:12 am

    I wrote an article titled “Responsive workflow” about a week ago, which shares quite similar ideas. You might be interested to read it through:

    • 6

      Hi Viljami, I found your article extremely helpful in defining my own responsive design process, thanks very much for sharing it!!

  5. 7

    Craig McPheat

    May 30, 2012 3:21 pm

    Currently looking at introducing a page table approach to content to help with that linear prioritisation of content.

  6. 8

    Thomas Strobl

    May 31, 2012 12:19 am

    We all know that good content is absolute necessary for absolute every website existing. And with the whole responsive process it seems to me like people try to get the same experience to desktops and mobile devices–just with a little different styling. While this works perfectly to simply display content in a usable manner, mostly one very important factor is missing:

    I know it aint necessarily so and there are people doing a great job discovering new techniques to display responsive content, but afaic the lion’s share of responsive websites have – because of the mobile first approach – a pretty dull desktop version that really doesn’t set you apart from your competition.

    Using media queries to create custom experiences for different devices is absolutely the way to go! But please don’t end up creating humdrum websites, just because of the sake of being responsive.

    My conclusion:
    I dont think websites viewed from a desktop browser should look different than before “the responsive web design trend” came up. It’s supposed to enhance a mobile experience, not to degrade desktop experiences. I think it’s important to keep that in mind.

    • 9

      Agreed. Though it’s not surprising that, as people are just learning new techniques, the designs will be more simple. It’s one of those things where you can’t really branch out to be creative until you have a firm grasp on how things can be executed. I think the “simple desktop” designs will fade as we all grow more confident in our RWD. We’ve begun to see that in our own work in our office.

  7. 10

    Marcus Marritt

    May 31, 2012 1:33 am

    I’ve been addressing our own design workflow at Zabisco recently, some real good nuggets here Drew – and I couldnt agree more that a workflow fitted for RWD and the challenges this presents is the only way to avoid massively over inflated project budgets and a what could end up being a mish mash of a design project. Collaboration is key for sure, its about the smooth transition from design to developer

  8. 11

    Does anyone remember (or actually use) “page description diagrams?”

    This solution sounds a lot like those. You gain flexibility and cut to the essentials – but you also lose the benefits of wireframing for the desktop.

    I’d love to hear a good cost-benefit analysis that would justify the loss of those benefits.

    BTW: Most of my clients are professional associations with very content heavy websites. My company almost always works on fixed budgets and we’re usually on the hook to build the systems we design. And 90% of the users are on desktop.

  9. 12

    Laura Müller

    May 31, 2012 5:43 am

    Our agency mainly develops websites and has a separate team for mobile sites and apps. We are trying to build responsive websites with a good user experience over all channels, but honestly, at the moment, i don’t know, how this should work. All the examples around the internet of responsive design websites, they do function, but especially for smartphones the user experience is not nice anymore. Long loading time, bad performance, and a very simple/ bad UX. Our solution at the moment is: We find out which devices our target group uses (for each project individually), we build a responsive version for tablets and for smartphones (of the target group) we use mobile templates, that are integrated into the CMS. Usually our clients have very complex websites, and with responsive design it is in my opinion not yet possible to get a good UX on smartphones. I would love to know, if someone has had similiar experiences and what their solution was.

  10. 13

    Brian Walker

    May 31, 2012 1:43 pm

    I like your solution of the Priority Guide. I have been following a very similar process when designing responsive sites. I find that prioritizing content “blocks” in this way also makes it easier for the client to understand the responsive design flow.

    I recently wrote a blog explaining responsive design to non-designers, that you may find relevant:

    @Thomas Strobl
    I think that the responsive design process is still new to many designers, and it can be difficult to get your head around. You can do truly amazing things with it, if you’re willing to push the limits. I like to browse for inspiration.

  11. 14

    I agree the Priority Guide seems like a step in the right direction. This reminds me of an article I read a while back that echoes some of your sentiments, but was focused mainly on how we need to structure agencies going forward:

  12. 15

    What program do you recommend for designing your priority guide? Do you have a template?

    • 16

      Matt, check the end of my article (above) under “tools to consider.” I discuss both keynote and some toolkits.

  13. 17

    Kim Joy Fox

    June 5, 2012 8:31 am

    The main issue I’m running into with responsive design is that is takes a whole lot more work to produce… which means higher quotes for websites.
    So on the practical side, I’d like to hear what other web developers are doing about this. Do you offer clients different packages? So a website JUST for desktop at a lower price, and then a responsive design for a higher price?

  14. 19

    Christoph Zillgens

    June 5, 2012 8:02 am

    Great post, Drew!

    This comes close to how I planned my workflow for the last responsive projects. But I found out that it didn’t work the way I expected. There are many things left to consider.
    The priority guide is a great feature and important for content planning. But it doesn’t tell enough to the developer on how to transform the desktop design to the mobile version:
    – What’s the grid on mobile?
    – what about margins?
    – How big is the logo?
    – How does the navigation look?
    – Where to place the votes?
    – and so on
    If you compare your priority guide to the mobile version of the website, there a too many differences between them. A developer needs more instructions.
    I had such a situation recently and couldn’t help myself but creating a separate, complete design for the mobile version to hand over to the developer.

    So the thing I’m missing in your article is how to get from the priority guide or desktop layout to the final mobile layout.

  15. 20

    Jonathan Lupo

    July 13, 2012 11:31 am

    Honestly, I think front-end developers need to be considered part of the Design team, and their role needs to be to get the conceptual framework of the experience, as quickly as possible, into code. Designers are not designing experiences if they spend all their time in Photoshop creating “mock-ups” of experiences. They need to witness how content and layout actually reflow, in the context of multiple, real-world, devices. Thus, prototyping becomes a critical part of the Design process. To make this easier, the visual representation of the UX, that gets to code first, need not be a hi-fi representation of the experience. “Blocking out” the UX, in the browser, ensures focus on content and a high-fidelity experience…not a beautiful Photoshop rendering of an experience that falls apart when a user switches an orientation from portrait to landscape on a mobile device.

  16. 21

    Lainie Barbeck

    December 23, 2012 8:10 am

    I am only 9 years old and I want to make a app but I don’t understand still. I want to make a game but I don’t know how and the article you wrote doesn’t help me at all it just confuses me even more please write back.

    • 22

      Annette Arabasz

      February 5, 2013 7:16 am

      Lainie – Do you know what kind of game app you wanted to make? Like… did you want to make a game for a computer… or maybe an iPad?

      I’m really happy to hear that you’re interested in making a game. I’m not a author from Smashing Magazine, but I’m a web developer and I’ve always wished that more young people would try to code. (I’m 27.)

  17. 23

    Marc A. Donald

    March 13, 2013 7:20 am

    Nice Article ! We can consider web design as a combination of planning + mixing text, images, and multimedia files to form a professional web design. Web designers utilize HTML for the website structure and CSS for adding their final touch from colors, fonts, alignment. Javascript is important as well to create an interactive page.

    But the point that web designers should be more familiar with the new web design techniques such as responsive web designs. Nowadays, huge traffic is coming from hand-held devices such as tablets and smart phones. A responsive web design will work on any device with no problem.
    Thank you,
    Marc A. Donald

  18. 24

    Victoria Kuhn

    April 14, 2013 6:12 pm

    I read this post some time ago and keep coming back to it. My team has been developing mobile first/RWD sites for more ~18 months. I do much of the user experience work though I expect my creative designer to take on this work (I use Flairbuilder, it’s a great wireframing package). It’s especially imperative for RWD sites. Your post stuck to the process of design … if you more to share about the user’s experience and how you design with the user in the center of the universe, please share. Thx.

  19. 25

    Ravinder Kumar

    May 7, 2013 10:41 pm

    This is the first article I read about “Responsive design”. I am a Flex Developer and started looking into the HTML world. The post is not very helpful for me but now I know what “Responsive design” is. I would like to appreciate everyone who left the response and provided additional links for more references.

  20. 26

    Hi Drew,
    Wanted to let you know that you have a dead link in your article. Under KEYNOTE FOR WIREFRAMES

    Great article.

  21. 27

    Now I know one more way to mock up :)
    thank you for the tips on wireframe with Keynote

  22. 28

    Very nice design on web site. mobile web design involves learning and internalizing an entirely different set of rules and limitations, .and

    This blog is very well written and I appreciate your efforts.. Keep up the good work


↑ Back to top