A Gov Supreme

I’ve been doing some workshopping and consultancy at a few different companies recently, mostly about responsive design. I can’t help but feel a little bad about it because, while I think they’re expecting to get a day of CSS, HTML, and JavaScript, what they actually get is the uncomfortable truth that responsive design changes everything …changes that start long before the front-end development phase.

I explain the ramifications of responsive design, hammer on about progressive enhancement like a broken record, extoll the virtues of a content-first approach, exhort them to read A Dao of Web Design, and let them know that, oh, by the way, your entire way of working will probably have to change.

Y’see, it’s my experience that the biggest challenges of responsive design (which, let’s face it, now means web design) are not technology problems. Sure, we’ve got some wicked problems when dealing with non-flexible media like bitmap images, which fight against the flexible nature of the web, but thanks to the work of some very smart and talented people, even those kinds of issues are manageable.

No, the biggest challenges, in my experience, are to do with people. Specifically, the way that people work together.

Old waterfallesque processes where visual designers work entirely in Photoshop before throwing PSDs over the wall to developers just don’t cut it any more. Old QA testing processes that demanded visual consistency across all browsers and platforms are just ludicrous.

The thing is …those old processes were never any good. We fooled ourselves into thinking they worked, but that was only because we were working from some unfounded assumption: that everyone is on broadband, that everyone has a nice big screen, that everyone has a certain level of JavaScript capability. The explosion in diversity of mobile devices (and with it, the rise of responsive design) has shone a light on those assumptions and exposed those old processes for the façades that they always were.

When I’m doing a workshop and I tell that to designers, developers, and project managers, they often respond by going through the five stages of grief. Denial, anger, bargaining, depression …I try to work with them through those reactions until they ultimately get to acceptance.

Somewhere between the “bargaining” and “depression” phase, somebody inevitably passes the buck further up the chain:

“Oh, we’d love to do what you’re saying, but our clients would never go for it.” Or “You’ve convinced me but there’s no way our boss will ever agree to this.”

I’ve got to be honest: sometimes I think we use “the client” and “the boss” as a crutch. I’m also somewhat bemused when people ask me for advice to help them convince their client or their boss. I don’t know your boss—how could I possibly offer any relevant advice?

Still, I’ve written about this question of “How do I convince…?” before:

Something I’ve found useful in the past is the ability to point at trailblazers and say “like that!” Selling the idea of web standards became a whole lot easier after Doug redesigned Wired and Mike redesigned ESPN. It’s a similar situation with responsive design: clients are a lot more receptive to the idea now that The Boston Globe site is live.

When it comes to responsive design, there’s one site that should thoroughly shame anyone who claims that they can’t convince their boss to do the right thing: GOV dot UK.

It’s responsive. It puts user needs first. It’s beautiful. It even won the Design Museum’s design of the year, for crying out loud.

This isn’t some flashy lifestyle business. This isn’t some plucky young disruptive startup. This is the British government, an organisation so stodgy and bureaucratic that there are multiple sitcoms about its stodginess and bureaucracy.

Gov.uk is an inspiration. If the slowest-moving organisation in the country can turn itself around, embrace a whole new way of working, and produce a beautiful, usable, responsive site, then the rest of us really have no excuse.

Have you published a response to this? :



This morning, Mark Boulton wondered aloud on Twitter about why responsive design “looks” like responsive design:

I wonder if #RWD looks the way it does because so many projects aren’t being run by designers, but by front-end dev teams.

This certainly isn’t the first time that someone has suggested that responsive sites have a “look” to them. In fact, it seems that particular topic has been quite popular over the last few years. And to be fair, a pretty large number of responsive sites do tend to share similar aesthetics.

Before I dig into that, let me state my usual “blame the implementation, not the technique” just in case anyone was considering insinuating that responsive design dictates a specific sort of visual appearance. (To be clear: I don’t think that’s what Mark was doing at all—I’m just preemptively dismissing that line of commentary because it’s almost certainly going to come up.)

There are a few reasons why I think we’re seeing this commonality at the moment.

The web can be trendy

Let’s be honest with ourselves: we web folk can be a little trendy. We do this with specific technologies and tools, and we also do this with visual design. There has long been a tendency for people to mimic whatever the recent definition of “beautiful” online is (grunge, “web 2.0”, “flat design”, etc). Any glance through the once massively popular CSS/design galleries will attest to that.

We’re still getting comfortable

Responsive design is still relatively young. With all the articles and presentations about it, it’s easy to forget that. You don’t have to look far though to find companies that are just starting to dip their toes into it for the first or maybe the second time.

Understandably, people will lean on established patterns (or frameworks like Foundation or Bootstrap) to provide a level of comfort as they’re working things out. Eventually as people get more comfortable with how to approach multi-device projects, their reliance on these patterns will lessen and they’ll start to experiment more.

Silo’s and waterfalls are still the norm

Kevin Tamura responded to Mark’s comment on Twitter suggesting our workflow may be to blame:

@markboulton @Malarkey I think it’s an over reliance on the waterfall methodology for projects.

The more multi-device work you do, the more you discover that the toughest problems to be solved aren’t related to technology. The toughest problems are related to people, process, workflow and politics.

You can see this reflected both in projects led primarily by folks more comfortable with development (which may exhibit many of the traits that Mark was noticing) as well as projects led primarily by folks more comfortable with visual design (which may buck the trend a bit, but often at the cost of performance and reach).

Transitioning from the traditional waterfall/siloed approach to a fluid process where designers and developers are working more closely together can be a very difficult adjustment. Not only do you have to battle the internal politics involved in such a move, but you have to experiment to find the right comfort level. Until organizations make that transition it’s natural for things to be off-balance a little bit.

The good news is that the transition can be made—and a lot of folks are sharing how they’re handling it. Eventually those walls between roles will break down. When they do, that healthier process based on collaboration will lead to more creativity and experimentation in design and that’s when this stuff will get really fun.

Thanks to Dan Mall for giving the article a read-through to ensure I wasn’t entirely off-base. (If I am, feel free to blame Dan.)