Procore accounting integrations

Re-imagining the accounting experience

Procore ERP Modernization

Background

While construction project managers like using Procore, accountants prefer their ERP software (”Enterprise Resource Planning”, also known as accounting software). Since both handle project finances, they need a way to share information.

Procore’s ERP Integrations tool allows financial data to be imported and exported between Procore and the customer’s chosen ERP, ensuring accurate financial reporting.

The problem

The ERP Integrations tool hadn’t been updated in years. The frontend code and user experience didn’t match Procore’s design system, and the backend architecture was outdated.

At the time, the tool had over 15 ERP integrations, 10 integration endpoints, and more in the pipeline. This complexity made it challenging and time-consuming for customers to use.

budget changes create and view screens

Above: a sampling of old ERP Integrations tool screens

My role

As the lead designer for the project, I was responsible for completely re-imagining the ERP Integrations tool. At the same time, the engineering team was updating the backend architecture.

My goals were twofold:

  1. Create a vision for what the ERP Integrations tool could become in the next few years
  2. Work with product and engineering to decide how we might start working towards that vision

Discovery

I started by researching our product internally to quickly understand it, assess the current situation, and find important opportunities. I talked with knowledgeable colleagues from the integration, support, and sales teams. I combined this information with customer feedback and analytics to identify the main issues.

Key pain points

  1. Scale & efficiency: The current process is manual, dependent on multiple roles, and time-consuming.
  2. Communication: Accountants are not promptly notified of items needing review and struggle to locate them in the tool.

Budget Changes 1.0 table
Budget Changes 1.1 table

Initial designs

In the current UI, each item type had a tab at the top. This was not a scalable solution as we had run out of space for more tabs long ago and had plans to add even more. (See the “More” dropdown in the screenshot below. 🫣)

Further, each item took up a lot of screen space, showing only 1-2 items at a time. This was a problem for users exporting hundreds of items daily.

My first design change was to organize the top-level navigation by the item status (Ready to Export and Ready to Import below). This way, users could see all item types in one list.

The assumption with these changes was that users could review and respond to items more quickly.

Budget Changes 1.0 table

Old ERP Integrations UI

Budget Changes 1.1 table

Initial designs

Customer validation

Next, I wanted to validate this direction with customers before moving forward. I reviewed a prototype with customers and internal SMEs to gather feedback on the new designs and ensure they could still find all the necessary information.

Key insights

  • Need more information: Customers shared that I had left out the most important data (Item ID), and requested a few more data points be added.
  • Lukewarm response to new IA: The change from tabs for item type to taps for item status got mixed reviews. Customers found it hard to tell different item types apart when they were all in one list.

Budget Changes 1.1 table

Initial designs

Budget Changes 1.0 table

Updated designs based on user feedback

Design iterations

Sometimes the smallest change makes the biggest difference. In this case, I added color-coded tags to differentiate item types, and (spoiler alert) customer response went from skeptical to enthusiastic.

I created a new pattern for bulk reviewing items (something customers had been asking for), created an improved framework for error handling, and simplified settings content.

Both the list view and the tags were not yet components in our design system, so I collaborated with the systems team to design, validate, and contribute designs.

I also partnered with our content strategist to ensure our statuses and actions were consistent with other Procore products.

Usability testing

The final test is always to turn the designs over to customers and see if they can actually use them. I conducted usability testing with customers, asking them to give feedback while performing tasks with a prototype.

Key findings

  • Task completion: All participants successfully completed the tasks. Other than a few small areas of improvement, we received positive feedback overall.
  • Information architecture: Most participants explicitly stated that they liked having everything on one page. This was a significant improvement from the lukewarm response to the initial designs, partly due to the tags and improved filter experience.

The Portland airport carpet

The Portland airport is very proud of their carpet

Team photo

Team photo 🙂

Team onsite

With the designs validated and complete, we needed signoff from cross-division stakeholders. We decided to use this opportunity to have a team onsite in our Portland office.

I worked with product management to plan sessions that brought together not only our entire product team, but also members from customer support, implementation, and custom solutions.

I led sessions to review designs, discuss roadmap and sequencing, and share customer feedback.

Usability testing scores

Outcomes

This is exactly what I was going to ask for!

If this screen were up I’d be able to take a glance and see what I need to do.

-Customers reviewing the updated designs

Following design validation, positive customer feedback, and support from cross-functional stakeholders, the project received approval from division leadership to move into the implementation phase.

I worked with product and engineering leadership on sequencing and creating a roadmap draft before transitioning the project over to the implementation team.