Making ubuntu.com responsive: scoping the work (6)

This post is part of the series ‘Making ubuntu.com responsive‘.

Following the designers and developers sprint, we had a full web team workshop day to discuss our findings and plan the work for the following weeks.

Planning and scoping was tricky because we had to balance the work required to make the site responsive with incoming work requests from the business — there was a big release of Ubuntu coming up and lots of content updates along with it.

We carried out a few team exercises that helped us to deconstruct the project into smaller chunks that we could prioritise and plan around other commitments, so that it didn’t feel like building the Titanic but rather something more manageable.

Creating a wishlist

Initially, it’s good to have an idea of what each person considers important for the project.

The simplest way to capture everything you want to do in a project is to write all ideas on separate sticky notes. This approach helps to identify common themes and priority tasks.

This is a good opportunity to get the entire team together in a room and give everyone space to say what they hope to achieve in the near, and not so near, future.

At the end, though, it’s only natural that you’ll be left with a huge amount of ideas, so it’s necessary to organise them into groups, like projects or topics.

Dividing work into phases

Following the wishlist exercise, and based on the resources and time available, fixed deadlines, and business goals, the list was trimmed down into four time frames:

• To be completed before the Ubuntu 14.04 LTS release
• To be completed for the release
• To be completed soon after release
• To be completed later

If you have hard deadlines for other projects that are in your team’s plate, start adding those into a calendar overview (we used four sticky notes columns) and discuss what can be done within the time that is left available.

For example, we knew that, in preparation for Ubuntu’s presence at the Mobile World Congress at the end of February, the content of the tablet and phone sections of the website would have to be updated ahead of any responsive work going live.

Defining high priority tasks

In terms of the responsive project itself, we defined the priority tasks:

• Update our CSS with the components that had been created for the two initial responsive projects and that would be useful across our sites
• Find an initial solution for main, second and third level navigation, and multiple footers
• Create updated image assets where necessary

And we also defined what we wouldn’t do at this stage:

• Rewrite copy
• Restructure and reorder content
• Change the information architecture of the site
• Update the site’s visual style

It was important to have these restrictions in place in order to keep the scope of the project as small and as feasible as possible. Most times, it’s impossible to do everything you wanted in the first instance of moving to responsive, so deciding what would be the biggest wins for the amount of time you have available is an important step in planning the work.

At the end of the workshop, we all felt more comfortable with the amount of work ahead: following a few simple exercises, we had identified pain points, set realistic goals and expectations, and established priorities.

Content risk assessment

Matt went through all the pages of the site to assess what, in terms of the design, could become an issue once the site was responsive and once the content had to fit into small screens. These findings were added to a document divided into five different types of content:

• Images
• Graphs
• Tables
• Layout and behaviour
• Text

With this document we could see how much work we potentially would have when transitioning all the pages of the site to the updated responsive styles, and which would be the trickier problems to solve.

Estimating time

With the content inventory at hand, Ant estimated the degree of difficulty of converting each page for responsive, using a scale of 1 to 3. He then estimated how many ‘points’ he should be able to get done in one day, which left us with an estimated time of completion of the first pass at fixing rendering issues.

Something to bear in mind when estimating times is that, while fixing the rendering issues that came with converting all the pages of the site to the responsive styles proved faster than initially estimated, the testing across different devices and screen sizes that followed was time-consuming for both designers and developers.

The complexity of testing and how long you should allow for it will depend on the site’s design and the CSS being used: for example, when using newer techniques you should allow for enough time to create suitable fallbacks for browsers with fewer capabilities. Another thing to keep in mind is that testing across devices should be done as you go, rather than at the very end of the process. Just a quick look at a couple of different devices and browsers (for example, previous Android versions and Opera Mini) before you start the estimation process will you give you clearer idea of the amount of work that lies ahead.

Even though our time estimates were a little off, creating those spreadsheets and dividing the work into very small blocks made us feel more in control, and, as we ticked pages off, it made us feel motivated.

Conclusion

When you’re working on a large living and breathing website, you know that all the updates and changes that come along with it don’t stop just because you want to make your site responsive. It’s important that everyone involved understands that you should be putting your website first, and that responsive is not necessarily the top priority. That’s why it’s important to be smart about the way you plan the project and give yourself some parameters to work within — the transition isn’t going to happen overnight.

Read the next post in this series: “Making ubuntu.com responsive: approach to content”