Responsive website design from a project managers view point

Today I’m looking at the challenges and rewards of responsive design but only from a project management stand point. There are many articles on the web about responsive and adaptive design, do not get the two terms mixed up as they are different, but for this blog I’ll assume you know what these are.

I’ll start where all good project managers should start and that’s during the pitch. Responsive design isn’t really a new thing, it’s recently come into our conversations due to the recent releases of a myriad of devices and screen sizes that can be anything from 320px wide to a whopping 4480px wide and the poor tired desktop size design of 1024px just isn’t cutting the mustard when it comes to users requirements. Being a recent shift in expectations there are many people out there who are using the terms but not fully understanding them, so I believe it’s the PM’s job to make sure the pitch documents that are sent out not only have the right terms, but also the right costs and assumptions for the challenges of a responsive design.

You’ve won the pitch and your in the discovery phase, this is the time to make sure that what was proposed to the client in the pitch is fully understood, make sure their expectations are managed by explaining which screen sizes the design will be targeting, which browsers it will be tested on, the number of designed screens for each breakpoint and what hardware they will need to use for their UAT. Now you might not know all of that at the start of discovery but you should know by the end and if it does change from what was pitched then, make sure the client understands the changes, document them and if required provide an updated estimate.




We’ve discovered all that we are to discover (For now) and your UX/IA is about to start. Make sure they are aware of the requirements, as a basic benchmark lets say we’ve agreed 10 desktop wireframes, 3 at mobile size (maybe iPhone 4s), 3 at tablet size (iPad2 still seems to dominate) and 3 at widescreen (for arguments sake lets say discovery found out that the biggest they needed was 1600px wide). During your IA work I would advise that your designer and lead front end developer(s) are inputting in to the IA stage, it’s crucial that you get their approval and buy in and note functionality that might take you over your budget and make sure during your presentations this is clearly explained to your client. Make sure your IA also think about and show the following on all devices

  • How the navigation works
  • What happens to any megnav
  • Download speeds
  • How things work with Javascript switched off.


IA/UX is done and all signed off with the client, you’ve updated the estimates (I know it’s not that easy but I’m living in blog world) and you hand the plans over to your designer. At this stage it’s very easy to leave them to it but, again I advise that you have regular show and tells from your designer to you, your IA and your developers, I’ve seen things added in by the designer that may not be that easy to do on a responsive site, if you’re lucky your designer will have designed a fair few responsive sites by now but don’t assume. Make sure that your designer has shown the designs in the devices they will work on, so that when it comes to presentation your client will understand exactly how much information fits on each screen size. One other tip I’ll share here is to make sure you know and if possible can show how the site will flex between breakpoints, this will help make sure the responsive site works on other screen sizes.


Again we are in blog world and the presentation goes well and other than a few amends it’s all signed off and your developers are chomping at the bit to start, hold them back, get them to look at each page, each template and each breakpoint and to time estimate the work (in an ideal world you should have done this before sign off). This will give you two things, a realistic view of the costs against the budget and the time against the project plan and it’s at this point you should be speaking to your client if either or both or more than expected, don’t leave it until after you’re in QA. Once all of that is done you can let them start creating your responsive website. Having run a fair few of these projects I can tell you that you can easily underestimate the amount of work needed, although a responsive site will be cheaper than 4 different device specific websites you are still doing 4 times the presentations of the same data

QA and UAT

The extra work for a responsive site QA is probably the most increased, think about it for a while, traditionally we’d design the 8 desktop pages and we’d check it in let’s say the top 5 browsers, all in all you are checking 5×8 (40) pages but in a responsive build you are checking 8 pages on 4 devices (6 if you count portraite and landscape views) and a combined total of 7 browers you’re soon looking at something like this

  • Desktop = 8 pages x 5 browsers = 40 pages
  • Widescreen = 8 pages x 5 browsers = 40 pages
  • iPhone 8 pages x 2 browsers x 2 orientations = 32 pages
  • iPad 8 pages x 2 browsers x 2 orientations = 32 page

This brings us to a total of 144 pages to check, thats getting close to 4 times the amount for a standard desktop build and that’s without looking at all of the other devices out there using even more browsers.


My last exercise above is something you should be looking at at each stage of your build, work out how much extra effort you’ll need to put in for each stage, how much longer meetings and presentations will be and also the number of internal and client meetings required, the extra feedback and amends that’ll come back and do allow for more post launch amends. All of these and more could blow your budget and delivery date so plan it out carefully. All that said a responsive site should look and function beautiful and be a great showcase for any business and investing in a responsive or adaptive site design would be a good investment and to flip that around to not design a responsive site during your next refresh is simply not an option.