You are here: Home » Archives for sprint

Tag Archives: sprint

Poverty Over – A Case Study, Part 3 – Building

Written by Andy Weir. Filed under Blog, production, project management, Review, work. Tagged , , , , , , , . 37 Comments.

In my previous post I talked about entering the build stage of our project without a complete plan over what the final infographic was going to look like or how it was going to behave. That might sound foolhardy and naive to some, but for W+W we start each project knowing that a voyage of creative and technical discovery awaits. With a project as intricate and as complex as this – uncertainty in initial planning actually serves the creative process better. It allows us to make discoveries and react to them based on creating working prototypes and versions, rather than second guessing the outcome of a myriad of variables.

At the start of this stage – the client was happy with where we were – but were naturally concerned that nothing looked very ‘Christian Aid’ yet. And for good reason too. We had purposefully left the style guides on a shelf gathering dust. It was time though to start tying together our initial ‘look and feel’ designs with the actual graphic style of the Poverty Over campaign.

For the build of this Infographic – we worked in weekly sprints. Each week I presented the development work to both the Agency and the Client at the same time. Credit to Tyrone at BMB who allowed this to happen and massive credit as well to Tom, the Christian Aid Marketing Director who entered into this agile spirit of things with much enthusiasm.

What did this weekly review mean? So what if there was one? You might be asking these questions….

Well -it meant that each week we would review our progress and look at our accomplishments. Where the infographic was working, where it wasn’t, why it wasn’t. Each week I would take the team feedback and then reprioritise the tasks and features that we would work on in the next sprint. I didn’t use the words Agile much and I didn’t force the idea that this was a revolutionary way of working. It was simply a weekly review of where we were at, albeit presented to the entire team as one and with a clear agenda.

In the background myself and the team were constantly working out which were the most important areas to focus on and in what order to do it in. The entire creative process felt fairly organic – but was underpinned with structure and good organisation.

As the sprints rolled past we rolled through the following features in this prioritised order:

1. Creating a palette and look and feel that a) allowed the user to read the data in the clearest way and b) was on brand for christian Aid.
2. Working out what to do with data anomalies – what happens when a country is missing data for a few years?
3. Working out what to do with countries that had changed borders, names, had been split up or merged? I can tell you a lot about history now that I didn’t know before this project!
4. How much tilt and ’3Dness’ is needed? Does the user need to spin the map a full 360 degrees?
5. How do we display contextual information? This ended up being the timeline pop ups that display key dates.
6. Do we show the future? Can we predict it? What is Christian Aid asking the user to do?
7. How else can I filter the map? We built around double the amount of filters that currently exist on the site. In the end we decided that some were simply too complex for the user to get their heads around. Sometimes less is more!
8. Allow the user to zoom in and study the detail closer.
9. Allow the user to move the map around the page.
10 How to represent scale? (One of the lessons we learned from our research is that a map must always have a scale)
11. Create an intro movie that introduces the concept
12. Create an intro movie that mimics the data and displays the correct poverty levels

There were of course many other themes and features that we worked through each week. The reality was that we were always focusing on the most important or most risky issues. As weeks went by – so many answers kept falling into place, not by design, but by discovery and by a repetitive and sensible approach to experimentation.

In the next and final instalment of this case study I will talk about our final delivery of the Infographic and all of the other elements of the website that supported it.

Poverty Over – A Case Study, Part 1 – Thinking

Written by Andy Weir. Filed under Blog, production, project management, work. Tagged , , , , , , , , , , , . 200 Comments.

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.

 

Dedication. The only way to work.

Written by Andy Weir. Filed under about us, Blog, Future gazing, production, project management, work. Tagged , , , , , , , , . 19 Comments.

We’ve got lots of pretty big projects on at the moment, all quite varied and all for very different types of clients. We’re hoping to be able to share some of the stuff we’re doing very soon on this website, so stay tuned kids. Exciting times for WEIR+WONG! In the meantime, I have a fantastic and revealing insight into the way we are are working. I guess that nobody has ever thought about this before, let alone implemented it, so please hold on to your hats. Ladies and Gentlemen I give you……… dedicated resource. Tada. Booooooooooooooooom. I thank you.

