“means of obtaining successively closer approximations to the solution of a problem”
Iterative design possibly isn’t really a thing in its own right, as design IS a fundamentally iterative process: analysing the problem space and context, coming up with solution/s, testing, applying insights to refine. Even just on paper, developing an idea is a fundamentally iterative process. However the iteration that takes place back and forth between design and development cycles is, of course, a thing, and that’s what this article is about. This post explores finding the balance between the minimal iteration approach of waterfall (which yes, still has its place) and the more agile iterative design-code-design-code approach, ending with an example of extreme iteration.
I have worked at both extreme and in-between – on so-called agile projects where even the smallest post-development tweaks and changes were frowned upon, with project managers looking at you in complete disdain, as if the very suggestion was an admission of an abject failure of the design process. To the projects where you co-work with developers, cycling through design-build-test phases at a rate of knots.
Now there are some projects that can be highly iterative and some projects where iteration can (and probably should) be minimal, but one thing I have learnt is that ALL software development need to have some element of iteration – for no matter how thorough the design process, how detailed how considered your specs; you never really get the insight you need until you get your hands on it and start playing. Little confusions, anomalies, unexpected combinations of screens etc. Expecting this to be managed out of the product cycle is naive.
Now clickable prototype Apps are great for getting a feel, and are fabulous for designing and testing information architecture, general interaction and ‘experience’, but for more complex micro-interaction, or if your interaction doesn’t follow an established pattern, they tend to be less useful -or require such an investment of time that you would probably be better off prototyping in code (if you have those resources available of course).
The great value from prototyping is that you get to see an idea manifested, and can poke around and get a real feel for what works and what doesn’t. It’s a really valuable process as it gives you the insight you need to make another ‘better’ version, a version that is a step closer to the final solution. Rinse and repeat…and out of the fog the most lucid solution begins to emerge.
My current project is designing an App which enables organisations and tagging of information from a variety of Cloud and SaaS data sources in one place. The project has relatively limited development resources, so we look to really work through every aspect of every feature in as much detail as is realistic so that we can try to maximise functional utility with minimum development time. In general, we look to increase our development velocity by minimising iteration. However, another big part of the same project is an automated organisation feature based on machine learning. No one knows what it looks like or really how it works. Essentially it can’t be ‘designed’ (we are not magicians) it needs to be ‘discovered’, and this approach will sometimes be resisted by the powers that be, as perhaps it feels a bit free a bit vague (or they suspect that it sounds like too much fun!)
My general conclusion then is that the more standard the problem being solved the less you really need to iterate, and the more novel or unique the problem you are trying to solve, the more experimental and iterative you need to be….which I think calls for a small graph.
In the premium iOS App WeatherGods which I recently completed, there was one aspect of the product, the ‘weather wheel’ which was built in an almost entirely iteratively way. We started with a basic concept and iterated build after build, layer after layer, feeling our way towards the solution. If we had tried to fully design it, it would have been a fantasy that was impossible to code. Prototyping tools were no use as they only really support existing UI paradigms.
The weather wheel was an epic journey over twelve months, but I would like to give you a highly condensed summary. The initial concept was simple – rather than using icons to represent the weather, we’d use textures, background & particle effects to literally show the weather. So, rather than the user having to decode rows of icons, they simply see the forecast as if they are looking out of the window, or at a series of pictures, therefore assimilating the data quicker without having to actually think. We had an hourly forecast for seven days, and liked the idea of a wheel you could spin.
To start, we created seven days and twenty-four hours per day in a wheel with space for the Weather God to sit at the bottom. We also created a zoom function, so we could see the whole week or a few hours. We then curved the text and put in some night and day.
We came up with a clever single finger zoom concept which I was very pleased with, but after we put some test content in the form of yellow stripes for sunny hours (each one cut out in a mask) we realised that we had some major performance issues already – There were simply too many lines to be rendered, so after much debate and testing different variations, we settled on just two zoom levels, and a maximum of twenty-four hours on the screen at any one time.
With performance under some sort of control, it was time to start building up the layers of data piece by piece. Soon we began to run into memory issues again, as a large number of layers began to kill performance. For what seemed like months we would step forward then back – trying different approaches in the code, different ways represent the weather information. Eventually, we made the decision to show a reduced set of layers on lower memory devices so that we didn’t have to compromise on the full vision for devices with over 1GB of memory. Gradually it began to take shape. We added particle effects with emitters, then moving looped images, then back to a different type of emitter, all the time tiptoeing around memory constraint and performance.
There were times when we felt we were stuck in a loop, that we felt we were making no actual progress. It became a labour of love, a bloody determination to get it shipped. Once it became close to being finished on one device, we had to polish it on other iOS devices and in other orientations – ten different variations of a highly complex multi-layered UI – what felt like weeks of tweaking and tuning.
But after over 400 builds, and countless thousands of design decisions, the weather wheel, the only icon free – animated data visualisation Weather App was finally launched onto the App Store.
The Weather Wheel is an example of extreme iterative design, one that was only really possible due to the unique circumstances of the project’s inception and the teams’ determined motivation to make it work however long it took. I learnt much from going through the process, and would definitely approach things somewhat differently now. In summary, if you are building something unique and new, iterative design is an important and useful tool. It’s an exploration, a hunt to track down the solution.