How to develop a responsive workflow

Remember the good old days? You know which days I’m talking about; the days not so long ago when we used to design websites to fixed widths. Looking back now they seem like such a simpler time; a happier time; a time when I could recite every font that was available to use online without a second thought. The truth is that Responsive Web Design changed everything. The world was flat and now it’s round, I was blind and now I see, the web was pixels and now it’s percentages.

With the introduction of RWD, it is vital that we as designers evolve our workflow to better suit the demands of the new web. Many of us have voiced our frustrations on how Photoshop’s fixed pixel approach is unsuitable for designing the fluid layouts needed for a responsive website but no useful alternatives have been offered. The web design world is desperate for a bespoke software that is built from the ground up with RWD in mind. Products like Adobe Reflow are a great start, as it shows that Adobe are at least working on a solution, but after spending a few hours with it at the weekend, I can see that it still has a long way to go before it becomes a useful addition to my workflow. With us being in limbo between a pre-historic software and the promise of what’s to come tomorrow, we are having to create alternative workflows to accommodate the shortcomings of our current ‘design software’ by introducing other tools and procedures that will help bridge the gap between fixed pixel and fluid responsiveness.

The following is by no means a list of how RWD projects should be approached, but rather how I have adapted my workflow to suit the new landscape.

 

1. Use what you know

I have stood on the border between the Photoshop/Fireworks/Illustrator divide as each have battled for supremacy and have witnessed innocent people get caught in a crossfire of pixels. Designers tend to have their favourite and would rather die a slow painful death than admit that another software has a feature that they might actually want. My view is that you should design in any software that allows you to work at your most efficient and explore your ideas quickly, be it Photoshop, Powerpoint or Paint.

It’s almost irrelevant which you choose as it should just be a starting point for quickly experimenting with different layouts. Personally, I prefer Fireworks as it ticks more of the boxes of what I want in a software. I try not to get heavily stuck into details at this stage and really try to just make some preliminary decisions on layout and structure much like some posh wireframes.

 

2. Use real content

Everything that needs to be said about the use of Lorem Ipsum in site mock ups has been said so please just trust me on this one and where possible use real content to design from. Where not possible, use last years content, write your own content or use the lyrics to ‘Candle in the wind’ but don’t use Lorem ipsum. If you don’t use real content, it will be difficult to see at which break points certain elements need adjusting.

 

3. Start at 1000px wide

This is just the width that I like to start at as it is close to a small desktop experience, which is then easy to scale up for larger screens and down for tablet / mobile experiences. Some people prefer to start wider whilst others prefer to design mobile-first, it just comes down to what works for you.

 

4. Play the percentages

RWD is all about fluid containers that grow and shrink to fill the browser’s available area, so designing in percentages rather than pixels will ensure that your designs flow in proportion to the browser and require less break points than the equivalent pixel based design.

I tend to have In-Design open in the background so I can easily and quickly find out a percentage size of a pixel based element. InDesign is great at handling these kind of calculations and you can easily find out what size a 428px x 333px element will be at 46% of its original width, whilst keeping it’s proportions or maybe find out 27% of a 889px browser width in seconds. The results are still given to you in pixels so you can then go back into the software that you are designing in and create that container in pixels, knowing that it will be relative to the percentage of the workspace that you have defined.

 

5. Create your typography styles in the browser

If you think I bang on about using real content within your designs, you should hear me go on about designing typography styles in Photoshop (or equivalent). Typography will look vastly different in the browser than it looks in the usual Adobe packages which will mean more work for you tweaking the design once it’s built.

Save yourself the headache and use apps like typecast.com to experiment and create your font styles with. Once you are happy with the layout and style of your typography, you can export your entire workspace as a transparent PNG to place within your design mock-ups. You won’t need to have any of your chosen fonts installed onto your system as it will just be an image but you will also not be able to edit it without going back into typecast.

 

6. Create your grid

By now you should pretty much have your design at 1000px wide (or whichever width you chose at the start) completed with the widths of the containers that hold your various content translated into percentages. I would now start to create a bespoke grid that mimics the container widths that I use within my design. So if I have a sidebar that is 30% wide and a content area that is 55% of my browser with 5% padding either side, my grid may look something like 5%, 30%, 5%, 55%, 5%.

You can use apps like Gridset to build your bespoke grid but again, I prefer to use InDesign as you can group elements and have them resize in proportion to each other.

 

7. Time to break it down

I now take my grid that I have created using InDesign and paste it into a 1600px wide (or the max width that you want your site to be) document. I then start to resize my grid wider and narrower by increments of 100px all the way down to 300px wide. At every increment, I check the width of each content container and make sure it is still large enough to house its content. When I get to a width that I think makes a container too small, I simply edit the grid to fit. So if at 800px wide the sidebar that I had created at 30% of the browser width becomes too narrow, I could add an extra 10% to it, making it now 40% of my browser width and being wide enough to house its intended content.

