When making the transition to building responsive websites, the hardest part can be getting started.

I get my fair share of questions about how to choose a direction and chart out the first few steps from industry comrades and potential clients. It can seem daunting, so I thought I’d attempt to sum up a few of my own current thoughts on the matter.

Consider RWD From the Beginning.

I believe this starts with a shift in perception. Whether massive or minute, this shift usually involves letting go of a lot of assumptions that center around desktop-centric browsing. There is so little that we can actually count on: mouse pointers vs fat fingers, hover states, screen sizes, connection speeds, device capabilities, etc. What good is initial planning (content strategy, IA, sketching, prototyping) without considering all of the variables the multi-device web provides?

If a team is knee-deep in .PSDs before considering layout changes and alternate viewports, opportunities for optimization and innovation will be overlooked. I’d rather proactively embrace a new approach than try to shoehorn an old one.

Benefits of a Lengthy On-Ramp

If I were on a team organized around fixed-width desktop-centric production I wouldn’t want to be expected to immediately start building responsive sites at the usual pace. Taking time to fiddle with devices, hack code, and perhaps most importantly, time to think pays off in the long run. Giving teams and individuals a cushion to get back up to speed after taking a new direction helps instill a sense of purpose instead of panic.

This cushion could be in the form of extra time for reading and research, extra time budgeted into a project, or even better, a responsive hack week project. Imagine teams of 2-5 that build a responsive site on any fictitious topic they want.

We had to uproot a lot of what we were used to at Paravel, and there are only three of us. Processes and roles will change. Not everyone will be delighted about these changes all the time, so ease in and give team members time to learn by doing.

De-compartmentalize workflows.

I’ve mentioned this before, but ditching the assembly line method of site building for a more communicative, iterative process will be helpful. Team members learn from each other (fatten those T’s) and arrive at solutions more quickly when they work closely. Rather than a more traditional design and development departmental split, why not create small teams with both design and development talent? That way, when someone has a good idea, it can be designed and prototyped without the hassle of multiple handoffs.

On Content

No amount of design or code can adequately fix content problems. It can be tempting to think about content in terms of mapping it to a desktop-based frame in your mind, but it’s important to separate content and hierarchy from any single layout possibility. Now is the perfect time to embrace the web’s unpredictability as well as the mobile first line of thinking.

Research from Google (PDF) shows that 90 percent of people start a task using one device, then pick it up later on another device—most commonly, people start a task on smartphone, and then complete it on the desktop.

Karen Mcgrane’s thoughts on content parity and consistency nail it for me. In many cases, it seems as though over-engineering and over-thinking take the place of good ol’ fashioned editing and restraint.

On Design

When content and hierarchy are set, where to next? I still use Photoshop, but I use it differently. It’s no longer for prescribing exactly what a site should look like. Instead, it’s used for quick layout exploration and asset creation. As for which view/layout size one should start with, I don’t think it matters. Remember, a single photoshop comp will only express a sliver of the layout potential a fully-flexible responsive site has. It’s impossible to accurately assess a responsive layout in .JPG form.

That said, no one should feel like he/she has to drop photoshop or any other tool cold turkey. To me, it’s less about how I get there and more about ensuring that old habits aren’t triggering reversions in my perception or wasting time. I think browser-centric workflows and style guides are the future, but don’t be shy about casually assembling components in a .PSD for comprehensive evaluation if you want.

On Code

Whether it’s CSS for a single component or an entire site, I finish in a mobile-first fashion by using min-width media queries to set the smallest view and move outward from there. However, I start much differently. I begin with wide views because the layout is usually more complex. I find it easier to ensure columns and spacing are set wide and work my way down to a single column.

All my values are relative (em, rem, etc.) and based on the 100% 16px base, so I can move code around without losing proportion. As I continue to fidget with various layouts, I shuffle code for larger views down into alternate media queries as needed. I’m not saying this is the most efficient practice, but at the end of a project this somehow helps me feel like every view has been well considered, which is most important to me.

On Breakpoints

