How we’ve been tackling Responsive Design

How we’ve been tackling Responsive Design

 

 

 

 

 

 

 

 

 

 

We have been re-considering our design and build process to deliver responsive design (e.g. The Boston Globe).

I thought we’d share what we have learned so far.  And in case you’re a client and wondering what’s point of all this? We deliver responsive design as standard not an expensive add-on.

The first thing that we concluded was that we could no longer follow the same process that we have been using to build sites for years. It just wasn’t practical to create PhotoShop templates for all of the permutation in screen resolution.  In fact it was a time-disaster!

We were in a situation where because we didn’t design everything our developers having to interpret the design into HTML/CSS and making a lot of design decisions ‘on the fly’.

They were considering questions like:

  • How does the navigation respond to smaller screens?
  • How should the layout adjust for smaller-sized devices?
  • What is the hierarchy of the content?
  • What are break points?
  • How important are those images compared to the text?
  • What exactly is the copy going to be? How important is it? (Especially true for CMS sites where copy isn’t often provided).

Now our developers are very good – I would say that (!) – but they were having trouble making the correct decisions related to these questions because they didn’t have all the information to hand.

How could they? They didn’t know the full complexity of UX strategy; what the client thought was a priority; what users wanted and what was in the designers mind when the site was conceived.

So to get around this we first started doing two types or wireframes and designs: desktop and mobile. This sort of solved the problem of what happens at the ends of the spectrum, but it wasn’t solving what happens in between.

One solution that we proposed – and shot down instantly – was extending the number of designs and wireframes to remove ambiguity. That was a recipe for expense and pricing us out of the market. Somebody worked out that it would be a minimum of 35 designs per site.

So we settled on this as a process:

  • Create the Visual and UX Concept
  • Set out the UX principles
  • Build Un-styled templates
  • Test
  • Layer in design to the templates
  • Test
  • Integrate

Create the Concept

The Visual and UX concept is the idea that we present to the client. It brings to life the site’s creative direction and the experience that we are trying to create. In other words, how we want to make the user to feel and doing so we are setting out the high-level UX strategy.  This is what the client signs off first.

Define the UX principles

That lets us create the UX principles for the spectrum of screen sizes that starts to answer those horrid questions….

  • How does the navigation respond to smaller screens?
  • How should the layout adjust for smaller-sized devices?
  • What is the hierarchy of the content?
  • What are break points?
  • How important are those images compared to the text?
  • What exactly is the copy going to be? How important is it? (Especially true for CMS sites where copy isn’t often provided).
  • What navigation is hidden?
  • What content is hidden on smaller screen because user requirements are different?

It was never going to be a complete document covering all eventualities, but it does give our developers a strong start point to develop the un-styled templates.

At first we kept on calling these un-styled templates prototypes because they felt like they were. But they weren’t! They working code that we re-used in the finished product. They were black and white pages that demonstrated exactly how the site would respond on different devices and resolutions. It was an un-designed site.

The steps between UX principles, un-styled templates and testing aren’t linear ones. It proved to be a conversation loop where new questions were asked (by the developers mainly) and answered (by the UX and Design leads and account management).

The up-shot being something that – when reviewed with the Visual and UX concept alongside – could be signed off by a client post user testing (essential and task driven) and review.

Layer in visual design

The next step was then to layer in the visual design elements of the site on to the templates to create the final HTML (either ready for integration if a CMS site or for content entry if a flat HTML site). Like the steps above this involved close and iterative collaboration between the design lead and the developer – there was no substitute for conversation.

Conclusion

This may not be where we end up, but it is where we are now.  If you gain nothing more from this article, remember don’t be afraid to try new things.

Process is a sometimes and substitute for common sense and collaboration. Most of all if the ideas above don’t fit the project, scrap them and try others.

We found that we had to evolve our design process to account for the evolution of the web and users. If we hoped to solve new problems – and be relevant – we were going to need a new approach.

As you see the key issue to address is communication. Earlier and more frequent collaboration among team members and the client have paramount – as evidenced by the conversation I can hear now in the background between a designer and developer.

That all said, Responsive Design isn’t the solution to multi-screen compatibility. It is just one tool available to us all.

0 Comments

Leave a reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

display:none;