I'm excited about recent developments in capturing website requirements throughout the design and build process. Requirements include how the front-end delivers the desired user experience and how that functionality gets managed in the back-end.
These days, we're doing a much better job making decisions about apps and integrations pre-SOW. However, there's still a level of detail that only comes once the project gets off the ground.
Historically, we've waited for a specific point in the process to capture all requirements and prepare tickets for development (in JIRA). This approach can lead to gaps in information, delays in the schedule, or additional time needed from certain team members.
We haven't locked in the new process yet, but I'm excited about where we're heading. Rather than a designated point in the project timeline, we'll start capturing requirements from the project kickoff. We'll capture everything we know upfront, and then, as we go, we'll add to and refine these requirements.
In every internal and client check-in, the team will reference these requirements and ensure they are up-to-date with recent feedback. The end goal is that the website requirements are ready when the designs are signed off. No heroic effort is needed to get them off to development.
We're also talking about how requirements can be as valuable to a client as designs. In that way, we're discussing how we might be able to present requirements alongside designs and require sign-off from the client.
A couple of pieces we still need to iron out are where the requirements live and who owns them. Right now, we're thinking about managing them in Asana, then as they're complete, pushing them to JIRA. Ownership-wise, we expect that our Project Managers and Strategists can own requirements with input from our Software Engineers and Designers.
This post originally appeared in Edition No. 101 of my newsletter. Subscribe here.
Monday, August 15, 2022
