It's all a part of learnin'
Pick your budgets and words carefully.
There are a few key takeaways from this project. First, our whole team learned the Top Task methodology and it was an extremely helpful way to approach a complete redesign of architecture, menu labels, and page content structure. It provided a meaningful “user first” foundation that put us on common ground with our stakeholders. Government agencies are already serving the people, so this approach was very logical for them to understand and it made our recommendations more meaningful. It also allowed us to tie our research and improvement data to the specific requests laid out in the scope (as shown above). It was very labor-intensive given the amount of time we had. Concessions had to be made in the backlog and discussing these trade-offs with the client was a good exercise in being thoughtful and prepared.
Secondly, clients frequently want the moon and account execs want to land the contract and often cut corners in scoping in order to make it seem feasible to the client. But budgets must absolutely ensure you’re able to set the clients up for success longterm. It is never enough to just “build a website” for a client. To truly improve their experience as stewards of a new ecosystem, you must provide education and guidance for after the site launch. This means style guides for components and content, as well as training on the new platform. They need to know how to maintain the new content model and understand the architecture well enough to guide future changes and updates. Post-launch activities must be considered equally with everything that leads up to launch, otherwise, you ultimately fail users. After the site went live we still had a long to-do list. Everyone pitched in and worked hard to make sure the client felt confident, which was a testament to the collaborative and helpful nature of our team.
Lastly, it took us a bit of time to unify our goals at the beginning, especially when it came to how the project roadmap would unfold. We knew we wanted to avoid a waterfall process. While the team agreed that an agile workflow would have been ideal, I knew the client wasn’t familiar enough with agile to be able to sell that to the rest of their team effectively. In a client's mind, a new website generally means an expectation of a "hard launch date." We spent a lot of time in discussion with them discussing what kind of release approach would work best. In the end we did a kind of “wa-gile” approach and had to operate tri-lingually. Internally we were speaking in agile-like terms. Our point-of-contact was comfortable enough with the concept for us to use some of terminology with them in our weekly check-in. But when it came to their immediate ecosystem in the office we had to support them by speaking more plainly and talking about the launch as a more specific event. This was a great lesson in knowing the limitations of your client partners and being able to meet them where they were, and still maintain internal project integrity.
