Responsive Interview with Harry Roberts

We’re back with another interview series. Each week we ask our interviewee’s the same four questions that everyone else gets, except there’s an added twist where we let the last interviewee ask two new questions for the next interviewee.

This week we’re joined by CSS Wizardy expert Harry Roberts. Lets see what he has to say.


For those readers that might not know who you are can you give us a bit of an overview as to who you are and what you do?

Hello! I’m Harry, I’m a Consultant Front-end Architect from the UK.

I started consulting back in November of 2013, and it’s been an absolute blast. I work with a variety of clients in different countries, helping them to get a handle on their front-ends, helping them scale codebases, helping them map out projections for UIs, tools and products’ front-ends, as well just offer a helping hand and hands-on training. As well as that, I do quite a lot of workshops and conference talks.

Before that, for almost three years, I worked as a Senior Developer at BSkyB, one of the UK’s largest companies. I was in charge of their front-ends across several products, and I led efforts there to scale, standardise, and share our front-ends in a much better fashion. It was here that I really started focusing on front-end performance, CSS architecture, scalability, pragmatism, and product-led development.

Before that, I worked at a string of different types of digital agencies in the north of England.

What was the best implementation of responsive web design you’ve seen in 2013 and why?

The Guardian’s new site is unreal. Not only does it look lovely, you can really see that they took a very pragmatic approach, kept things simple, and have really pared things back to the bare minimum. This—I am speculating—should allow them to focus on their core, making sure they focus on the right things at the right time, meaning the product itself has a very clear scope, but it also should allow them to evolve and grow the product as and when they see fit.

I genuinely believe a lot of people are too ambitious when it comes to RWD, trying to do too much funky, crazy stuff, that ultimately leads to spaghetti code and an unmaintainable codebase. I think that, by the looks of things, The Guardian team have taken a much more sensible approach, and still have a site that looks beautiful. I believe there’s a huge misconception (especially around RWD) that things can’t be both simple, and good looking. I imagine The Guardian’s codebase is as elegant as its design.

Man, I really love The Guardian <3

What are two responsive web design frameworks/plugins/shims/etc that you recommend/couldn’t live without?

I don’t know if I can actually say this, but my own inuitcss is completely invaluable. I use it on every project, and a lot of people out there are using it—or its principles—on their own work. It’s a constantly evolving culmination of all my years of work. I’ve just started a large, very exciting, very ambitious project with the NHS over here in the UK, and inuitcss got our entire architecture and roadmap up and running within half a day. It’s a framework in its truest sense—it’s an enabler that I work because of, not in spite of; it doesn’t force design decisions upon a project; it’s fully customisable; it’s incredibly modular; it works to solve scalability and architectural problems, not visual ones.

On top of that, I’m not sure. I don’t really use much third-party stuff in my work. I know it’s not a plugin or framework, but I couldn’t live without Sass. I was one of the naysayers to begin with, really resistant to it, but now I can’t work on a project without it.

What is the one thing with responsive web design you would like to see improved?

General knowledge of its implications: how much responsive design impacts responsive development (e.g. a designer saying ‘this is large screen, this is small’ is very different to actually working out how to tie those ribbons together), how much it (can) affect(s) performance, how much remains unknown (small-screen does not equal slow connection, retina capable does not mean retina is always suitable, etc.). RWD is still in its infancy, but I think we all need to slow it down a bit, be prudent, be cautious, and be aware. RWD is great, really great, but it brings a lot of implications with it.

If you could offer one piece of advice around responsive web design, what would it be?

Keep it simple, seriously. I’ve worked on mobile-specific and fully responsive builds that have really, really benefitted from being simplified, toned down, pared back. In fact, there was an incident at Sky where a few simple changes to a design allowed us to take a product to 100% of the market six months sooner than was planned, equalling a return of hundreds of thousands of pounds almost half a year sooner than expected. All from simplifying a design. It’s good to push the boundaries, it’s nice to be ambitious, but we also have to be pragmatic. A good design having that much business impact is far better than a perfect design that takes twice as long to implement and maintain.

Start small, work from there, prove or disprove concepts and ideas gradually. Things can improve over time, as and when it’s appropriate.

A huge thanks to Harry for taking time out to answer our few questions.  For those of you wondering what his bonus two questions were…. well he was the first cab off the rank so he came up with the first two questions.  What were they? Who’s answering them? Well that’s for our next instalment.

Responsive Design Ebook

A collection of interviews, tips, tricks and some responsive sketch pages in one easy to download file.

Learn from more than 26 leading responsive design experts across more than 80 pages for the price of an expensive coffee. Or, think of it like buying me a beer to say thanks for sending you a newsletter each week…. plus you’ll learn tons too.

Buy Now for just $6.99

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>