The key thing to remember is that if you make a container wider, you need to make another container narrower by the same amount to maintain the 100% entire width. This is the best way that I have found to define break points (the point at which your layout will change) as you only add another breakpoint when the content breaks and not to the width of a new device. This procedure can be time consuming as you will end up with 14 different previews of your grid as it grows from 300px to 1600px wide but it is the best way that I have found to check how your design will look at different screen widths before it’s in development.

Another option is to use a tool like Adobe Reflow that also allows you to add content to containers and then drag your workspace and see the elements scale. You can also determine your break points by resizing your workspace until the content breaks and simply adding a media query. Reflow is still in public Beta and can be downloaded from here.

 

8. Add some polish

Having scaled your designs down at increments of every 100px, you would of identified a few widths at which the content breaks and rectified it by adding a breakpoint. You can now go back into the software which you created the original designs in and change the layout of your design at the widths that you identified as break points. This means that you end up designing only 2, 3 or 4 different layouts (depending on the complexity of your grid and how many breakpoints you need) that will cover all the way from 300px to 1600px.

 

9. Deliverables

If you have followed this process, you should now have a set of layouts that match your break points, a document that shows how your grid is made up of percentages of the browser width and how it collapses for smaller screens as well as all of your typography styles already created and tested in the browser. This should be a very strong point for a developer to then start building your designs accurately and without having to deal with content breaking at certain widths later on.

This process may seem very long winded but without a specific tool built entirely for RWD, it is the best way that I have found to easily test my responsive layout using non-responsive software and clearly communicate my ideas to a developer. This is by no means the one and only way to approach a RWD project, but it’s the best I’ve found.

What has responsive design changed about your workflow? What tips would you share? Let us know in the comments.

Featured image/thumbnail, flow image via Shutterstock.

  • Hemanth Malli

    Another great post .. Good points !! For creating good responsive design, we need to ..
    think in terms of grids that become a linear column when the site gets small. That will be a good mobile experience for users.

  • http://www.littlesparkvt.com/ LittleSparkVT

    Great Post. I’m happy that you covered something as important as workflow as it’s a bit different than traditional web development. Thanks for this!

  • Gary Hicks

    Great points, but why 1000px and not 960px (based on the popular 960grid)?

    • http://twitter.com/nomescriba Nick

      I’m just a student so in my case i design on ps or ai on a 1024 grid and set my a min-width of 1024px or 980 so that landscape ipad and desktop are the same but then changes on ipad portrait… i think the 1000px pretty much covers even the smaller mac airs and depending how you want it it goes up to the big imacs…

  • James Eggers

    I too question 1000px. While 1024px used to be the standard monitor size, the average teeters between 1280 and 1440px wide depending on the reports you read. Constraining a large screen design to that will provide very large side margins and a lot of lost opportunity. Sure many tablets have a height or width of 1024px but if the traffic patterns still show a dominating amount of traffic from desktop, you’re doing a disservice to your visitors by following the recommended practices from 3-5 years ago.

    From my own responsive workflow experiences, starting small and working up has yielded designs that are significantly richer and cleaner – for ecommerce and B2B sites in addition to traditional blogs and brochure sites.

  • https://aratech.ae/ Necolas Hamwi

    I used to work with: 960grid for years. But then shifted to Bootstrap, after working with Bootstrap for a while, i’m starting to feel the that 960grid was better, and lighter on the browser, specially it’s custom CSS generator: http://grids.heroku.com/ It gives unlimited freedom to define your grids! Even make it 1020px (my liking).
    We ended up using a combination of Bootstrap (for JS stuff) and 960grid on our website: https://aratech.ae

  • http://twitter.com/NeoMudaly Neo Mudaly

    Really emphasizes the shortcomings of PShop when it comes to designing responsive layouts, doesn’t it? There’s a real opening here for Adobe to create ONE graphic design product specifically for web designers. I personally, don’t need a product that is going to write code for me as in Reflow or an entire suite of products to achieve my goal of designing a responsive web interface.

    • Wizfactory

      I too feel a need for a specific design software for web designers only. Adobe really needs to work on this.

  • Lobster Coupons

    Great Post. I’m happy that you covered something as important as workflow as it’s a bit different than traditional web development.Really emphasizes the shortcomings of PShop when it comes to designing responsive layouts, doesn’t it? Thanks for this!

    long beach web design

  • Diana Parker

    Great !!! all the points are so good and beneficial for the developers. I really appreciate your work and in future i definitely read your blog. I am also a software developer so your blog is really helpful for me.