Procore: Tool Onboarding, Kickoff

Summary

At-a-Glance	ㅤ
Company	Procore
Role	Senior Product Designer
Project Length	3 months (October - December)
Team	Product designer (me); one product manager; two content designers; three developers
Year	2023

Procore is a construction company that offers over 40 tools for general contractors, subcontractors, architects, and even more users: it’s a one-stop shop for ensuring physical structures can be built, from pre-construction to payment. The digital tools in Procore allows building to be speedier than ever, but the user flows lacked onboarding.

👀

At-a-Glance: The Kickoff project was intended to improve customers’ first 90-day experience with their new Procore account, projects, and tools. It spurred the creation of a template and a series of onboarding layouts currently being tested live, using new components that will eventually be added to the Design System. We saw a 3-8% lift in our customers completing relevant onboarding tasks within the first 90 days across a variety of tools within the same category.

Background

With a variety of tools, it’s no wonder Procore is helpful to construction sites worldwide. However, our product partners and support team agreed that there were far too many customer support calls that occurred after new users signed up with Procore.

💡

The reason for the confusion: What Procore had in variety and complexity made it difficult to know where to start. Empty states were truly empty and offered no recourse of how a user could get started with Procore. With no guidance, new users needed to delay action, and many preferred to call customer support to get them set up.

The Problems

Two business problems were observed, which coincided with very real customer pain points:

Difficulty in set up means less customer value gets delivered up-front, which leads to a higher likelihood of churning: It’s not easy to set up Procore, especially for a new user. Set up is labor intensive, and users generally don’t see value until 5-6 months after they create an account.

Customer support needs to offer assistance to all levels, when they could be reserving white-glove service for customers who pay more: Providing customer support for new accounts that haven’t necessarily proven that they’d convert to paid accounts means fewer customer support representatives.

The Goal

🎯

My role was to design the first phase of the onboarding experience for the Project Management Tool category to prepare for user testing. To do this, my team and I also worked on a template that could be utilized throughout all the tools in that bucket. This template would allow our developers to build the first iterations for testing performance with a smaller audience. Each iteration had the potential to have more design work done on it as we worked through supporting the tool.

The Solution Explored

We settled on a self-help onboarding flow that utilized cards and CTAs to guide first-time users to the appropriate tool. The templates were used for Project Management tools, including Drawings, RFIs, Specifications, and other related tools. They were built according to some of our more pressing engineering constraints.

✨ Pride Point

The design system team was temporarily split up for this project due to an influx of growth-related projects that were newly prioritized. Having worked in several types of companies varying in size and resource availability, this was a familiar turmoil. In addition to the pressure of growth, our team was faced with a myriad of engineering constraints. No one party was truly happy with their work; we all had to buckle down to do the best work we could with what we had.

That said, our struggles didn’t go unnoticed: in every meeting, I made it a point to vocalize that we were accepting a lower standard of UX with the understanding that we would be given the resources to bring up the SUS score. Eventually, we were granted more engineering and research resources, allowing us to prove that the Onboarding feature was already showing promise, even in its primitive state. The project continues today, working toward a more sustainable and even more usable solution.

The Design Approach

The Onboarding feature had been green-lit in an effort to reduce churn and customer support resources for new Procore users.

As a larger company with an even larger backlog, this meant that Procore designers needed to be prepared to take on different projects at the drop of a hat. Our design system team had been recruited to help in these efforts.

The problem: Reviewing customer feedback from construction specialists, sales calls, and past user research efforts revealed that new users had a lot of trouble setting up their Procore instance…and even after implementation, understanding what to do next in the massive app was not easy.

These quotes came up in feedback collected by our product partners and subsequently came up in All Hands meetings to reiterate the severity of the user problem.

Implementation is difficult. On top of that, even after implementation, it’s not easy for a team to get up and running on Procore.

💡

There are several education channels available, but one of the core tenets of usability heuristics is help and documentation. While Procore certainly boasts detailed documentation, there were little to no in-app moments of help that could aid a struggling user through the flow.

My responsibility was to follow up on concept planning and execute design, content, and spec work to handoff to our engineering partners.

The team started the project with an onsite; after a round of org shuffling, the responsibility of executing the first phase of the project came to me, and the original team was needed elsewhere. I reviewed the notes and concepts from the onsite as well as the handoff notes, and it was time to begin.

📷 Onboarding had two separate paths, both of which were being designed and tested: Project Onboarding and Tool Onboarding. Knowledge in both projects allowed for understanding the constraints and directions that would later lead into Tool Onboarding.

Prior to the Tool Onboarding work, I worked on 18 different UI concepts and 6 different layouts for Project Onboarding, which would chronologically take place before Tool Onboarding.

📷 By the next couple of sprints working through design systems projects, I was then recruited to execute on Tool Onboarding, which followed a different pattern from Project Onboarding.

Project Onboarding would ideally take place after Account Setup and would lead into Tool Onboarding, depending on the tool the user needed to set up.

For example, a Project might only need to have the Drawings Tool set up, but won’t need to worry about Submittals or RFIs til much later. Using Jira as an example, setting up a Project is closer to setting up a milestone or an epic; setting up a Tool is probably closer to the tickets within an epic.