At WEIR+WONG we have been working with some fantastic designers and developers. These guys are simply the best in the business. They uber-rock. We have allowed them to rock harder by simply giving them one job to do on a day by day basis. No daily interruptions so they can just have a quick think about ‘this other project’ or upload some changes for something they didn’t do in the first place. Robin and I are producers that like to protect our team from interruption, and dis-information.

Why is this a revelation? Because we know that from speaking to and working with other agencies resourcing is a nightmare usually based around booking up 1 hour slots. An unmanageable task for the poor resource manager and a false economy anyway. The way forward is one job, one day per any one person.

How do we do it? It’s quite simple really:

  1. We book resource per job and not based on a bunch of time that can be used up on a multitude of different projects.
  2. A morning scrum. What did we do yesterday, What are we doing today, What’s stopping me do it?
  3. An open channel of communication throughout the day with the rest of the team. Don’t go to the producer if you need a design asset. Speak to the designer. Remember that building complex stuff should always be a conversation between creatives and techies. If it isn’t then something is wrong.
  4. Limited interruptions from producers. Save them up for the next Scrum.
  5. A prioritised list of functionality and features. If you finish something early, get working on the next bit and don’t ask anyone for permission.

So what benefits have we seen. Lots. We can’t think of any negatives either.

  1. Creative people have the head space to think laterally and focus on the proposition and user experience. We don’t really care when, where or how they arrive at the solution. In fact we trust them to arrive at the solution, and we seem to be finding better solutions faster these days.
  2. Technicians and developers can get themselves in the ‘coding zone’ without interruption. We’re being delivered better, more robust code that is tested and clearly has had more love given to it.
  3. Client and agency feedback is turned around much quicker. We can react quicker to change and produce more robust and thought out solutions.
  4. People like working with us. Their day is less stressful.
  5. We like working like this. Our day is less stressful.

But I guess that everyone knows this already. It’s pretty obvious that dedicated workers can only be a positive thing. So what gives with my sarcastic take that this is a new insight. Well, if you aren’t doing it yet it is a new insight. And most agencies and production companies aren’t.

This can change. Believe.

When can change happen?

Written by Robin Wong. Filed under production, project management. Tagged , , , , . 24 Comments.

left a bit, right a bit
I just read an interesting article over on lifehacker about putting the brakes on ideas at certain times during the production process. You start a project, come up with some great ideas, focus on the best, start work on bringing those ideas to life, and then along comes an idea that you wish you’d have thought of in the first place. What do you do? Drop tools and replan? Ignore this distraction for now and address it at a later phase?

Well there’s obviously several schools of thought, but 2 things are clear. First, great ideas should never be dismissed, especially if they add more value to the end user. Second – and this is the counterbalance to the first idea – change is only worthwhile if it doesn’t reduce the overall value of what you’re trying to achieve. If changing course and incorporating a new idea means you can’t realise all the other great ideas you had because of all the extra planning and changes you’ll have to make, then clearly park it for later.

The next conundrum revolves around the question “when is it a good time to change”. For an agile project, I would argue that embracing change is a central part of how one approaches a project, but this does not equate to having carte blanche at any time to throw new ideas into the ring. For me, if you’re using a sprint model, then at the start (or possibly end) of each sprint, the team should evaluate their priorities and decide what is going to add the most overall value. Until the next sprint, the team should stay focused on achieving these priorities. Any ideas that pop up, can be parked until the end of the sprint, when they can be considered by the team again.

There will always be exceptional circumstances when this isn’t the case, and you may need to down tools to investigate if you should change course, but I believe those situations should be kept to a minimum. I’ve seen teams change course all too quickly mid-sprint, to the detriment of the project and the morale of the team. Waiting until the end of a sprint is often a short period of time, and if it doesn’t come soon enough for the impatient, try a shorter sprint on the next project.