Why Design For Feedback (DFF), why not design to finish, it needs to be finished sometime?
When I first arrived at my current employers, I found some digital designers would pick up a design project at the beginning of the sprint and demo it at the end of the sprint to the product owner. I remember seeing one piece of design work being finish and demoed three times in a row. This meant that three weeks later the designers and product owner were getting frustrated with the lack of progress.
Design for feedback was the key, using white board rapid sketching we created a visual conversation with the product owner. This allowed both the Agile team (Dev, Design, IA etc) and product owner (client) the opportunity to build up a conversation around the problems, the solutions were discussed and visualised through rapid sketching on the whiteboard.
Capturing the white board scamps, we then started creating low fi designs, with the aim of discussing the evolving designs every 2-3 hours.
Remembering that we were still designing for feedback we took out the unneeded complicated design elements and the Design For Feedback process evolved from low fi designs to polished ideas.
This constant Design For Feedback process kept evolving far after the site pages went into user testing and then live. Every day the pages were live they were giving valuable user insight back into the evolution of the living pages.
In a nutshell Design For Feedback added value by improving communications and speed, whilst reducing design waist.
Also see continues delivery