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.