On Design as a Service

Yesterday, Tom Maslen wrote this piece, on responsive design and how the BBC’s User Experience and Design (UX&D) teams are set up to work with the various BBC ‘product’ teams. It’s good, you should read it, and then come back and read the rest of this.

I agree with almost everything in there, but thought there were a few points that needed fleshing out, perhaps with a slightly different viewpoint. Obviously everything which follows is personal opinion, and is offered up in the spirit of open communication, with the aim of making things better, rather than personal attack or criticism.

Some background

From October 2008 to December 2013, I worked in the aforementioned UX&D team. From 2008-10, I was part of an embedded team within BBC Audio & Music (A&M). From 2010 onwards, the department, alongside most of BBC Future Media (FM), was reorganised several times, and we became more of a central team.

It’s fair to say that I found the time embedded within A&M much more productive and fulfilling, though of course there were rough patches too. I strongly believe that the embedded nature of the team was a big part of why it worked so well – but there were plenty of other factors.

Although Henry Wood House wasn’t the shiniest of buildings, the three floors that we were based on were open plan and yet small, giving the air of a small business. Open enough to share, and not large enough to be overwhelming and faceless.

Thanks to the sterling work of Tristan Ferne and others, we had what was known as 10% time, similar to Google’s 20% time, which was a chance for anyone, of any discipline, to work on their own personal projects, as long as they were somehow related and beneficial to the BBC. We had monthly show-and-tell meetings, where people could come with ideas or requests for help, and this all promoted a very positive atmosphere of shared expertise and mutual learning. I’d bring it back in a heartbeat. But anyway…

Taking the emotion out

One thing it’s important to state clearly, is that any critique of current practice or organisational structure has to be divorced from personal criticism. As Jake and Crystal both pointed out, correctly, there is no-one at the BBC, either within or outside UX&D, who is actively trying to keep designers and developers from working together. There is no evil master plan. That said, several very good ex-BBC people cited this way of working as one of the reasons for leaving the BBC, so it’s something that shouldn’t be swept under the carpet as a non-issue.

Most of the designers I worked with in UX&D are great people, who would be more than happy to work alongside developers. And there are good people within UX&D working on figuring out how we should adapt to responsive design and the main truth that Tom, and others, have pointed out – online, you simply can’t control completely, how your users will experience your content. How do we provide the best possible design solutions with that in mind? I agree, we start from the bottom and work up.

And finally on this point, I think it’s important to have this discussion in the open – like I say, no-one wants to make things worse, so we need more discussion between developers and designers – and I know that there are plenty of people at all levels of the UX&D structure who want to make things better. So let’s make something good happen.

Here be problems

That said, there’s no denying that there are problems with how things are done at the moment. Again, this isn’t necessarily the fault of personalities, it’s just the way the organisation is structured, and how working practices easily fall back on ‘traditional’ waterfall-esque design approaches. This really needs to change. Everyone needs to be focused on delivering the real thing, and realise that User Experience includes loading times, page weight, caching and so on, all the way down to how you structure your content and your data. As Tom says, start with understanding your content, not just your users – really understand it, and design around that.

Tom is also right that the ‘4-screens’ mantra, and break-points approach, is holding us back as much as it is helping. Again, I think both of these things have good intentions – the first is to underline, to those of us not familiar with the mobile web at all, that we need to change from simply designing a desktop site, to something which works across multiple screens. The second is simply an attempt to be able to design *something* given the vast array of screen proportions.

But ultimately, both things are flawed – Tom advocates ‘all screens’ – I’d go further and say ‘no screen‘ – because what’s really important is the information, the content, the meaning and interaction with your users, and this needs to be designed to work in any possible medium. That’s why I’d start with designing your domain, API and URIs, then build up from there.

Defending the Centre

And yet. I’d like to somewhat defend the ‘central UX team’ approach, just a little. Or, rather, extend some empathy towards understanding why such an approach has been taken. Because one of the problems of such a large organisation such as the BBC is its’ traditional silos. The ten products strategy, although great at reigning in the sheer volume of wildly-varying-in-quality online output, has, unfortunately, reinforced silos as much as it has broken them down.

And so having purely embedded design teams can lead to massive differences between the ‘products’, and a lack of joined-up thinking or overarching strategy. With that in mind, a central team which can work across many products, makes sense, of a sort. It also helps foster a community spirit, and shared knowledge and expertise between designers.

However, it also encourages and highlights the differences between disciplines, and, just like with the different products, a separate team with separate objectives will lead to people pulling in different directions. It also leads to organisation structures and layers of process and management which result in unexpected side effects like completely separate desk spaces for different disciplines.

To be clear, I think there is a very good rationale behind the idea for a central UX team – from within News, or any other single product, it may make perfect sense to have an embedded team, but when you’re responsible for establishing a quality standard of design across the whole of the BBC, you’ve got a more macro-scale problem to deal with.

Forever Cycling

The other problem Tom highlights is the cycling of UX&D staff through different products. Again, having witnessed things from the other side, there are good intentions behind this. As David hints at, rotating staff gives people a chance to try new things, to learn from different teams. It helps spread knowledge around, so that if a member of staff is away or ill, and again, reinforces the sense of a consistent approach to design across all areas of the organisation.

And yet Tom is right – it also means that you have to spend an overhead of time training up new joiners, a lot of expertise can just disappear overnight, and, quite frankly, the resource management of all this can be a nightmare from the UX side of things too. Personally, I also felt under more pressure in this system, as I was never fully in control of my own resourcing (but then unless you’re freelance or run your own business, you’re never fully in control, so that’s almost certainly just my hangup!).

In Summary

Overall, then, I think Tom is pretty spot on, if veering a little towards a too-negative perception of the people that make up the UX&D team. But a) I don’t think that’s intentional, and b) this is exactly why open discussion, sitting and working together is needed – because the more we continue to define ourselves as separate and different, the more that others will make assumptions about our attitudes, and communication breaks down, being replaced by suspicion. Gosh, that’s just defined multi-cultural tensions in a nutshell.

I would advocate embedded design teams, or rather, completely multidisciplinary teams, focused on the same goal – making the best possible thing, for the most number of users, via any form of interaction. But I do think there’s important and complex problems to be solved on a more macro level across an organisation such as the BBC, if we are to maintain a good level of quality.

I’d suggest this can be achieved not by separation of disciplines, but more by a loose and regular discipline meet-up/network type approach, perhaps, so that people of similar skills can keep some sense of community and share ideas and expertise. Having said that, the sheer size and geography of the organisation doesn’t make that easy – but it’s not impossible, we just have to try.

And finally, as Michael quite rightly points out – all of this is pretty useless if the rest of the ‘business’ is unengaged and even more separated from development than design.

There are good people who want to help solve this. Let’s keep talking, but more importantly, do something. Maybe moving back into Henry Wood House is a (completely impractical and impossible) start.

Leave a Reply