The New Normal: Issue Tracking for Design
The new “normal”…
Over the past couple years, our large scale projects have grown in complexity, where a “normal” project may have a front-end design and build period of six months or even more. With these large scale projects, we may have three to four designers and multiple front-end developers working on a project at one time. This growing complexity requires adjustments to our workflows, organization and quality control.
How can our Project Manager (PM) and Quality Assurance (QA) team know what everyone is doing? How can we meet benchmarks, give reliable estimates and maintain accurate communication between the project team and the client?
At TBG, we have found that maintaining a very detailed issue tracking system has been the key to keeping our projects on task and on time (issue tracking is sometimes also called “bug tracking”). Each issue is filed individually in a dedicated software system. It is assigned to one person and proceeds through a predetermined workflow (example: Open -> In Progress -> Resolved on QA -> Approved on QA -> Approved on Dev -> Live -> Closed). Phew! That’s a lot of steps for one issue.
How many emails am I going to get about this?
This may sound suffocating to designers or front-end developers, who have their own workflows and need space to work through complex problems and explore solutions. I found myself quietly resisting the move toward this kind of formalized system. Won’t we lose the quick back and forth we had before? I am going to get how many emails about this? Is the overhead worth it? Change is difficult, but the reality was that we already had a tremendous amount of overhead writing long emails trying to detail why we changed something six months ago in a meeting. Not fun or efficient.
So how does this system actually give us more freedom?
I am going to generalize here. When working on a project, we can divide our time into two large containers: building and QA/revisions. The building phase consists of the actual creation of new designs or templates. We may have a block of hours to create six new template designs with a due date of 10 days. This is our “put your headphones on and dive in” time. The second large portion of our time is spent on QA. This includes fixing bugs, rethinking areas that do not work, resolving discrepancies between static designs and implementations, etc.
The QA phase is where our time and work becomes much harder to predict or document. It is often difficult to quantify how much QA is involved in each project and to identify the priorities. The designer’s priorities may be completely different than the client’s, and there comes a time when we all need to be in sync to get the site ready for launch.
Our issue tracking system provides needed, consistent guidelines as we work through these processes. Our QA team will go through a site and find issues that need to be resolved. Our project manager can then determine when these issues must be resolved and how much time or resources they will require. As designers or front-end developers, our jobs just got a lot easier. We may have a couple pet projects, but our main objectives have already been laid out for us with a deadline. No more wavering over tiny details when we have 10 high priority items the QA team has identified and reviewed with the client.
Freedom from this decision making lets us focus on solving the problems.
What used to be an undefined area of the project suddenly has definition and a timeline. Resolving the real issues actually makes it more likely that our front-end team will get the page to a production-ready state and have the time to go back and add the finishing polish. And more often than not, the little issues clear up in the course of a thorough QA.
In addition to the benefits it provides the project team, the issue tracking system creates a central knowledge base which is helpful for the PM and the client, even more so for multi-phased projects where there is a need for long-term continuity, even as certain variables, like team members, change. We now have an organized list of tasks that give a clear view of actual work remaining. We have the ability to prioritize this work. And it becomes much easier to estimate time and resource needs based on the number of issues logged.
The idea of compartmentalizing our tasks creates intense QA periods where we can make sure our projects are on track. As we complete these QA cycles, we can move into our next ‘build’ phase with clear heads and confidence as we put our headphones back on and dive in again, knowing our project is in a good place and we are free to build on a solid base.
About the Author
Leave A Reply