How Pigment implements new use cases in our internal Workspace

When Pigment needs to build a new use case in Pigment, here’s what we do.

At Pigment, we are, of course, big Pigment users. Almost everyone at Pigment does at least part of their day to day job inside Pigment, because we understand the value of having all our planning and analysis in one powerful platform.

But when we need to scope a new use case, what do we do?

Because we have so many use cases within our Workspace, we like to be thorough when scoping a new one. And recently, our People Team decided to bring their headcount request processes into Pigment. 

The use case

Within the People Team, our Talent Acquisition team works hard to fulfill headcount requests from across the business. However, it can be time-consuming and difficult to keep track of outstanding requests and their approval status.

The desired process flow, which is very similar to what many of our customers implement, was:

1. Team lead inputs new headcount request
2. Finance is able to see the details and approve or deny the request, including reasoning
3. Approved requests are passed into Lever, the recruitment platform we use
4. Hiring status is then passed back into Pigment, where team leads can view the status

One important requirement, which adds a bit of complexity, is the ability to track position history. For example, if someone is promoted or leaves, sometimes their vacated position shouldn’t be filled exactly as before. Maybe a more senior or more junior hire is required, or perhaps no backfill is required at all. That history is important to retain so we can understand how the headcount need has evolved over time.

Here are some of the considerations that helped us build this use case effectively:

1. We obtained clear requirements from executive stakeholders

The first time a new platform is implemented, executive oversight may be necessary. But for subsequent use cases, it’s usually sufficient for those executives to give their requirements and review at key stages. In the case of this particular application, our stakeholders were happy to provide the People Team project lead with their requirements up front rather than being directly involved.

For help with requirements gathering, click here to access our User Profile template.

2. We designed the use case fully before any modeling started

When your team is enabled in Pigment, it can be tempting to go in and start building straight away, using that experience to guide your decision-making as you go. However, designing the use case in full allows you to spot potential roadblocks and ensure the process will fully meet the defined requirements. No matter how many applications or use cases you implement, having a separate design stage will always benefit the end result.

3. We mapped the entire data flow, both within Pigment and outside of it

One of the benefits of that separate design stage was that we could map the entire data flow. This included data flowing within Pigment (meaning sharing Blocks from other headcount and finance applications), data flowing between Pigment and Lever, but also data flowing between Lever and HiBob, our HRIS platform. Even though this data flow happens outside Pigment, it still impacts the use case, and therefore it’s still important to consider during design.

4. We struck the right balance between automation and good friction

Pigment is a powerful platform, and it can be easy to try to minimize conversation and deliberation wherever possible. For some parts of the process, this makes sense. However, there’s something to be said for good friction. When the needs of a TBH position change, we decided to allow that conversation to exist instead of trying to model for every eventuality. This kept our model clean and easy to maintain, and introduced good friction to make sure the TA team is able to gather all the required context for the recruitment process.

5. Dashboarding was considered from day 1

One of the most important parts of any use case is the dashboarding, and our Boards were a key part of this use case. It’s where team leads would submit new requests, finance would approve them, and updates would display. For that reason, our Boards were considered throughout the design and build phases.

6. We involved the end users in testing

While most of the design and build happened within a small project-specific task force, the TA team and select team leads were brought in for testing. They were able to confirm not only that all initial requirements were met, but also that the user experience was intuitive and effective.

7. We revisit the use case when new functionality is released 

Because this use case was implemented earlier in the year, there have already been several updates of note, such as automations, which have warranted revisiting the use case. While all use cases should be updated periodically, major product updates should trigger a review of any relevant models to see if they could be improved or enhanced.

Ready to scope your own new use cases?

We love to see customers building out new models and use cases after their initial implementation. The same launch resources that we share during your Design & Build phases can be used for any new use case, so bookmark them for your next build!