The Role of Requirements

I worked on a recent project with very enthusiastic stakeholders. They were very hands on, and we had many long requirements, strategy, and design discussions to come to consensus and take in feedback. Plus, they loved the design recommendations! AND they were on board with the content strategy! As a result they kept our team on as partners well into development. However, as development went on their implementation 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?

Enthusiastic Stakeholders

I mentioned that the stakeholders were completely on board our plan. As a result, we got used to constant communication and discussion. That 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.

Unfortunately, although we discussed requirements along with strategy, we never created a concrete list of site 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 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.

How To Document Requirements

Getting started? Start early!

• Make notes from the start – as early as the first conversations about the project
• Connect broad goals to the detailed requirements that will accomplish those goals
• Have a question? Ask it! Nothing’s worse than realizing at the end of a project that no one knows how the thing should work
• Have those notes “live” on page templates or content templates, so that everything stays connected