It’s good to plan, design, and test with all sorts of devices in mind, but it’s become standard to let media queried breakpoints be defined by content/layout rather than any specific device. Whenever things don’t fit or hierarchy breaks, add a media query. My favorite example of this is if we set a max-device-width media query at 480px to target an iPhone 4, the iPhone 5 wouldn’t display any of the targeted styles because the screen is larger. Fine-tuning breakpoints to the design rather than the device will make your responsive layout ready for just about any new device the market may throw at it.

On Grid Systems and Frameworks

One of the most important skills in RWD is the ability to control the layout (how content shifts and reflows at various widths). Grid systems can be extremely helpful, but I’d say it’s good to avoid counting on them too much. To me, using these tools in a drag & drop fashion takes the fun out of the process because the framework then determines the content choreography and not the designer.

Get help.

Most of our learning at Paravel has been through our mistakes. Whether it’s determining if a design might paint you into a corner when things begin to scale or how best to code a new feature out, getting help saves time and money. Don’t be afraid to reach out to teams with specialized experience, whether in the form of production work or introductory consulting.

Above all, the key is to not get frustrated if the process gets sloppy or less efficient than we’re accustomed to. While projects may take longer at first, the effort put forth to ensure that teams are headed in the right direction will pay off exponentially. And remember, it’s less about how we start than where we end up. The trick is simply to get going.

For additional tips, check out Chris Coyier’s Notes to an Agency Starting Their First Responsive Web Project.

Ads by Fusion

47 Responses

