How the BBC should practice Responsive Web Design
FACT: design as a service and responsive web design are incompatible. This is an open letter to Ralph Rivera, the head of BBC FM, explaining how we should change the relationship between developer and designer. This blog post is massively inspired by (and in some places copy’n’pasted from) Trent Walton’s excellent blog post which finally placed into words how I’ve always felt but was unable to externalise. Thank you Trent 🙂 and sorry for copying you so blatantly.
UPDATE: It’s been rightly pointed out to me that this blog post can be interpreted as a criticism of individuals working in the News UX team and the wider BBC. I’m sorry for causing any offence, this is meant as a criticism of the way UX and dev are structured rather than aimed at people.
Before iPhone
The BBC has always practiced design as a service: UX is given a brief, delivers designs based on that brief, and then a dev team implements the design. This worked but it always irked the dev teams. Pixel perfect, flat designs don’t take into account the variability of the web, they don’t describe what should happen in the different circumstances that can occur when different people use our websites.
It doesn’t explain how different types of browsers should be supported, or take into consideration SEO or accessibility concerns. And when the design that the product manager (read: customer) and designer both sign off on had a HUGE background image, well that just made us developers mad!
But we used to get away with it because everyone used a desktop computer, on a broadband connection, in one of 4 browsers. Developers would have to find a compromise with design or be accused of trying to practice engineering perfection.
After iPhone
This isn’t the case anymore, since the iPhone the variability of the web has exploded and its now impossible to communicate or even be able to understand what might happen during a users experience on our site just by making static designs. To face the reality of the web’s inherent variability by default means addressing the following issues from the very beginning:
- Hostile browsers
- Tiny screens
- Slow connection speeds
- Touch inputs
Cars are designed to perform in extreme heat or in icy roads, not on a well paved road on a normal day. We should be practicing responsive web design in a similiar fashion. With such a wide range of possibilities the sensible thing to do is zero in on the harshest conditions (or toughest things to deliver) and start from there.
Trent explains these four issues excellently (I’ve altered some of this to make it more BBC centric):
Hostile browsers
Making websites pixel perfect is unrealistic. People deliberately use outdated browsers (IE7 and IE8 only trend on our stats when people are at work), while others prefer browsers like Opera Mini and Chrome set to proxy mode that place data savings above visual performance. This hostility extends beyond browsers to the web itself: JavaScript timing out while on a train riding across the Northamptonshire countryside, battery saving modes that limit the connection speed. Its perfectly natural for the web to be in a constant state of flux, embracing this variability means that we must prioritise content delivery to all browsers (HTML and mobile-first structured CSS) and progressively enhance from there.
The responsive BBC News site does this, it delivers a core experience and then enhances the site if the user has a modern browser. This technique is called “cutting the mustard”, its a technique that has been picked up by other companies and similar techniques have been developed too.
Tiny screens
The majority of our users now consume our site on a device that isn’t desktop. I’m deliberately not saying “mobile”, because that word best describes a persons complete experience with us rather than the type of device they are using.
Function should dictate form. UX practices print design when it should really be practicing product design. What I mean by that is we’ve defined 4 break points to fit the content into before we’re even looked at the content. How do you even know when a break point will be needed when you’ve not seen the content? Does every single one of our pages just serendipitously require the same 4 break points as every other page on the site?
I think the 4 device groups that we use when talking about our designs is a nice communication tool, but it doesn’t solve all of the problems our content has when viewed in all the different devices our users have. A break point is called a break point because it is a point (width) at which the design starts to break and look weird. We should be designing our sites content first and seeing how it fills different canvas sizes rather than defining 4 blank canvases and trying to force our content into them.
Slow connection speeds
A fast website is a well designed website. Nobody deliberately asks the dev teams to make a site slow, but with each element added to a page the page weight increases. Balancing the performance against the amount of content/functionality in a design is impossible to do if UX is only delivering the design. The BBC should be using the concept of a performance budget. We should have a minimum viable speed for each page, adding a new feature to a page should take into account the performance budget: is the benefit of the new feature worth the increase in pain downloading the new feature would cause the user? Can we remove a feature or post/lazy load it to accommodate this new, more important feature?
Touch inputs
There is no correlation between screen size and input method. The device explosion that started with the iPhone is still mushroom clouding out beyond us. In the last year we’ve had Chrome laptops with touchscreens, smart watches and Google Glass. We need to be input agnostic and adopt a “fat finger first” approach to web design. Its easier to make affordances for fat fingers initially rather than retrospectively, especially when detecting touch is near impossible.
The “4 screens” strategy BBC FM speaks about is backwards looking and incorrect. Instead our strategy should be “all screens”.
Design as a service is broken
We can’t continue practicing design as a service for the following 3 reasons:
- A separate UX team slows down our ability to deliver because there is no quick iteration between design and build: seeing what works, what doesn’t and feeding that back into the design process.
- How do we even know that the final delivered design is right if it has had no extensive user testing or A/B testing on the site? Nobody gets it right first time and yet by delivering the designs up front we’re acting like it is.
- Separate UX teams hurt the user experience because UX people are sheltered away from the realities of how our users consume the site and so they lose all perspective of how the site works, or even worse they assume everyone has an iPhone and a perfect internet connection.
- Constantly moving UX people around the business means that they never learn how the product they contribute to works. This kills us as each new UX person needs time to understand how our site functions. In the worse case we’ve had UX people spend a very long time in isolation working on a new feature only to bring it to our dev team and we immediately start seeing issues with it.
How we should work
UX need to alter how they perceive responsive web design, they need to address the scenarios of hostile browsers, tiny screens, slow connection speeds and touch inputs by default. Responsive web design isn’t about mobile or desktop, rather its about adopting a more flexible approach to the web. It’s about accepting that we never really had any control over how the user consumed our content. And instead of trying to force users, browsers and their internet connections to work how we would like them to, its about designing an experience that moves in the same direction as the web, using the flow of the web’s current to move faster to our destination of larger audiences.
If you want to make better products, if you want faster development cycles then embed UX into the development teams and make us jointly responsible for the same objective: a working website.
By @tmaslen