The author chose to make this story unlisted, which means only people with a link can see it. Are you sure you want to share it?

The GDS Design Principles for Agencies

WIKIMEDIA COMMONS / http://bit.ly/17E3kqx

The GDS Design Principles for Agencies

Part 1 of 3

In my previous post I talked about the Government Digital Service. The GDS’s Design Principles are still, for me,the best practical enunciation of agile, delivery-focused philosophy taking over in digital today. A copy sits taped to the wall above my desk at work.

So, by way of starting, I am going to look at these principles, extend them and see how they can be applied to digital marketing & advertising. There’s ten of them in total — to keep posts at a reasonable length, I will look at the first three to begin with.

1. Start with needs*

* user needs not government needs

Replace “government” with “client” or “brand”, and we’re getting somewhere. Yet all too often, the actual end user’s needs get relegated to the tail end.

One example of this is the common practice of making users of a Facebook app Like or post a Tweet to use something before they can start.

“Great — I always want to Like a page or Tweet about you before I can use your service, rather than just use your service”

— Absolutely no user, ever

Whose needs are met by these? Certainly not those of the users. The “Like” is not genuine. It feels cheap, a little bit crappy even, and plenty of people will just unlike or delete the Tweet when they get a chance.

Those that don’t undo their action will make your KPIs look good. But KPIs are meant to measure performance — they are a means, not be an end to themselves. If you’re artificially inflating those KPIs, then what exactly are they measuring? Not only is it bad for the consumer, but it’s dangerous — inflated KPIs mean you don’t see if your apps are poor or unengaging, but mask it.

If your answer to not getting enough Likes is to force people to Like things rather than improving your product, then you need to get out of the business. Truly engaging brands and apps don’t need to compel; they’re good enough to earn plaudits organically. With apologies to John Willshire: Creative developers should be making apps people Like, not people Like apps.

Starting out with user needs will make you produce a better product.

2. Do less

There’s many excellent, well-provided open source frameworks out there. A lot of the question that used to bug us in the early days now have workable, open-source, solutions — solutions that ten years ago I would have killed for. Modernizr, Bootstrap, Underscore on the frontend, with Symfony, Django or Ruby on Rails supporting the back. And you can quickly get these set up on a virtual server on AWS within minutes to test out, and wind it down if it doesn’t work out.

In short, you’re now able to rapidly bootstrap an app or idea with these technologies at a speed unimaginable a few years ago.

Yet all too often, agencies (and clients) rather do more than less. Wheels have to be continually reinvented. The same mechanics abound (fill in a form, win a competition). Every project must be painstakingly (and expensively) designed and wireframed out before a line of code is written. Websites must be hosted on proprietary architectures running on ancient versions of IIS or Apache, and conformant with ancient versions of Internet Explorer.

No wonder then that too many great ideas get bogged down, obsessed by process and risk-averse. Expensive eggs-in-one-basket marquee projects come to forefront, and waterfall starts to dominate your entire approach.

This monolithic nature may in part be related to old-school agency monolithic ideas about creative — everything must come under the umbrella Big Idea, the one-size-fits-all Message. And that may have worked in a time when advertising was static (print, out of home) and agencies could move at the pace of an oil tanker (and ads cost as much as a tanker).

We need to break away from monoliths, both technical and creative, and think more diverse, small, even risky, projects.

3. Design with data

Data is in fashion right now — you cannot move for articles continually about the rise of Big Data, or how data-driven development is the next big thing. On the face of it, it’s brilliant — we can get near-real time feedback on how users are using our apps and sites and we can adjust or modify our designs or workflows based upon that.

But “data” is a pretty catch-all term, and it would be dangerous to treat all data equally, or even to treat data as gospel. We need to be careful about the nuance involved when dealing with data — the very process of collecting it comes with a set of assumptions and hidden contexts. Whenever collecting data, bear in mind the following questions:

How was that data collected?

How accurate is that data?

What assumptions have been made about that data?

What about the data you are not collecting?

For example, serving customised content to someone based on what they & their Facebook friends have liked. What a great idea, especially as we have the data right at our fingertips! But, this is predicated on several assumptions:

A person shares the same (or similar) tastes as their friends

A person’s Facebook friends are the same as their real-life friends

All those Likes are actually what they like

All of these assumptions are, at the very least, open to very open doubts. Particularly the last one, if some of those Facebook Likes have come about from forcing people. Perhaps that’s why Open Graph search has been such a disappointment.

This does not mean that your data is deceptive by default, or that designing with data is mistaken. What it does mean is that, as part of the process, we should never be afraid to question the data collection process and the assumptions behind it, with an open, not cynical, mind.

Questioning those assumptions can go a long way, and produce some surprising results. A final example: using green for a button to mean “Get Started” is best for click-through, right? Green means go, after all. An assumption nearly everyone makes, because nobody bothered to even check to see if it’s true. Until someone actually did A/B test it, and it turns out red is better than green (at least for for one website)

Designing with data does not mean the end of creativity in design. On the contrary, it demands that we be creative and challenging when thinking about data, to get data that is useful and can produce meaningful decisions.

Parts 2 and 3 coming up in due course — in the meantime feedback welcome