Designer-Agnostic Approach

What is a designer-agnostic approach? Essentially it's a plug-and-play mentality where any designer on the team can pick up a project and continue to move it forward.


I know that there are about a million questions that come to mind when reading that.

  • How will a designer know what jobs they should work?

  • How will the designer know what to do within an assigned job?

  • Or who to talk to when they have questions?

  • Or what's been happening with the task to date?

  • How are files shared/kept up to date?

  • How do you keep track of the latest version?

  • And many more...

Before I answer all of these questions, I want to start by giving some background on how I came to this solution. When I took ownership of the Parsons Federal design team, I was severely short-staffed and impeded by a lack of processes and workflows. We had an impressive amount of work coming in with unknown competing priorities. Additionally, the design team was restricted by a process that locked them into a project through to its completion.


To add another layer of complexity, I wasn't given an increased budget for new staff or software. My first task as Design Leader was to get my arms around the situation and develop a plan to fix this.


My initial task list looked like this:

  • DON'T LOSE ANYONE

  • Develop relationships with the team and gather pain points

  • Build a relationship with leadership and gather pain points

  • Reach out to all Federal units to start building cross-functional connections

  • Map out current processes/workflows and validate

  • Research available tools/software that the organization already possesses

  • Create new processes that utilize existing tools

What I learned:

  • Prioritization was operating under the "squeaky wheel" approach

  • Design requests were coming in via email from everywhere

  • Team members were completely unaware of each other's workloads

  • No version control or tracking was in place

  • No brand guidelines for any team deliverables

  • Atlassian tools were at my disposal

I was somewhat familiar with Atlassian's Jira and Confluence. I had led or been a part of several engineering projects that used these tools in their agile workflows. I started by prioritizing my findings into a new checklist:

  • Create a single entry point for all requests

  • Use a system that allows me to prioritize these requests and distribute them to the team

  • Give team transparency into what others are working on

  • Give management transparency into our workflow and tasks

  • Create a methodology for version control

  • Standardize our deliverables to meet brand guidelines



Looking at the list, I figured out that Jira would answer all but one my checklist items.

  • Single entry point: All projects have an Epic. Epics include all high-level information needed to complete a job. (links to shared resources, project scope, relevant files, job numbers, restrictions/requirements, key people, deadlines, etc.)

  • Prioritization: Job tickets are created directly within Jira by the requestor and automatically put into a backlog on the Kanban board. An email notification is automatically sent to notify me. I prioritize that board as needed to ensure delivery schedules. Because the Kanban board is prioritized, my team knows they can take the top job in the queue. Tickets contain all communications and file iterations related to the ask. This workflow allows any team member to grab any job and advance it, even if it was originally created by someone else.

This doubled our productivity overnight!
  • Transparency: Jira tickets are visible to all parties involved. A few benefits of this level of transparency are include utilization tracking, visibility into workloads across the team, project clarity to leadership, and problems are quickly addressed.

  • Version control: all deliverables are tagged with the associated Jira ticket number. Tagging allows us to track all deliverables, see version history, and create a repository in Confluence with previous outputs that we leverage for new tasks.

The Jira workflow has been through a few iterations and there have been new processes added, but for the most part this solution has really withstood the deluge of work we've received. The team has since grown and the Kanban board has easily expanded to accommodate the work. With regards to the last item on the checklist (brand alignment), I'll write about that another day.