Tag Archives: design

DR Codes

This is a thought that’d been rattling around in my head for a few years, which I want to try and crack this year.

Each agency I’ve worked in, there has been some form of tea making culture. Every day, at varying times during the day, someone will offer to make a brew.
Small teams of good friends know how to make each others drinks, but larger teams struggle to remember, and if you’re offering to make a large round, you have to remember quite a few permutations of the basic bases: Drink Type, Sugar Count, Strength/Milk Ratio, Foam, Steep Time, and so on.

At de-construct, we had a number of solutions to remind brewers how the team liked their drink. These were pieces of beautiful design which presented the instructions to make the drink in a graphical format, printed as a large poster in the kitchen area. The first one, I think was done by Alex Griffin, mostly in response to me accidentally putting salt in a cup of tea instead of sugar (they look the same, it wasn’t my fault).

There are so many combinations though, and people change their desires frequently – I’m drinking more tea than I used to for instance, and some times I need sugar, other times I don’t. If you’re making me coffee though, its simple – freshly ground black filter coffee please.

So posters only work so far, and don’t solve the problem of remember who wanted a drink either.
How often have you scribbled down some hieroglyphs like MK: T2S, SB: C1SB, KL: C2 to keep track of who asked for what?

So the idea of a DR code came to me a few years back when looking to create a new poster for a space: A graphical marker which explains how someone wants their drink, that can be read by both humans and machines. A QR code for drinks.

A human looking at the code could easily see the drink’s make up: drink type, sugars, milk, etc. A computer could read even more information, and build that into applications. A mobile app could easily capture what drinks people wanted, and who wanted them – perhaps the DR codes are stored against the address book entry, and the app logs the ratio of making the drink to receiving the drink (to catch out people who never step up to the kettle), and that data could be aggregated to show the consumption habits of a business, and improve stock ordering accordingly.

So I’ve started work on creating the code itself, a human and machine readable visual device which holds information on a drink’s make up.

There are TR Codes (Tea Requirement codes) and CR Codes (Coffee Requirement) so far, and I’m still tweaking the meanings (for instance, subtleties between ristrettos and espressos, or milk/foam ratios for drinks like a latte vs a capp’).

There’s potentially colour to explore too, to expand the drink types. I’m pretty sure it could extend to drinks beyond the office, cocktails for instance might work based upon ratios.

Once the DR Code works, I’ll look at how we can use some simple Javascript to recognise the icon, and act upon it in some way.
I’d also love to look at non square / non digital looking versions, using perhaps pie chart type visuals and colour.

There are bunch of references which have influenced this so far:
The work Mat and I did on CLARITY*
The espresso field guide (and versions of that)
Tea over IP

Venturing is the new social

I had this slide in a presentation to a client about six months ago.

They’d asked me to come in and tell them what social media might mean for their business.

I introduced the presentation with some basic creds, how I’ve been doing this ‘digital’ thing since 1995, and how the question has rarely changed since then:

90s – What might the web mean for our business?
00s – What might mobile mean for our business?
2007 – What might digital mean for our business?
2009 – What might social mean for our business?
2010 – What might apps mean for our business?
2011 – What might social mean for our business?
2012 – What might …

and here’s my punt, What might venturing mean for our business?

(Excuse the order and timestamps, its just to illustrate a point).

By venturing, I mean creating new businesses, new products and new services, or investing in the process which allows them to be created.

Rapid product and brand creation. Applying startup and incubator models to agencies, and seeing what happens.

In its poorest form, it looks like agencies setting up hack days and not paying its developers, using the results and saying ‘look what we made’.

Slightly higher (or lower) on the scale is networks pouring cash into incubators like Wayra.

Above that are agency models like PIE and DE-DE, and shifting propositions from companies like R/GA.

And of course, at the very top are businesses like Frog, Ideo, Fluxx and Sidekick.

Venturing is the new new. That comes with bad and good, but will undoubtedly be interesting to see what is created/coerced.

Update: Just stumbled across this link which explains some of the problems with venturing and generally issues with working in startup modes. When campaigns fail, no-one dies. When businesses/products/ventures fail, jobs and people’s careers can be on the line.

Obsolesce is more.

Google by Michael Mandiberg
Google by Michael Mandiberg, used under CC License

I’ve been thinking recently about obsolescence, and whether we sometimes throw the baby out with the bathwater when jumping from one platform to another.

The Yellow Pages, for instance, has been practically destroyed and made irrelevant by Google, yet Google doesn’t allow you to browse in categories, as the Yellow Pages did, nor see an unrated/unfiltered/uneditorialised list of everyone in your local area – just those who have good page rank (and how many plumbers do you know that understand the importance of semantically structured content?).

The newspaper, although far from dead, is a snapshot of moment in time, and not just a single article but a massive slice through a single day, curating news, opinion, advertising, economics, literary style, design influence, and many other socially and culturally interesting aspects beyond just a specific piece of copy. Yes, the Wayback Machine exists, but it gives you little context.