Leave a comment or contact me via Twitter @TrentWalton

  • Francesco

    In your experience, did you usually teach the client about using style guides instead of pixel perfect layout?

    If a client asks you to design a mockup (e.g. news website, where the homepage is plenty of different modules), how do you proceed with style guides?

    Great article, though. Very inspiring.

  • Brett Jankord

    Starting responsive projects is challenging. Designing for the anywhere, everywhere web is going to be more challenging than designing one fixed width layout. The ideas you talked about are good for those who maybe considering starting their first responsive project as well as those who have been building responsively for some time now. Bookmarked this to share with others as I start responsive projects. Thanks Trent!

  • Trent

    @Francesco: I think it’s a process. At Paravel, we weren’t able to make any of these transitions overnight, so we don’t expect anyone else to. To me, the process is mostly about relationships and clearly/patiently lending advice.

    If a client asks you to design a mockup (e.g. news website, where the homepage is plenty of different modules), how do you proceed with style guides?

    We’d do both, but the comps would be rough and come with continual reminders that getting to code is where the real tire-kicking begins.

  • Aaron Alexander

    The bit about design is spot-on. In my experience, designers focus on the desktop layout and then create tablet and phone comps -- in portrait only. As you’ve pointed out, in a truly responsive layout, breakpoints are rarely that confined and predictable. Unlike traditional web design workflows, development needs to accompany design in the very early stages of RWD. This has been the hardest concept (for me) to implement with agencies.

  • James Rice

    A nice read, Trent. A lot of it rang true for how we at Mudlark approached our recent redesign recently. I wrote about the process and how things have changed for us here: http://wearemudlark.com/blog/the-new-mudlark-website/

  • Cory

    The last few sites I have done the basic design for desktop is done first. But when it comes time to start coding, I start with the smallest mobile resolution first and scaled up from there. It really helped change my mentality when making a site, making the focus on whats most important first and the fluff later.

  • Joao

    Great post Trent, prepare to go viral :)

    Right now I work in a 20+ employees web studio, and we use Photoshop A LOT, and apparently nothing is gonna chance in the near future.

    Should I quit and start a small studio with my best designers friends?

    No need to answer, I´ll do that anyway...

  • Jon Bellah

    Brilliant, as always, Trent!

    Giving up pixel-perfect control was the hardest part of gettings tarted with RWD for me. Once I did, though, I was pretty amazed with all of the things that I could do.

  • Neil Bradley

    Brilliant article, as always Trent. Your site always makes it comfortable to read content about these subjects.

    I wondered at what stage of the project from initial client meetings do you decide on which devices and flavours to support? Do you decide on those breakpoints before even thinking about the design or do you look at that after you’ve come up with your creative direction?

  • Trent

    @James Rice: Good stuff!

    @Neil Bradley: Thank you:)

    I wondered at what stage of the project from initial client meetings do you decide on which devices and flavours to support? Do you decide on those breakpoints before even thinking about the design or do you look at that after you’ve come up with your creative direction?

    We set out to support all modern devices and try to only make concessions with progressive enhancement in mind. If a client raises specific concerns or targets during planning, we’ll reassure them and pay extra attention to any specific device if necessary. As for defining breakpoints, I think it’s most sensible (and fun) to let the design/content dictate them. There are too many devices to bother with targeting any specific one.

  • Andrew Sharman

    Thanks for a really interesting article. Alot of people talk about the break points in RWD. It seems to me that it’s where the point of compromise lies in a design, unless we target specific devices. So, I wonder if you could please tell me if you have ever, in all honesty, targeted a specfic mobile device with a responsive layout? Or is that just cheating?

  • Trent

    @Andrew Sharman: Thanks!

    I wonder if you could please tell me if you have ever, in all honesty, targeted a specfic mobile device with a responsive layout? Or is that just cheating?

    I wouldn’t want to build an entire layout targeting a particular device. Think about the recent change in screen size from iPhone 4 to 5. If we targeted 480px for iPhone 4, those styles wouldn’t apply to the 5. It’s maybe more of an unsafe bet than it is cheating.

    Also, I updated the post based on that question. It’s such a good & common one. Thanks!

  • Marc Carson

    Thanks for this writeup. What’s your RWD/non-RWD proportion at present? I was pretty gung-ho about everybody-gets-RWD-all-the-time until I worked on some RWD sites, and realized that for certain clients, it seemed to make sense to back off RWD a bit and look at marketing-type features. So now I feel a bit shy to admit it, but no, not everyone in my new sites pool is getting RWD.

  • Trent

    @Marc Carson: Thanks for the comment.

    What’s your RWD/non-RWD proportion at present?

    We’ve been exclusively responsive for almost 2 years. It’s what we find most exciting about web design right now, but even more than that, it seems the most responsible thing to deliver given the unpredictable future of the multi-device web. It may not be on a client’s radar now, so one thing you could do is build fluid-width (fully flexible) sites and cap the width with a min-width in the CSS. That way, if/when clients want to go responsive at a later time you’re halfway there.

  • John J. Locke

    Excellent article, Trent. The larger and more entrenched an agency is in its design workflow, the harder it will be for it to adjust to designing with unknown devices in mind.

    @Neil Bradley Not only should we design for known devices, but unknown future devices. The only way to do this is check for breakpoints on available devices and by resizing the browser all the way up and down. Who knows what phones, tablets, or other unknown screens your design will show up on in the future?

    @Francesco The design process is just as much about the clients adjusting as the design team. If they trust your team’s expertise and their results, they will be more open to what you have to say. Potential clients have no doubt researched the design process elsewhere before coming to you, or have been through it before, so they will not understand why things have to evolve at first. Communication and trust will always be the pillars of the design-client relationship, so listen with empathy, and explain the need for a new approach with confidence and understanding.

  • Trent

    @John J. Locke:

    Communication and trust will always be the pillars of the design-client relationship, so listen with empathy, and explain the need for a new approach with confidence and understanding.

    Love that.

  • Francesco

    @John J. Locke:

    so they will not understand why things have to evolve at first

    True. That’s a big challenge.

  • Evan Mullins

    These thoughts are much appreciated! Thanks Trent.

  • Darren Street

    I really like this site. You make allot of sense except one thing that I don’t get. This is probably because I am a British limey...but your name sounds like a shopping centre. No offence :)
    Bloody cool site though.

  • Trent

    @Darren Street: A shopping center? Dang. I thought it sounded more like a town;)

  • Tom Hermans

    Great article. Been advocating the use of full Photoshop mockups for longer than today, even if only to get rid of adjusting a color, stroke thickness or various elements in several comps.
    But with so many different screen sizes and RWD, the wireframing in HTML/CSS which evolve further into prototyping and eventually live, with Photoshop still for eye-candy or some asset design, development site-wide is much more easy, layout as a whole gets much easier with just some copy-paste you can re-arrange each and every fluid modular blocks. I’m not saying this is “the” flow, but if you know a bit of code and are past the point that each site has to look pixel-exact in each browser/platform and such.. you get testing from the beginning on each device and applying color and eye-candy brings a site really to live.
    I also experience a very different grasp on what a site should contain, how it should be accessed and a much more content-focused and less designing from outside-in approach.
    content > typography > layout > paint
    and with a RWD approach you really have to think about the first ones before “applying paint”

  • Chris Meeks

    Great post, Trent!

    There is one thing that often goes unsaid here. One huge barrier to more agencies adopting this type of workflow is that it isn’t easy to find good designers that can write a RWD front-end.

    In my experience, larger agencies still think of “creative” as separate from code and have hired that way. You can’t build a project in an environment that includes quick, iterative prototyping if you don’t have the people that can make design decisions in a browser. Or am I overstating that problem?

  • Emma Jones

    i new in responsive web design, still in a learning process. Great info though.
    Emma

  • Elina

    Hello Mr. Walton, thank you for sharing a really interesting article. Responsive design could be more beneficial if we target mobile devices, though it is not easy to find brilliant designers that can write a RWD for mobile devices.

  • Marc Bernier

    Great article. I like your process. In a dream world, Photoshop will “save as” a perfect responsive .css file. Probably Edge in a near future...
    One sure thing, photoshop mockups will be always important for the client.
    For me, the most hard phase is refreshing all browser on all device i test when developping...

    Thanks and keep doing good job!

  • Trent

    @Chris Meeks:

    You can’t build a project in an environment that includes quick, iterative prototyping if you don’t have the people that can make design decisions in a browser. Or am I overstating that problem?

    I don’t think you are. It took lots of effort for Paravel and there are only 3 people who’ve known each other for 15+ years. Generally, I think adapting involves personal skill-set changes as well as organizational changes.

  • Mike Torosian

    Trent, this article was very helpful. I do have a question in regards to reaching out to teams with experience, I too am part of a 3 person team, and I am eager to explore this, I would love to get critique and professional guidance, however, I am not sure who to reach out to, I have tried on Dribbble and Twitter with no success, any suggestions?

    Thank you.

  • Trent

    @Mike Torosian: I think it depends on what you’re hoping to achieve specifically. I’d start with setting aside for personal reading and experimentation with RWD and maybe a hack week internal project to facilitate further learning and discussion. I’d also consider attending some conferences that cover RWD and multi-device design. Something like: http://artifactconf.com or http://aneventapart.com

  • Trever Yarrish

    Thank you for the post Trent. Everything you wrote in this post resonates with me, and the section regarding grid systems and frameworks is something I have been going back and forth on quite a lot lately. My team leans pretty heavily on Zurb’s Foundation these days for quickly prototyping and creating MVPs for layouts. I then find that we sometimes box ourselves into the confinements of the framework as a result. We typically always create our own stylesheet in the production version to remove framework bloat and the redundant over-riding of styles.

    Questions: Do you guys utilize frameworks for prototyping speed? Do you practice any lean design MVP methods with your projects? I guess I am wondering what your teams initial approach is. We use the frameworks initially so we can get ideas in the browser as quickly as possible for feedback purposes, and at times feel like we are battling against the framework.

    Thank you much!

  • Julie Setbon

    @Trever Yarrish:
    Trever, have you used Foundation on any asp.net/mvc4 sites ?

  • Trent

    @Trever Yarrish: Hiya, Trever. We’ve not used any frameworks for prototyping aside from stuff we’ve developed over time internally. I definitely wouldn’t think it’s a bad thing unless you feel it’s preventing innovation or holding the team back from full comprehension for what responsive layouts could achieve. Most of our prototypes are tiny pieces of the site as opposed to full layouts. It’s not planned that way, but helps us quickly explore certain behaviors without investing too much in any one direction.

  • Bruno Mateus

    Thank you, Trent, it’s a magnificent article.
    I sometimes felt I was alone on some opinions, like building complex designs first and drilling down to mobile devices, or design with device-independence as a goal, instead of targeting devices (separate layouts for desktop, iPhones, iPads and Samsung Androids).
    Glad to see it was not so wrong at all! Please keep up the great work, I always learn something new reading your posts. Cheers.

  • Elliott

    Great article! I’m currently doing my portfolio, using the ‘mobile’ first approach. I really like the Bones theme approach and organisation! I have already learnt so many lessons in regards to RWD and I’m sure there are many more to come. Images and pointer events are where I feel the much needed help.
    Once again brilliant article, thanks!

  • Eric Rowan

    Hi Trent, thanks for the insight. I’m not new to RWD, but lately just getting started on a project has been daunting.

    Regarding grid systems and frameworks, what is your advice to someone who lacks the ambition, skill or timeframe to custom-build a system on a per-project basis? Is there a simple system Paravel uses (Foldy?) as a starting point for every project?

    Thanks!

  • Erik Holmberg

    Great insights as usual Trent. I use the same workflow at Fuzzco, copying styles from larger widths to smaller. It’s remarkably fast.

    The quickness with which you can knock out these width break points depends on good structure of your html up front as well as how easily your css rules can be reused.

    The point that stood out to me was that, even if your client doesn’t opt for responsive layouts, you should at least set the site up for it in the future. It will save you a lot of time down the line.

    There is a good chance in the future your client will either see the value of having a responsive layout, have the capital to add responsive layouts, or both.

  • Mike Torosian

    Trent, one thing I tend to struggle with is developing proposals for clients when it comes to RWD. I don’t know if you’d be comfortable with it, but have you considered a post on how your proposal process changed with RWD? How do you outline costs for your clients? Is a lot of it a bit of guesstimating with some padding built in to cover odds and ends? What do you do if a client needs an outline of cost up front? Do you have some insights you could share on that process? Thank you for your time.

  • Trent

    @Mike Torosian: We’re having the same struggles here. I find that because our work is less straightforward these days, jobs aren’t as easy to estimate. To balance that, we spend even more time upfront getting to know potential clients and asking questions. We’ve been tweaking this part of the process a bit lately, so I’ll report back soon if anything good comes of it.

  • Mike Torosian

    Well that does give me comfort to know that others are facing the same issues, I am looking forward to hearing how you tackle these obstacles. Thank you again.

  • Michael Johnson

    I love all over your articles and they continue to inspire me as a beginner in responsive web design, but you should consider using “-webkit-text-size-adjust: none;” so that your type hierarchy isn’t compromised on the iPhone’s landscape view. In landscape your h3’s and p’s are very similar in size. I only just discovered how to fix this the other day so I’m not totally sure if it has any drawbacks.

  • Trent

    @Michael Johnson: Well spotted. Thanks :) I just added: -webkit-text-size-adjust: 100%; and -ms-text-size-adjust: 100%;

  • Lelala

    Having a rise of 10 - 15% in mobile traffic shows where the trend is going; you have to go where “the puck will be”, not where the puck currently is :-)

  • Vinacle

    Very Interesting Article!!
    Ideas you discussed are very nice for those who want to learn responsive webpages. Responsive workflows is not similiar to Traditional web design because we have to think about RWD approach in initial stages.
    Thanks you Trent and keep sharing such helpful posts!

  • Leroy Fernandes

    Hey Trent, I didn’t quite grasp what you meant by “Fine-tuning breakpoints to the design rather than the device will make your responsive layout ready for just about any new device the market may throw at it.“
    Could you explain a bit more or with an example?
    Good article though. It is always interesting to read tried and tested methods. Thank you for sharing your knowledge.

  • Trent

    @Leroy Fernandes: Another way of putting it would be that I base media query breakpoints on the design and the content rather than on any given device. So, instead of something like 320px for a phone, the breakpoint would be based on when a layout gets cramped or needs to be shifted. Does that help?

  • Jess

    I think simple and responsive is best for most web sites.

  • Theo

    “No amount of design or code can adequately fix content problems.” - Love this quote... You help the client with the content get the site running and that’s it. As you leave, no more ongoing maintenance of content in most cases.

    Thanks for this great article!

  • Tom

    Responsive desgin is no.1 now. Thank you, great article.

Leave a Reply