Echo & Co. analysis & requirements process.
Echo & Co. (which was Echo Ditto when I got the job offer and became Echo & Co. just before I started working there) has long done creative, innovative digital work for non-profits. When I came on, a lot of things, not just the name, were in transition. UX and content strategy were becoming the core foundation of the business, and campaigns and communication strategy were on the way out.
One of the challenges of this shift was that the experiences were getting richer and more complex, but there wasn’t an established way to translate those experiences quickly and efficiently to the developers to build. Wireframes or designs and IA would be handed from one team to the other, usually with some informal transition, but that process differed from project manager to project manager. That often resulted in websites that came out a little bit different than what the UX team imagined and even misaligned with client expectations. We needed a replicable, uniform process that would leave no ambiguity or room for error.
With a background in content and Drupal site building, and by then having worked closely with both the UX and technical teams as a technical project manager, I was tapped to try to find a way to bridge the gap.
Starting with wireframes, I broke the experience into manageable chunks, thinking about how each piece of content would be constructed in the backend. Each content block became a component, with pages and pages of wireframes all marked with boxes and component numbers.
Next, I sat with the UX team and reviewed how they envisioned each component working, focusing on what they had discussed with the client, the purpose of each section, and the types of content that would flow into each area.
After digesting that info, I built a component definition document, where each component was outlined and explained, and then each page (usually aligned with a content type) was defined by the components that appeared on that page. Then I sat with the development team to review each component and page. These marathon sessions included making technical decisions (let’s use nodequeues for that, blocks for that, this needs to be its own content type, etc.).
That rough process became the foundation of a system that we would iterate on over the next year. That first pass was a good step, but things were still falling through the cracks, especially when it came to how clients expected to be able to manage the content.
The next major iteration of the process included breaking up each component even more and defining the fields and field types that would be needed to support each of them.
And we kept iterating. We set up a flow via Zapier to tie the components we were defining in a Google Sheet to tickets in Jira so they could be built. We established a hierarchy of ticket types for producing the different kinds of things that needed to exist, from the content types, to the components, to the page templates, to the taxonomies. Everything was fully articulated and, thanks to full-team walkthroughs of the component definition process, understood by everyone on the project.
The new process was a joint effort and informed by everyone in the company as they worked their way through it. We adapted and changed until we had a process that would work for the highly complex, experience-rich websites we were building.