Yesterday we launched povertyover.christianaid.org.uk. It was a fantastic, yet challenging project to work on and over the next few days I’ll be describing the craft of producing this interactive infographic. I say craft because I truly believe that is what we do. We take an idea, whittle it, shape it and fashion it into something that makes sense in the digital arena. Something that the target audience will take meaning from and hopefully – share it with their friends – which was the goal of this website.
When BMB approached us with this brief we were extremely excited to be involved. Robin and I follow a lot of infographic blogs and from the outset we were enthusiastically researching these and looking for great examples of map based infographics. The thought of being paid to create infographics that moved and reacted to data, time and various other filters was very appetising.
From the outset, the data we were to display was clearly defined. For each of the existing 285 countries of the world, a statistician had put together a 500 year history (where possible) of their relative poverty or wealth. Read more here for how these figures were calculated. We were supplied a figure from between 0.1 and 1.0 for each country for every year. It was our job to make this look beautiful, allow people to explore the data in an interesting way and highlight the following key parts of the story:
1. The world has, on the most part, moved out of poverty especially over the last 60 years.
2. There are however vast parts of Africa and Asia that still have a a way to go.
3. Countries that have been extremely poor before they’ve come out of poverty.
4. With further investment, development and aid – it is possible to move the countries remaining in poverty into prosperity.
Initially we looked at many influences and considered lots of different directions for how we were going to start representing the data. We loved Aaron Koblin’s work (Robin blogged about his show at the V&A last year here) and whilst we respect what he does, we quickly realised that we needed to be extremely graphic in our communication style – which was probably quite far removed from Koblin’s work . There were quite a few variables in our brief; wealth, poverty, maps and time. We needed to be single minded in our approach to how this was represented. Here are some of the approaches and influences we looked at:
Carl and Simon – the most excellent creative team at BMB had also researched many different types of maps (this is a whole cartographic language on it’s own). They provided us with some great books like this one. We were able to find inspiration from many examples here – but also it started reinforcing lots of map do’s and don’ts!
Initially Carl and Simon were extremely keen to represent the data as a globe that the user could spin around themselves. We knew that until we actually started experimenting with the data and the visuals that we just couldn’t be so conceptually ‘nailed down’ just yet. To their (and the BMB producer Tyrone’s) credit they allowed us to be pretty non-specific with how we were going to display the map at this stage. We entered our prototyping phase with gusto, knowing that the team were in for some serious experimentation!
Any period of prototyping needs to have some clear questions to answer. We had three:
a) What was the infographic world going to look like? Was it to be a globe, a flat map, a 3/4 view?
b) How would we represent the changing HDI value? By colour? By the size of countries? By height or behaviour?
c) How far could we push the tech spec? A world map, with all of the country borders etc has hundreds of edges. If we are doing something in 3D how was Flash going to handle all of the interpretation of the data on the fly and then rendering it as 3d values. Should we use Papervision? Away 3D? Should we use 3D models from 3DStudio Max? What could we get away with before it fell over?
We finished our ‘Think’ stage of the project knowing that we had only planned the project in terms of the objectives and the potential of the raw data. Now… looking at the project from outside eyes, this might sound a bit irresponsible and lacking in “traditional” planning techniques, after all it might appear that we had simply created a list of questions based around look and feel, style and technical possibilities. We felt though that we had now fleshed out exactly what the website needed to communicate and we were now in an extremely good place – our Design stage was ready to go.
In my next blog post I will describe how we prototyped and started working out a visual style for the infographic.
Who are these ‘Users’ anyway?
There is a niggle in the back of my head. A meddling thought that comes out of no-where every so often and then disappears as quickly as it came. I’ve only just been able to crystalise and thus articlate this thought so here is my attempt at putting it to bed.
In a world of relatively new concepts like user centered design, information architecture, why is the language we use so far removed from reality?
Users, Use-Cases, Scenarios, Actions, Interactions.
If user-centered design is intended as a way of humanising and making products and services more relevant and usable for the target audience, then all of these phrases are a direct contradiction of that ethos. Who really uses these words in real life?
Over the past year we’ve been involved in quite a few big website build projects that have required a significant period of user centred design. I am not just talking about doing wireframes. Our way of working puts our ‘users’ at the heart of everything we do. We always set out our requirements gathering stage of the project by positioning them from the target audience point of view. The language of all our documentation is all based in ‘UX speak’. For example:
You get the general idea. This helps us formulate a wish list of functionality, which leads through to the creation of wireframes and then these prioritized features are designed and built. Our testing period uses the above terminology to check whether we have succeeded or not in what we originally set out to do. We can place great big ticks next to each ‘User Story’. So far so good right? Well, not really.
As we go through the above process our team often have to justify the design and functionality decisions we are making.That means that these documents, conversations etc are all shared with account directors, client marketing directors, client CEOs etc. Whenever I suggest that we are basing this or that route on something that the ‘user’ might do I am met with a familiar 3 second look. Its a look that firstly questions whether they have heard me correctly, secondly tries to work out why that word is relevant within the sentence and thirdly relaxes into an uncomfortable “ok buddy, I think you mean ‘our customers’ so lets just pretend that you didn’t see me wince when you said ‘user’ to me”.
A user? A what? Are they on drugs? A user story – why is it a story? Who is telling the story? Is this jackanory?.
‘User’ is the word user that I am most ill-at-ease with. It is jargon of its worst kind and I grimace everytime I say it. I will maybe say it 20 times a day and just assume that it means the same to me as it does to others. But it doesn’t. To others it reinforces the idea that people are almost programmed to do what we think they will do. The phrase de-humanizes our audience so much that we creep into habits of making huge presumptions on what they do and how they will do it. The phrase tempts us to be lazy, it tricks us into grouping a multitude of different personalities into one homogenous meld of a human/user. A (huser maybe?).
So what’s the solution? I don’t have one that I am completely convinced by.
One method of humaizing our user’s in this world is to give them typical personalities. These can exist as pen portraits.
‘Suzy is 23 years old and has left university where she studied bio-chemistry. She is a fitness fanatic and is a member of a local running club. She is on Facebook and has 262 friends although she would say that only 20 of them are real friends.’
The idea being that in your test scripts you can relate your ‘characters’ to the journey’s that you set up.
I think it’s probably a good thing for the development team to think about the various personalities the product may encounter – but for the wider team? I think the response might be ‘Who the **** is Suzy?’
So has anyone got any bright ideas? Should we just translate this ad-land speak into simple laymens terms?
Users, Use-Cases, Scenarios, Actions, Interactions.
could translate to…
People, Things that might happen to these people, What someone has done, Stuff you need to do, Stuff you do and you get something back.
It doesn’t quite work does it? It just all sounds a bit rubbish – without any sort of knowledge behind the words.
So anyway – I’m looking for answers so if you have any please follow these user stories:
Scenario:
User Actions:
Admin Actions:
Test complete. Maybe.