Archive for April, 2009

This post has been brewing inside of me for some time. It’s has finally been burped-up precipitated by Ben Malbon’s provocative post at BBH Labs (yes, we are genetically related – he is my uncle).

Ben asks the question, “Why isn’t there more great work in the interactive space?”, and it sparked rabid debate at the BBH Labs blog – in no small way helped by his Twitter ‘outreach programme’.

I’m not taking the piss when I say that it’s gathered a posse of mainly advertising folk – strategic planners and digital creative brains – in one place. It’s a kind of ‘dirty’ several dozen. It’s like Mad Men two-dot-oh without the cigarettes. But it’s generated a fascinating open conversation about a big problem: what do advertising agencies need to do about digital, or interactive, or whatever it’s called? The really interesting thing is that this conversation is happening in the open. The problem is both bewildering and widespread enough to have convened an itinerant community of interested people from competing agencies in discussion. The power of networks, eh?

We at Made by Many obviously come at the problem from a different direction. We’ve been creating web applications for almost a decade and avoided interactive advertising, banners and buttons. As we work increasingly closely with advertising folk I thought it might be useful to contribute some of the guiding thoughts we’ve collected along the way. As an adjunct to Ben’s post I’ve jotted some of these down. I stress that this is not a magic formula for getting interactive (or digital or whatever…) to work better, it’s just a set of observations based on our experiences of delivering lots of the kind of projects we think ad agencies are going to want to be better at in the future.

So here goes:

Remember, it’s software. To most above-the-line folks software is a black box. You put great ideas in one end and disappointing stuff (compared to their inflated expectations) comes out the other end. The black-box model treats technology as a kind of grubby witchcraft. There is little or no idea of relative complexity, cost, resource or time implications of building the software to make the great ideas happen. A brilliant Technical Director once said to me, “Remember, whatever you’re trying to do has got to be delivered over HTTP”. Lesson painfully learned: you can *only* do this stuff successfully by involving technical people fully in the creative process. I’m not talking about the IT Crowd, or your network people, or hackers, or weirdos – they are all *the wrong kind of techy*. I’m talking about people with social skills and rounded personalities, people who are actually quite like you but just just happen to know a great deal more about how technology and creative work together. This relates to points 6 and 7 of Ben’s list. I’ve put this as number 1 once because once you’ve got a good technical leader working with you all else will fit into place.

It’s a ‘copy and paste’ world. You are legally required to act like a magpie. You have a god-given duty to plunder the Web for what works and to remix, recombine and reinvent it to be better. I’ve been amazed and horrified recently to hear above-the-line creatives say things like, “Let’s try and create the new Facebook…” or “Maybe we can come up with the next ’social networking’”. Yeah – big ask. Good luck. This relates to Ben’s point 8, “Not invented here…” In our opinion, you should try to use as much as possible of what’s already out there and built, and try to create as little as possible yourself.

Do as little as you can. I remember how freaked out prospective clients were when we started telling them we try and do “as little as possible”. It still scares them. I think we must have got it from 37 Signals’s web book Getting Real. I strongly recommend this book/philosophy to anyone who really wants to know how to be better at digital. It’s all in there, many of the themes picked up in Ben’s blog post and the conversations rippling outwards from it: ‘Less Mass’, ‘Half, not Half-Assed’, ‘Race to Running Software’, ‘Start With No’, ‘Rinse and Repeat’ – it just goes on and on. Changed my life that book. I remember the old school Chief Technical Dude at a national broadsheet shouting at us once, “I didn’t come here today to discuss philosophy with you”. He’s not there any more. First they laugh at you. Then they hate you. And then you win.

Embrace change. Also covered extensively in the 37 Signals bible and utterly obvious to anyone who has ever built anything digital. Change is inevitable. Yes, change, *during* the course of development. So, instead of trying to contain change with shed-loads of useless specification documents and the Damocletian threat of change requests, why not embrace it? It’s a good thing. In fact change is just about the the **best** thing about the Web: you can change it at practically zero cost – it’s not like making something physical and then having to re-make it all over again. If you’re not leveraging this wonderful quality of web software then you’re in trouble. Having a lower cost of change makes you competitive – and as you are competing for eyeballs, attention and engagement with a trillion other websites in an environment that’s still evolving faster than most organisations can handle, you’d better start loving change: change is your best friend. Hug change. This relates to Ben’s points 1, 6 and 10.

Work fast. Fail fast. Clients are often amazed at how quickly we work. We created the Telegraph blogs platform in 5 days from scratch – note: we didn’t use WordPress (wish we had btw but this was a couple of years ago) we designed and coded it in .NET. And then we did the same with MyTelegraph in 17 working days. I don’t think I’d like to work quite that fast again but it shows what you can do with a tiny team of specialists following a process they totally own with a very clear idea of what they were trying to achieve (and permission to fly under the radar). We work in tight iterations that involve team members in committing individually to small parts of the bigger project and delivering again and again. At the end of each iteration we have a demo to the whole team and the client. There’s nowhere to hide. If it doesn’t work, we think again. Best to find out as early as possible if you need to change direction. And in order to keep the velocity high and the feedback as real-time as possible we try and involve the client in ‘live’ decision-making. The time required to develop anything is approaching zero (of course, it will never actually be zero!) so you can now design and develop in near real-time, instead of sequentially. We think this provides a fascinating opportunity to apply Agile software development methodologies to the entire process, from strategic vision through delivery, ongoing management and further releases. You’ll need to experiment to find your optimum rate, but it’s incredibly exhilarating to work fast and we’re convinced that this contributes to better work. Use as few people as possible. Small teams are more productive. Use multi-disciplinary people not just multi-disciplinary teams. This relates to Ben’s points 1 and 10.