Are there unique elements we lose, which still have value, as we progress to the next stage of an object or medium? How can they be amplified and either pivoted around or reborn to maintain relevance, rather than simply nostalgia?

Perhaps looking backwards is a good way of spotting valuable things we’ve lost and deserve to be remembered, or at the very least explored.

Privacy Policies are not enough. Transparency requires accessibility.


TLDR: Make data policy statements accessible, else they’re worthless.

There is currently lots of discussion about privacy policies, and the use of data by applications (not just mobile, but any application, whether it be desktop, web or unicomp) after a number of notable examples of companies taking/using data from you without explicitly asking permission to do so.

At the same time, Google have recently changed their privacy policy across all of their services, to provide a simpler, singular, shared policy, which not only aims to keep the policy more simple, but also allows data to be shared across their services.

And, today, a shared privacy policy has been agreed by the major ‘app store’ owners, which further aims to make policies clearer and arguably more strict when it comes to use of your data (ergo life).

Admirable (or forced into doing so) or otherwise, having data policy statements is only part of the job.

I challenge you to find me three people in your network who have read a EULA when purchasing software, or read every letter of the terms and conditions when buying a product from an online (or offline, for that matter) retailer. If you can find me three, and they’re not all lawyers, good on you – you’ll know just how much spare time your friends have on their hands to enable them to read the lengthy legal documents, and how intelligent your friends are that they can intepret the often complex and grey language.

In the main (me included), consumers and users do not read license agreements, and rarely privacy policies. They generally make an assumption that the organisation aims to not be naughty with their data. They place a great deal of (sometimes misplaced) trust and faith in these organisations to respect the data they have access to. Sometimes, the assumption is stretched to breaking point.

Personally, some of the techniques used by apps like Path, Twitter, Color and Facebook, are innovative and magical. They provide a layer of intelligence to the application which you don’t have to think about. If a centralised system has access to your address book, and your friends’ address book, it can see there is an overlap, and suggest that you connect also via their service. This is smart. This is using data to create a better connection between two people. I’m all for these sorts of clever approaches to making smarter experiences.

I’ll go a step further. If you had to approve every single data transaction, or clever technique like this, two things would happen: a) user experience would become so poor, that most apps would rarely seem like magic, dramatically reducing their appeal and adoption, and become less likely to succeed to be frictionless and b) new and left-field techniques would rarely be implemented, and apps would become functional, and progress and exploration of new mechanisms to create ambient and passive interaction would falter.

These are bad things.

So, what is the solution? If people don’t read privacy policies, that there is an important moral point to ensure users know how their data is being used, but all with progress, and painless user experience in mind, how can we make sure that apps ‘do good’?


Accessibility is not just about making sure people can get through doorways in a wheelchair, or see small text in big letters.

Accessibility is the provision of information in a usable form to all.

Accessibility in the context of privacy policies are making those policies clear, and immediately understandable, so they are read (in some form) and understood, and AGREED to.

And it is the explicit agreement for applications to use the data in the way explained which allows apps to continue to innovate and be magic.

How do we make privacy policies accessible? Plain English? No. Hire a lawyer? Probably not.

I think its through the use of icons. Those funny little dingbat symbols we see all around us which evoke meaning.

A picture of a man on a door, means men can use this toilet.

A horizontal line through a red circle means do not enter.

An arrow pointing upwards means we take your personal data and upload it to our servers.

An arrow pointing left and right means we share your data with other systems.

A arrow pointing up with a dollar symbol means we share your data with advertisers.

The first two examples you might recgonise, the final three I just made up, but with a globally recognised icongraphic data policy system in mind.

It works for food (red/amber/green lights for salt content on UK food packaging, for instance).

It works for film and computer games (BBFC ratings on films, or ESRB ratings on games).

It works for copyleft (Creative Commons licenses for instance).

In fact, Facebook already employ a basic similar concept for their “Approve this Application” screen when you’re using an app for the first time.

When installing or choosing to use an application, a quick prompt with a set of icons which quickly describe what the application will potentially do with your data.
This then allows you to make an informed decision on whether to continue installing the application.
It means you can make an informed decision on whether you’re happy for your data to be used, without crippling the user experience or innovation, and without you having to read through paragraphs of legalese.

This concept doesn’t remove the need for application developers and platform owners to develop honest, open and sensible data and privacy policies, it just calls for those policies to be made accessible, in a format that everyone can understand.

Once again, accessibility (and good information design) to the rescue.

Now, over to you, application platform developers.

Being able to grasp scale


I think so often when dealing with world issues like famine, poverty, illiteracy – the problems is not being able to comprehend the scale of the situation. What does 1.2 billion people without clean drinking water actually mean? And the more intangible the issue, the less one feels able to do something about it. These infographics all use the idea of ‘If the world was a village of 100 people..’ to scale down the numbers and make the problems tangible. Great use of design to explain a problem. Next step: Simple tangible steps towards removing the problem.