How do you quantify demands on your time?

Northern Trust needed to establish a formal process to track the demands on the design organization’s time and begin planning more strategically.

Background

As the value and importance of the design organization grew exponentially at Northern Trust, so did the demand for support. Senior Leadership was fielding requests from the business team often in the form of emails, comments in meetings, or teams messages. These requests would often get lost in the shuffle until it was time for the work to begin.

The Solution

Working with our design leadership team, I created and launched a Microsoft form to help gather the support requests. The form, which could be filled out by the individuals making the request or anyone in the design organization who received a request, created an item in Microsoft list, which was reviewed on a weekly basis.

By reviewing the requests at the organization instead of team level, it allowed us to be more strategic about the work and see where there are connections across business units. It also allowed the leadership team to review support requests in detail and see if it makes sense for the internal design organization to support a request or for an external vendor to take it on.

 

Project Details

Team: Myself

My Role: Design Operations Lead

Time: 3 Weeks

In This Case Study

  • Overview

  • Intake Form Details

Intake Form Details

The form was divided into two sections–basic information and design risk.

Basic Information

Basic information was all the key details about the feasibility of the project. These details included the business unit, funding details, timing, and the type of support they needed.  

Support was categorized by the type of problem they were solving instead of what capability (e.g. Defining User Experience instead of Design). This was a conscious decision to redefine the design organization’s relationship with the business from agency to long-term partner. It also gave us leeway to help craft the right multidisciplinary team for the need.

Design Risk

Design Risk is based on a rubric I developed in 2020 to help an agile team ,where I was the Design Program Lead, with PI Planning. It asks a series of questions to help determine the likelihood and scope of the support you’d need from the design organization by asking about:

  • Last time a feature was designed

  • Primary Use (internal or external)

  • What key client feedback is

  • How core to the client or partner workflow

  • Plan for the technical architecture (reuse or rewrite).

By understanding the size of the risk, we can make sure we have an appropriately sized team in place to:

  • Establish an appropriate partnership with the program

  • Have a rough estimate of lift for the program to resource an appropriate team so we don’t burn anyone out

  • Change the conversation with our enterprise partners from “I need x designers/researchers” to what problem needs to be solved.