Why Iterative Design?

Someone recently asked me “How much time have you usually allotted to paper testing?” I guess I don’t think about it as a process where I allocate some portion of my time to sketching, and another portion dedicated to making prototypes followed by high fidelity comps and production assets. Working that way feels too much like a waterfall process which assumes an orderly progression from concept to product. As a convert to Lean Startup thinking, I know innovative software products don’t come from a predictable and orderly process. As we make things and show them to customers we often learn that we must change the design of the product at a conceptual and structural level, as well as the surface level. How can we create a flexible design process that allows us to keep moving forward fast while allowing course corrections to the design along the way?

Pick the right technique for your situation

In my practice, I’m working with many different design techniques (solitary and collaborative, low and high fidelity, physical and digital, at a general and detailed level) throughout the project. I consider the problem I am trying to solve and the kind of feedback I want to gather and choose the method that works best for the situation. In any given week, I might be working on and showing customers: the live product, a generically-styled mock up with fake but realistic data, and a paper prototype as well as using sketches on paper or a whiteboard to think through problems and communicate with my team. Of course, earlier in the project before we have working code we’re using paper and mocks more, but that doesn’t stop once we have a live product. We use them all together as needed.

Three examples

Here are three examples of teams using different methods for iterative design which suit the needs of their team, product and audience.

Carbon Five

Disruptive Innovation using Agile Development and Lean UX
In this blog post Courtney describes a weekly cadence where a balanced team of product owner, designer and developers’ priorities are guided by feedback sessions every week on Friday. In the sessions, the team first shows the working product to potential customers to validate it meets the objectives of the week’s experiment. The pictures in the post show a technique the team used to explore areas where the customer didn’t understand the product. They printed out graphical elements from the product, taped them to a whiteboard and used markers to draw other UI elements. That way the team and the people giving feedback could collaborate on alternative presentations and behaviors quickly and flexibly and save time coding. Cortney presented more information about working this way at the Lean UX NYC conference in a presentationa called Blending Lean UX and Agile Development.

AppNexus

Behind the Screens: the Making of Campaign Monitor

Suzanne from AppNexus describes how her team used a designer/developer pair and iterative design methods to share an initial concept with users and evolve towards a successful solution. Note that the team had an idea going into the project that was not validated by the users. Through multiple iterations, showing things to users and getting feedback, the team eventually found a great solution. Also note that these technical users required realistic data before they could provide specific feedback about the concept.

Heroku

Design of the Status Site

In this project, Mark and the Heroku team used a prototype built in the Sinatra framework, using spaghetti code and inline styles, with read-only access to a live database.

So remember, it isn’t about the technique you use, it’s about the learning you want to gain.