Here’s an example of the two types of Onboarding in their final states:

📷 My goal was to create interactive onboarding elements that would live within an always-accessible side panel. Since many of the tasks were not simple checklist items, several design iterations were explored.

Taking a look at the Procore support hub, it’s clear that there’s a lot of detail that goes into it. Realistically, though, how often do people read through a support page before they start their journey into a service they’re using to make their lives easier? On top of that, each Tool had its own “user manual”.

The reality is that we were asking far too much of our customers from the get-go, when the app should act like a hotel concierge, helping people get to where they needed to go so they could actually feel like they’re getting value out of Procore.

Early iterations utilized aspects from the checklist concepts in Project Onboarding, but so much of the Tool setup had several steps to get through before something could truly be called “complete”. Plus, there was a lot to say that couldn’t fit in a simple checklist. Eventually, we opted for a specialized Card.

The team ran into a myriad of engineering and time constraints, which forced the iterations to evolve.

As the Card design continued to solidify, the moment when the team realized we’d have some major hoops to jump through became apparent: we didn’t have a dedicated backend team, which I hypothesized would have a negative impact on the user experience.

Based on usability heuristics and several design standards found through studying other onboarding flows, the most ideal path would be a set of cards that could act as an action item; it would also automatically detect when the action has been completed.

The card would then, ideally, resolve itself the next time the user opened the onboarding panel.

Unfortunately, without a dedicated team of backend engineers, we learned that an auto-resolve would take a lot of heavy lifting, along with a backend structure that we didn’t have built.

After meeting with my engineering partners, we learned that because this was meant to be an MVP, so we didn’t have the resources we needed to create any kind of automation, even though it looked simple. The fact of the matter was that we didn’t have a backend structure to support the ideal “completion” path.

Remembering that this would be the first iteration and an MVP, and the goal was to get actionable feedback from customers, the team and I created a set of cards that displayed what needed to be done, but would also need to be manually dismissed by users. We had to accept that this was a “for now” situation, and if we had more resources in the future, it would be an easy fix.

The hardest decision to make was having to negotiate the design down to a more primitive format: users would have to manually dismiss cards that they had already completed as a part of the onboarding process.

I stated my concerns:

Asking users to manually dismiss onboarding cards for a process that is completely new to them goes against the usability heuristic of recognition vs recall. How could we ask them to think about which part of the process they were on when they might not be able to call up the side panel again?

Some tasks could take the users out of the main Procore app, which meant they couldn’t track the status of the task they were taking on. Visibility of system status is literally the first usability heuristic listed in the original 1994 Nielsen article.

Some of the buttons wouldn’t go straight to a page; others would open a modal. How would this affect the development side?

I was met with the same answer: this is an MVP. Understanding our position, I rallied around my developers and sought to design something that would be technically feasible, ensuring the concerns were logged so that the team could potentially fix it in the future.

After collaborating with the developers to iron out the constraints, I designed the final spec to be used for the interactive card design. This effectively created a template that would be used for the rest of the Tool Onboarding project.

The first Tool to receive the Onboarding procedure was Drawings. We had a backlog of all the other tools within the Project Management suite, and the plan was to apply the same designs for each so that we could test them all at once.

When you ask a design systems designer to create reusable designs, we deliver. Working closely with the developers, I created a spec that would act as a template for the rest of the Project Management Tools.

With the template and specs delivered to the engineering team, the content designers could work independently from UX. I specifically designed the Figma template so they could easily replace the text or utilize annotations to direct developers to the correct copy.

The content design team was a key partner in this project. Since each Tool had its own user manual, it was imperative that we worked with them to get the right content into each Card. In addition to the development spec, I also fashioned a Figma template for our content design partners to easily comment and/or manipulate the designs as they saw fit.

I completed designs for Drawings, Specifications, RFIs, and a separate tool that was shelved for later. The second phase would be focused on testing these templates and determining how and what to scale. My rotation with the team was coming to a close, so I ensured that there was ample documentation for the next designer.

I already made sure that my Figma documents and Jira tickets had comments, but as the team got reorganized once more, I wanted to make sure I could explain what was already done, what we could (or couldn’t) do and why, as well as any concerns I had. I recorded Loom videos for my colleagues and set up meetings between myself, the content designers, and the designer who would be taking over the next phase of the project: testing.

Final Thoughts

The first phase of Tool Onboarding allowed the next designer to run tests via UX research. Through her testing, I learned that my initial designs tested well: there was a 3-8% range lift in users taking action thanks to the Onboarding panel and cards.

The project was a challenge with formidable constraints, and I’m grateful to have had the opportunity to help shepherd the first phase of the Kickoff project. This was absolutely an exercise in trusting one’s team: though it was frustrating at times, we all knew we were on the same team and we were doing our best with what we had.

I’m glad to have seen the Kickoff project continue to thrive under a completely new team of designers and developers. The success metrics I’ve seen in each All Hands meeting is a reminder that all work has to start somewhere, and I’m proud of the work my team and I did to begin the Onboarding work in earnest.

🫖 Would you like to hear more?

Drop me a line at hello@robbinarcega.com and I’d love to chat!