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.

My Mission for 2014: Writing is Structure

It will come as no surprise to anyone that I’m interested in writing, and specifically the writing of narratives. I’ve always harboured a desire, if not the will or confidence, to write stories – scripts, sketches, that kind of thing. And, in the realm of technology, I’ve long been interested in structure. It’s often said that structure can be bad – too restrictive, too cookie-cutter. That’s not the kind of structure I’m interested in.

Things like Mythology Engine, Storybox and the Stories Ontology were attempts to convey the kind of thing I am interested in – but they, too, can be interpreted as trying to dissect narratives, and thus ultimately destroy them. In contrast, I guess what I’ve been trying to investigate is the structure which informs the creation of narratives, as well as the analysis, with the latter being only so that the narratives can be discussed, shared, and in turn, inspire new narratives. So my interest is more in conveying meaning, where possible – telling stories to the machines, as I’ve noted elsewhere. But also in using structure as a guide, as an inspiration.

Many times when I’ve tried to start writing a story, I’ve struggled. At first, the fear grips you that it’s down to two things – you can’t write, and you don’t have any good ideas. The first fear can, after a while, be dismissed, especially with the adage that is prevalent in technology as well as writing – just make/write something, a terrible first draft, just so you’ve got somewhere to start from.

The second fear, of no ideas, is a harder one to shake. Primarily because, in a lot of the writing I’ve read on writing, it concentrates literally on the process of writing, of scrawling on paper or typing on a computer. Giving yourself time to write, setting a target of a certain number of words a day, even in terms of writing prompts, little sentences designed to spark your mind.

But I’ve never really found this helpful either. What is helpful, I’ve found, is structure. Again, not as a ‘this is how you must write your story’, but as inspiration – ‘try this way of structuring your story, and see where that takes you’. Robert McKee’s book, Story, is a step in the right direction, but it felt a little too focused solely on screenwriting, and was a tad too opinionated and didactic for me. I got about a third of the way through the book, and, feeling it wasn’t for me, gave up, falling back again on the thought that you just had to sit in front of a blank screen, perhaps with a writing prompt, and see what happens.

Then, two things happened – David Varela’s tweet – ‘Writing is structure’, provided a spark of light, for me. For so long, I’d been under the impression that structure was always viewed with suspicion by writers, for the ‘cookie-cutter’ reasons above. But this gave me confidence.

And then, I read FilmCritHulk’s Screenwriting 101. I found it incredibly inspirational, broad-minded and enlightening. It doesn’t really talk about the process of writing as I’ve mentioned above (the ‘just sit down and write’), nor the slightly worn phrase ‘writing is rewriting’ (the latter, which may indeed be true, doesn’t help, in terms of a narrative, if you’re trying to work out how to start).

What it does, is help you focus on the inspiration for narrative and character, and suggests several structural approaches for both analysing and creating. Things like the five-act structure, character trees, snowflakes, ‘therefore and but’, and so on. Seriously, read the book. Again, it doesn’t insist that you write every story in these ways, but it gives you frameworks, approaches – things you can try, which will help you structure a narrative, before you get to the stage of literally writing the dialogue and so on.

That, that is what I’m interested in. And I want to know more. Firstly, because ever since reading the book, whenever I watch a film or TV show, I’m consciously looking out for five-act structures and so on. But secondly, because I want to build something. You see, as far as I’m aware, all the tools out there for writers are either ones that are very general purpose ‘idea collection’ tools (mind-maps, post-it notes etc), or purposely script-writing ones (things like Final Draft, or Adobe Story). But I’m not sure there’s anything in between. Something which takes the structures and frameworks and leads you through them, or helps you create narratives using them, or even just helps you analyse existing narratives through that lens. So that’s what I want to build.

To that end, this year, I want to learn and understand as much as possible about the structure, craft and process of writing narratives. I’m not as interested, as I say, in things like ‘how do you find time to write’ or ‘do you just sit down at your computer, type, look over it, and type again’. I want to find out more about the different ways you can structure a narrative – what are they, how often are they used, where are they helpful, how might they be combined.

I want to speak to as many writers as possible about this. If you’re interested, get in touch (I already have a short list of folk I’d like to talk to, so expect emails, but get in touch anyway!). If you don’t really use structure, that’s absolutely fine – I’m not trying to force everyone to use it – I just want to provide something for those who do use it, or are interested in it. Similarly, if there are tools which already do this – I’m interested in terms of research, but I’m still going to build something, if only for my own learning – please don’t bring me down ;-)

I’m thinking this could result in a series of blog posts, or perhaps even a podcast series, of interviews with writers – and then ultimately a tool, based on all that knowledge.

Let’s see where this takes me.

P. S. Things that also helped inspire me to write this – John Yorke’s Into the Woods, Matt Locke’s Don’t get bigger, get weirder, and Kim Plowright’s Guiding Principles.

P. P. S. Oh, and I guess I should write a blog post about the slightly-different new job at some point, too..

P. P. P. S. Also worth clarifying – I’m not looking to build something whereby machines auto-generate stories. Whilst that may be an avenue worth exploring, I’m not interested in taking authorship out of the hands of humans. This is about giving more tools to humans to create stories, and, perhaps, to widen the audience of those stories to include machines as well.