This may come as a surprise, but I hate "iteration" with a passion. Like so many other once-meaningful words sacrificed at the design-thinking altar, "iteration" has gone the way of such hollow-eyed corporatespeak as "ethnography", "empathy" and "design thinking". #singletear
Strangely enough, though, iteration is critical to design — not only in terms of productivity but success in general. At least in my line of work it is, anyway. I'm a Content Design Director at Fjord, which means I get to run our studio's content design team and also lead integrated design teams on client projects. Serving as both a content director and a design director helps me look at design challenges from different perspectives; in both roles, focusing on iteration helps my teams do their best work.
In terms of content design, my team collaborates with other designers across the lifespan of each project. Our talented content designers make their fair share of contributions, but some of the most significant activities they engage in are domain mapping and content modeling. The output of these activities informs everything from wireframes and microcopy to visuals and metadata, helping to determine components and patterns reflected throughout any given design language.
The content designers in our studio start to sketch maps and models during the first week or so of an engagement, bringing their rough sketches to the design team to spark early conversations. Over the course of the following weeks, they'll whiteboard together until they have a clear understanding of the objects they'll be designing and building into their solution on the front end as well as the back end.
Warning: this process can get messy. Some content folk (not ours) are... persnickety. Some IxDs don't love the idea of working with "pre-wires" (a clever nickname given to content models by one of our production designers). Some developers might wonder why they need to embrace content models when they already have data models on their mind. Until they actually give it a shot. Then they usually see the value in it.
As a design director, I've been exploring ways to use iterative design in the context of rapid prototyping and user testing in order to validate or invalidate concepts that have the potential to become viable products. My last project is a decent example of that kind of iteration in action.
One of our clients was interested in validating some concepts of theirs in a six-week timeframe, so they offered us the opportunity to give it a go. Using our existing processes as a jumping-off point, our project manager and our solutions architect and I got together and iterated on whiteboards until we agreed on a streamlined approach we felt would get the job done right. After getting buyoff, we put it to the test.
Over the course of three two-week sprints my team of four designers built and tested interactive prototypes — one smartphone and one tablet — for two very different concepts, engaging in user interviews and shadowing sessions up front and conducting additional user research along the way as needed. As you might guess, we moved at a somewhat frenetic pace. More than once it proved difficult to get participants for remote testing lined up in fairly short notice. It was frustrating at times, to say the least.
Our small, nimble team made it work better than we could've imagined. Our testing groups were effective, providing substantial amounts of substantive feedback that helped us improve our prototypes. Our client knew we might run into certain roadblocks because we set appropriate expectations at the outset, so they worked with us to help sidestep potential issues. And by the end of the engagement, our client was delighted with the results and had given our studio a new project.
Btw this make > iterate > test > validate approach we road-tested certainly had its merits, but it was not without its faults. Everyone on the team was super tired by the end of that six weeks, and we wouldn't have been able to accomplish what we did so rapidly without 1) having an amazing team 2) being handed a component library to work with or 3) having a relatively hands-off client. Our team had a productive retro after the project, and I'll apply what we learned here to my next opportunity to implement a similar approach.
All this to say that perhaps we shouldn't relegate "iteration" to the buzzword dustbin just yet. Iteration without proper direction can result in more ambiguity and white noise than clarity and actionable insight. At its best, though, iteration can open teammates up to each other, shake teams out of their routines and help everyone not only understand limitations but transcend them.