A few years ago, I was working on a project that was easily the most complex interaction design that I or my team had ever worked on. It was filled with “interesting moments” where timing, feedback and responsiveness were absolutely critical. The team had been used to a fairly typical design and development process. A PM would set the scope, a designer would create static wireframes, iterate on them a bit and then deliver final designs to development that were not supposed to change. These were the final designs, after all.
We had recently adopted Agile development and so the question for me was, when are you going to “get to done” on the design? My answer was honest but, at the time, not appreciated. I said:
A design is never done, it only approaches done. *
I knew what the reaction would be — What the hell are you talking about? Something is either done or it isn’t! We’ll never ship! You’re going to ruin everything!!
But I still stand by that statement, even more now than I did then. It is foolish to think that you will get the design right the first time. It is also foolish to think that there won’t be changes to a design once development begins. And on a larger scale, software products are never done unless they are dead. Life is better when you stop kidding yourself and your team and admit that there is no “done”.
As a design manager, I use this concept of approaching done to evaluate the health of a project and the effectiveness of its designer. A designer is on the right path when his or her solution is approaching done. In the early stages of a project, there is typically a high level of variability. Designs may appear to be approaching done only to get completely reset once a new requirement or constraint is encountered. This is completely normal. But over time, this variability should become smaller and smaller. That is when you know a design is on the right path. There is a steady progression toward done.
* This idea of approaching done was inspired by some bastardization of what I remember from calculus class and the limit of a function. It may have come to me in a fever dream.
There are some compatible ideas in the Lean UX arena. If you’re interested in learning more, I suggest checking out the following sources: