I worked on a recent project with very enthusiastic stakeholders. They were very hands on, and we had many long discussions to come to consensus and take in feedback. Plus, they loved the design recommendations, they were on board with the content strategy, and as a result they kept our team on as partners well into development. However, as development went on the implementation of our design didn’t quite match our expectations. Over time, larger and larger issues became apparent, and by the time the dev team was ready for launch, we designers and strategists were feeling disillusioned about the entire process.
What went wrong?
I mentioned that the stakeholders were completely on board our plan. As a result, we got used to constant communication and discussion with them, which kept us all on the same page throughout the design process. When a new development team joined the crew, they had months of discussions to catch up on, which they gamely attempted.
Unfortunately, the one thing we neglected to share with them was a list of the site requirements specifically identified as “requirements.” Our requirements were clear (we thought) from the mockups, the notes, and the best practices we had shared with them, but without a checklist of requirements (labeled as such), the dev team felt they were lost at sea. They didn’t have the time to learn what we had spent close to a year working on. They needed something streamlined and obvious.
And did I mention silos?
There was one other factor impacting our developers. After we attempted to catch them up, they shut themselves in a separate room to do their work. If there had been any hope of catching them up on all our learnings, it was completely lost at that point. By isolating themselves, the developers thought they were helping with concentration, but really they were shutting themselves off from knowledge and context.
Unfortunately, we can’t always stop people from siloing themselves. And so my lesson’s learned: collaboration is a huge benefit to creativity, but it can’t replace requirements. Documenting requirements is often all that stands between a brilliant project and a could-have-been-brilliant idea.