Design Definition of “Done”

“A contract is a contract is a contract!”
—Ferengi Rule of Acquisition #17

I’ve almost lost count of the number of times I’ve gone to Agile training workshops. As we all know, no company ever implements Agile quite the same way, and almost nobody does it the “orthodox” way. Regardless, Agile is an engineering-driven approach to project and product management that unfortunately has very little to say about design. There are always benefits and tradeoffs to any implementation of Agile. In some cases, I think it works quite well, but expectations always need to be set up front.

One of the things engineers are often asked to do in Agile workshops is to collectively come up with a definition of “done” which they agree their work can be evaluated against. I decided that this document is good practice for designers to adopt as well, and then to share with the engineering teams they work with. I’ve done this at the past three companies I’ve worked for and I think it does a good job of promoting alignment across PMs, designers, and engineers. This is the most recent one.