Aquent is a large and successful creative staffing company. They’re able to discover and source talent who are best fit to solve the creative challenges their customers have. What makes Aquent unique is its ability to remain human in the process. They focus on building longlasting relationships with talent and clients that go beyond the (often) transactional experience of recruiting.
For Aquent’s business to function, it requires “orders” — a collection of accurate information regarding a client’s needs. They are the contract between talent, client, and Aquent. An order is filled with an immense amount of information that Aquent agents use to facilitate sourcing and placing talent with clients. Successfully placing talent with a client is called a “fill”. Filling orders is how money is made.
However, Aquent’s teams across North America operate individually, in an infinite amount of ways, to capture, input and maintain order information. This is done using a proprietary platform. The trouble is that any information could be input into this platform, in any form or fashion. This leads to a high volume of orders in, some with accurate and sufficient information, and others not so much.
Users, therefore, spend much of their time manually validating, managing, updating, and sharing information about orders, instead of focusing on relationship building between talent and clients — the differentiating factor of the business.
Our job was to explore and validate (or invalidate) the idea of qualifying inbound order information before actually becomes a workable order in the platform. In other words, help our users determine whether the information they have is accurate and sufficient, earlier in the order workflow. This was the stakeholders’ vision.
As the sole product designer, I worked with stakeholders, a Product Manager and a team of engineers to:
We started by engaging in a series of interviews and surveys with our primary users — agents, Account Managers, and Account Directors. These are the folks who use the platform constantly. They’re the ones who do the work of the business. Talking with them provided a solid amount of qualitative findings and allowed us to formulate some personas and affinity maps.
We then conducted a series of audits around the existing processes our users engaged in for collecting information. This provided insight into information architecture, content landscape, and user flows.
Our research allowed us to surface patterns of pain and concoct problem statements that aligned with both business and user needs. The initial hypothesis that order information needed to be qualified wasn’t entirely correct or incorrect. The challenge, instead, was in how the information was communicated. We found four thematic problems that we wanted to address:
- Awareness of information
- Prioritization of information
- Setting expectations
- Cross-team communication
Through a series of Design Jams, our team arrived at a handful of approaches to solving our four primary problem areas. A Design Jam is a series of exercises that engage the entire team (product, design, engineering) in divergent and convergent thinking.
A Design Jam has many benefits aside from arriving at ideas to explore:
- They bring awareness to the design thinking early on in an agile development process/environment.
- They allow for team members’ unique perspectives to riff off one another, making for different approaches to problems.
- They guide the team to a collective vision that they can champion and advocate for when working with other teams and stakeholders.
- They’re fun! (At least that’s what engineers always tell me)
With the ideas we generated, we were able to wireframe and develop low-to-medium fidelity representations of a tool that addresses our four thematic problems.
This tool, which we named “Requests,” acts as the first step in the order creation workflow. Instead of a laborious process of passing information from one user to the next, using third-party tools, we positioned our users in a space where information can be captured and deliberated on at once, in real-time, collaboratively, and internally. Once it is decided by users, together, that the information is accurate and sufficient enough to be made into an order, they create an order directly from the tool (which ties to the legacy platform for the time being).
Over the next 6 months, we will be observing and learning from our users as they engage in this new workflow. Already, we are seeing positive patterns and receiving good feedback consistent with our proposed solution.
Awareness of information
Requests provide a space for all user types (Sales, ADs, AMs, agents) to collaboratively gather and edit the information that specifically correlates to successful order models. This provides a single source of truth for users to refer to for use and ongoing dialogue. Furthermore, it surfaces client, market, and historical information within the existing platform to help inform users of Aquent’s relationship with the client at hand.
Prioritization of information
The collection of information is done in the form of a web form. Some fields represent key information that should be gathered. Some fields ask questions that prompt fruitful, proven dialogue between users and clients. The fields are presented in a specific hierarchy to suggest prioritization consistent with the value of the information. Furthermore, the information input can be calculated against a learning model that helps predict the success of an order using the information gathered.
Previously, individual teams had their own definitions of what information made for a ‘good’ order. Furthermore, each user type tended to have their own definition of ‘good’ order (i.e. what’s good to sales isn’t necessarily good to the agent). Multiply this reality by x-amount of teams and you can imagine the difficulty in measuring and evolving growth and success.
Requests makes for a consistent, cohesive, and universal format for information gathering. The information it intakes is based on success models and is positioned to help with each user’s specific workflow. Operationally, all teams use requests before making orders, and therefore it has begun to shape how teams operate by creating workflows based on information gathering, rather than output.
The inclusion of a chat module, as well as users’ ability to collaborate in real-time on the form, has allowed users to engage in and reference an internal ledger of dialogue within the context of the information at hand. Furthermore, teams have begun conversing with other teams over information, pulling on expertise, opinions, and experience from peers outside a specific team or market that the client is assigned to.
Aquent successfully operates on the model of using technology to foster face-to-face, human relationships, in a marketplace that is so caught up in speed, volume, and automation. However, Aquent’s approach is difficult to sustain if the technology doesn’t serve its users. What we’ve learned is the introduction of a new tool isn’t just helping users do their jobs. It’s also shedding light on the entire ecosystem of the business. It’s uncovering opportunities for addressing how the company works, not just what the company does.
It’s not just a question of whether an order’s information is accurate and sufficient. It’s an on-going exploration of how an order’s information is being arrived at and what implications that has on its success.