These are my notes, conclusions and thoughts from yesterday’s Responsive Summit in London.

Last week, Alex Morris – UX Director at Mark Boulton Design, Chris Armstrong, Designer from Front, the company responsible for Typecast, and Josh Brewer, Principle Designer at Twitter, were discussing the idea that – whilst Josh is in the UK – we should all get together and have a chat about Responsive Web Design; the problems we share, the tools and solutions we’re individually developing, and how we can collectively we can get a better understanding of what RWD means for us and our daily business.

Yesterday, the ‘Responsive Summit’ took place in Microsoft’s offices in London. And huge thanks must go to Martin Beeby from Microsoft for not only providing the room and also the tea, coffee and lunch. Oh, and cake.

In attendance were:

In Person

On Skype

Ahead of yesterday I was a little sceptical as to the format and the practical value from getting 25 people in a room and have them discuss Responsive Web Design. I thought it’d be a bit of a bun fight. But, actually, that couldn’t be much further from the truth. The people who attended represented a broad range of websites, products, agencies and clients. We had people representing websites and products that have issues of massive scale: the BBC and Twitter. Through to individual freelancers working on site designs and builds for primary schools. The range of considerations on the table was therefore also as broad.

Last week when Chris, Alex and Josh decided on trying to make this happen this week, they had the brainwave of putting a form up on a website to gather questions, concerns or comments from the community. We had a hundred responses or so. All of these were broadly grouped around the following topics:

  1. Workflow
  2. Layout
  3. Sensors
  4. Images
  5. Advertising

This first blog post of mine is just about the first point. Specifically, these are my thoughts based on the discussions not necessarily the consensus of the day.

Workflow

We broadly agreed that from our experience, Responsive Web Design affects workflow considerably. Speaking personally, Mark Boulton Design have been building all our projects responsively for the past 18 months – typically HTML/CSS templates for handover to clients or development partners. And it affects workflow a lot. Here’s what we used to do:

  1. Create planning and design artifacts: site maps, wireframes, user flows and journeys, scenarios etc. All of these were up for revision and change by the client.
  2. Create flat Photoshop comps based on those artifacts, but only when they were signed off. Oh, and typically that would tally with a billing point.
  3. Build templates from signed off comps.

Typically waterfall process. This doesn’t work well for us with Responsive Design. For the past few years, we’ve been working the following way, but only in the last 18 months or so has it become increasingly crystal clear for me that there has to be a structure of project flexibility to accommodate the inherent fluid nature of RWD.

  1. Sketch. Get the ideas down *amongst* the requirements. Meaning, we don’t have design specification documents, we dont have lengthy requirements documentation. We have user stories (or something similar) and we combine them with research, thoughts, sketches, ideas to document the scope of the project.
  2. Prototype. In HTML. This allows us to get the product – in whatever form – in front of the client. The aim is to remove The Big Reveal. It also lets them see how the site responds on different screen sizes. Also, we can start to think about problems that may arise due to a responsive approach *now* instead of when the templates are being integrated into a backend, or at other production sensitive times.
  3. Design. However you increase the fidelity is up to you. I use Photoshop, other people use Fireworks, some do it in a browser.
  4. Iterate. Have a project structure that embraces change. That means a focus on priorities.
  5. Talk. This approach requires much more collaboration with a client. I mentioned The Big Reveal: the thing designers do where they squirrel away for a few days and then come back and go ‘ta da, look what I made!’. That’s just so risky.

Some of you will think I just described an Agile process – and partly that’s right. There are some things from Agile that are useful for us when designing Responsive sites: prototyping working code, iterating based on priorities, increasing the fidelity of your design work in the browser instead of comps.*

* Note: I’m not saying design in the browser. I’m saying increase the fideltiy, or apply a design system, not do it all in there.

Yesterday, we discussed similar issues around this process. How, in large agencies which are crippled by siloing of design and front-end development resources and their own immovable processes, are finding it very difficult to work with RWD. It’s not because RWD is difficult, appropriate for a project or anything else. It’s because their process can’t accommodate it.

One of the issues is to do with the delivery of design ‘comps’ to a client. The old way was easy: we do wireframes, we make comps from those wireframes, clients sees them, signs them off, we build it. We can’t do that now because we’d be delivering comps for every viewport size. We can’t do that. More the point: we shouldn’t do that. This is when RWD comes under criticism for not being commercially viable. It’s because it’s trying to be shoe-horned into an existing, fixed-canvas, inflexible process.

The take-aways for me, based on yesterday’s discussions, were that we’re on the right track. Prototyping in HTML early, showing and involving clients in the process early – so they can see how a site will respond to different viewports – actually showing them in different devices helps mitigate the ‘The Big Reveal’ and the associated risk. It helps clients understand – and this was a great point made by Cennydd – that RWD is sustainable design and a cost effective, future-compatible, approach to building websites for an ever-increasing myriad of display sizes.

The next part of the day was to discuss Layout. But, I’ll leave that for the next blog post.