The people selling it must in some way be responsible for delivering it. At my last place, we used to have a Sales and Marketing Director who knew practically nothing about the Web. He would go out and sell ridiculous things that could never be built within budget and were probably crap ideas. He would promise anything to get a sale, with no thought for the consequences. He had no responsibility for delivery at all. That unhappy situation may be analogous to the layer of account management one might find inside some ad agencies. We dealt with it by getting rid of account management and giving clients access to the teams delivering the work. The clients were happier, the teams were happier and the work was better. I know this is a difficult one and people often criticise digital agencies for having fairly shoddy client services, probably fairly, *but* this is not in itself an argument for having a layer of people in the way. It is an argument for making sure that people who look after clients not only know what you do and how you do it – in detail – but also share responsibility for delivery. This relates to Ben’s point about risk-taking. Great to take risks – but everyone should have a stake in them, on the upside and the downside.

User experience is much more important than you think it is. It’s hard to exaggerate the importance of having the right attitude to user experience. It’s impossible to imagine all the people who will ever use the thing you design and build, to conceive of how how different they are to you, to understand what their lives are like and how your thing fits in, or to see the world – and your work – through their eyes. However, unless you try relentlessly to do this you can never produce stuff other people will use habitually. We use a lot of storytelling techniques to capture user needs and business objectives in a format that we can turn into software. And then we obsess about the user experience, and we keep on obsessing about it long after the site is live and make constant upgrades and new releases. It can always be better – user experience, behaviour and expectations are constantly evolving, and your intended audiences always spend more time at other peoples’ websites than they will ever do at yours. They will judge what you’ve done against the last best experience they’ve ever had. Which is harsh, but it’s a fact. Getting a lot of people there on day one is fairly easy. Frankly, you can pay for that and it’s no measure of success in the new skool. Getting people to come back repeatedly, inveigling your service in their lives: very, very hard. Ask yourself the following questions: Why does what you’re doing matter? Why will it bring people day after day? What’s in it for them? What will make people recommend it and talk about about and bring their friends? These are the toughies, and that’s before we’ve even started talking about revenue.

Be generous. Give it away. I hope this doesn’t sound too hippy, but we’ve found that working in an open way and sharing things with a broad network online has really worked for us. We use a lot of Open Source Software – and we obviously also open source some of the stuff we make. Recently, we’ve been sharing presentations on SlideShare. In the past we’ve found that blogging about the way a project is coming together helps to generate useful feedback and interest. Everyone is trying to work this stuff out – and will be for some time to come. The kind of thing we’re seeing at the BBH Labs blog, and at We Are Social’s blog – with competitors sharing thinking and debate – is only going to grow.

Create a shared visual language. Technology is often very abstract, intimidating and difficult for clients and even some of the people working in a multi-disciplinary team to understand. This is why we always try and create a shared visual language for the project team: diagrams that explain what we’re trying to do and how it all fits together. We sketch, we use collage, we build models and tangible representations of the things we are trying to create and the way the end-user will experience it. Traditionally, software development has been heavy on written documents and opaque diagrams. We’ve tried to smash that apart and make it accessible to everyone regardless of their experience or background. We totally believe a big part of our job is “translation”.

Act like a start-up. Ben talks about a lack of great interactive (or WhateverTF it’s actually called), but there are many, many examples of great interactive created not by agencies, but by start-ups: small teams of people working out of garages or similar grotty premises to make disruptive and game-changing new digital services like Delicious, Last.FM, YouTube, Blogger, LiveJournal. Start-ups seem to be able to do what ad agencies find very difficult. This is interesting, as ad agencies will soon be making many of the things that connect brands and people in new ways in the new skool – traditionally the bread and butter of the eager little start-up. We always *try* and run a project like a start-up. It’s not always possible, but even if you can only manage it partially you’ll find yourself doing a lot of the things above quite naturally: working small, fast and Agile; stealing ideas inspiration; being obsessive about user experience and treating it like software.

Creativity is slightly different online. Digital horizons and possibilities are still opening up so rapidly that it’s difficult for all but the most insanely passionate to keep current. This isn’t like having a personal interest in style or fashion, or art – it’s about getting in there and trying countless numbers of services out. It’s about being registered at a thousand social networking sites just so you can compare the interactions around sign up, or how they deal with recommendation. Clearly, there isn’t actually enough time in the day for one person to do all of this – which is why we employ a whole bunch of loonies and do it together, using a whole set of social tools. We also lean on a network of many thousands of people outside the business: people in our own blurred personal/private networks. And we always look for people who understand that this isn’t just another channel, but a change in the way human beings operate at a fundamental level. It’s kind of bigger than communications, advertising or marketing for us (which sounds terribly embarrassing and weird but I hope you know what I mean). I think that being *that* engaged with it all allows us to zoom in and zoom out, and think about strategy and creative in parallel with executional thinking. This is, I think, very different to the linear way of approaching a problem where you sort the strategy out first upfront and then work your way down to executional issues. In Digital (or WTF it’s called) that would risk getting far too far in a project before realising the awful truth about cost or complexity.

As I said upfront, this is not meant to be an exhaustive list of ‘how to do great digital’, just us sharing some of the things that work for us. We learnt most of them the hard way!

13 Comments