Where the Iteration?
People who design things know that the path to perfection is through iteration. They try a thing out, test it, tweak it, try it again. Depending on what the thing is, the size of the cycles can be minutes or months. Likewise, the number of cycles can vary from just one to the maximum allowed by the constraints. Testing can also be done by the designer or by a likely consumer of the thing. My point is that iteration is the common theme, but there are many different ways about doing it.
A graphic designer may try out different typefaces for a particular layout. This is iteration with the designer performing all the steps herself.
A writer may go through several drafts (iterations) of a piece that he then sends to his editor for review. The editor in this case acts as a tester and requests changes. The writer makes changes and the article is published. And the iteration doesn’t always stop there. A reader may spot errors that will be corrected in later revisions. In this case the resultant work is honed to perfection after being scrutinized by author, editor, and reader. The iteration cycles by the author are implied while the one with the editor is by design. The incorporated reader feedback is optimistically unexpected but still a part of the design process.
Physical goods, too, undergo iterations. A prototype is an intentional first iteration. New models of the same product line are iterations built on previous designs. The size of cycles for physical products is much longer than digital ones.
And then there’s software. Whether your process is considered waterfall or agile or whatever the latest trend, I guarantee that you will find iteration in the process, even if you don’t explicitly plan on it. Let’s say you’re developing something by the waterfall methodology. Assuming you even finish the project, when it’s released, there will be a reckoning. Users will discover bugs or worse, they won’t use your software because it doesn’t do what they want. You’ll most likely have to go through another (painful) iteration.
I believe the best way to iterate is with a version of your product that works. Either a working prototype or a hidden feature. The sooner you do this, and the more cycles you go through, the more polished your software will be and the less painful it will be to make changes. It’s also important to incorporate the end users as soon as possible because they will be the final judges anyway. Live testing existing users provides the best feedback, but be careful what you test and how frequently you test. A constantly changing product leads to user abuse.
Building a product iteratively with small cycles forces you to cut out everything but the absolutely necessary pieces. It requires you to figure out the essence of what it’s doing. This is usually referred to as an MVP or minimum viable product.
The danger of building iteratively is if you stop iterating. MVPs are sometimes used as an excuse for doing a quick and sloppy job, which isn’t so terrible unless you never get around to the next iteration. It gets even worse if you keep adding more “MVPs” to your product suite. This appears to be more common than not as I’ve noticed discussions (1, 2, 3) in the design community around MLPs or “Minimum Lovable Products,” suggesting that we raise our bar for we put out there from not just viable but to lovable.
So the community agrees on building something minimal and doing so iteratively, but just exactly where the minimum bar should be set still seems up for debate. I’ll save my thoughts on that for another day.Written 9 November 2014