.png?table=block&id=e0804b0d-d843-4a21-bd4a-b68022a1ebb0&cache=v2)
.png?table=block&id=87d81fe7-8cb9-42db-8ba1-aeefe8e7df3f&cache=v2)
Summary
At-a-Glance | ㅤ |
Company | Levelset (subsidiary of Procore) |
Role | Senior Product Designer |
Project Length | 3 months (July - September) |
Team | Product designer (me); five developers; one product manager |
Year | 2022 |
Risk Reports are a product offering of Levelset, a subsidiary of Procore. It began as a highly manual wizard-of-oz proof of concept involving several forms; manual PDF generation to be uploaded to a drive; and someone downloading that Risk Report PDF to upload it to send to the customer who originally filled out the request form. And that’s assuming we even had enough data to create a Risk Report to begin with. Whew!
At a Glance: In about 3 months, I delivered an interactive, in-app version of the Risk Report, converting it from its static PDF format. I also incorporated a Risk Report search into Levelset’s existing search functionality. I worked with five developers and a product manager to build out the design for live testing, allowing for a base metric to compare toward in the future.
Background
Levelset’s main user base consists of construction contractors and suppliers who rely on timely financial paperwork through the exchange of work contracts.
Construction is a tough job, and on top of that, getting paid in a timely manner has traditionally been a complex problem. Levelset’s core offerings are based on the financial aspect for contractors and subcontractors.
A Risk Report acts like a credit score to construction suppliers, allowing them to assess contractors’ payment speed, history, and growth to determine:
- Will this contractor pay me on time?
- Or, will they reliably pay me, even if it isn’t necessarily on time?
The Problems
When I first started working on this project, the Risk Report was a Wizard-of-Oz proof of concept. The Risk Reports were requested via a third-party form, which would trigger a request to run numbers to generate a bespoke Risk Report PDF. The PDFs were then uploaded to a folder which sales representatives needed to access, and then, via email, would be sent to the original requester.
Unsurprisingly, there were a few problems that arose from the user side, and taking the manual proof of concept to the next level would allow us to pursue at least one of these issues:
- Lack of form status: The third-party form gave little to no indication that the request was sent.
- Not enough information: Users wouldn’t know if they were even eligible to receive a Risk Report; if they looked up a report on someone who wasn’t on Levelset’s radar, they might not get the information they need.
- Lack of in-the-moment help: Because it’s a PDF with a lot of heavy terminology, there are no interactive elements that can help express the value of the Risk Report.
Lack of in-the-moment help was the problem we prioritized, since the original Risk Report was a static PDF that offered no guidance. In a kickoff meeting with a director-level PM, a senior-level PM, several key developers, and myself as the sole designer, we decided that this was the problem we could solve sustainably with our developers.
The Goal
Our goal was to fold Risk Reports into the Levelset application to avoid the manual form to PDF to email flow. This feature would give us base UX metrics with which to compare future iterations, allowing us to further test the validity and desirability of the Risk Report feature.
The Solution Explored
I utilized a combination of a starting point of a UX audit from past Risk Report PDFs; follow-up interviews with companies who used the experimental feature; internal data from account managers; and industry-standard usability heuristics to port the PDF into the Levelset application.
By the end of the project, I was preparing to be moved to a different team, so it was important for me to ensure I left it in a good place. Metrics-wise, I asked for trackers on each interactive element to see if people were using them at all, along with a suggestion for a future designer to conduct user interviews for qualitative feedback.
✨ Pride Point
I received extremely positive feedback from the developers I worked with during this project, all of whom said that I was one of the best designers with whom they’ve collaborated. This is largely because they were great at communicating! They were open to coming to my working meetings to get their consultation on development constraints.
For context, Levelset was coming out of a largely start-up mentality where it was “UI first, questions later”, and my experience at both start-ups and acquired public companies helped to bridge that gap. This was also the third project I was juggling during the same quarter, and I was very pleased with myself for being able to work efficiently without burning myself out!
The Design Approach
Three different projects in one quarter? Bring it on.
The first step before any project for me? It’s gotta be the prioritization from the user standpoint and the business standpoint. By this point, I already had several small LODO and efficiency work for an internal tool along with two medium-sized projects when this project fell into my lap.
I’m big on protecting my time, so this is when I requested a meeting with my four PMs in a room so we could prioritize the work together. I enjoyed working with all of them and gave them ample heads up beforehand, so I wasn’t worried about potential chaos that could ensue. We had truly candid conversations around prioritization during these meetings, and so we were able to prioritize Risk Reports. (Here’s a link to the template if anyone’s curious.)
Discovery research highlighted UX gaps in Risk Reports, creating a feature list based on level of effort for finalizing our goals.
I had about four days total to learn what I needed to know about the experimental feature of Risk Reports. It wasn’t a lot of time, so I planned and proposed the following:
- UX Audit of the existing feature, and the PDF that is sent to users, limited to about a day and a half of work.
- Secondary Research, digging through any marketing research that may have been conducted by this point, limited to a couple of hours.
- Internal interviews from Account Managers (AMs) and Expansion Account Managers (EAMs) to understand how they sold this experimental feature to their accounts…and what happened when they weren’t able to sell. I limited this to whoever I could find in the physical office since they often showed up onsite and whoever had time to chat with me on Zoom.
I presented my research synthesis to get team alignment, and it worked well: I got the sign-off to start design work on porting the PDF into the main web app.
There’s really nothing like a concise, clear, timely meeting that gets people in a room excited about what we get to work on for our customers. I received a great reception from a large cross-functional team from Austin, Cairo, and my local office in New Orleans.
.png?table=block&id=460ca13f-8a15-497a-b040-9f5e37d253ef&cache=v2)
📷 The UX audit highlighted usability heuristic concerns, such as the lack of system status when a person requested a Risk Report.
What I usually do when faced with a new part of a platform is to perform a UX audit as thorough as I can with the time provided. It hasn’t failed me yet. This was a teaching moment for me as many of the PMs and developers hadn’t seen a usability heuristic audit before.
I made a Usability Heuristic Audit Template with an info tab appropriate for my audience’s point of view. I recorded myself trying it out and made copious notes on why certain issues were points of concern, along with scores that were based on my experience so far as a designer. I also added a tab with recommendations of what we could pursue based on my perceived level of effort, which I said should be compared with our developers’ combined level of effort.
This report wasn’t immediately well-received as it was a lengthy document, so I later compiled the main points into a research synthesis presentation that would prove to be effective at aligning the team’s goal.
Secondary research revealed there were no existing base metrics or clear record of the experimental Risk Report feature yet; this became a key outcome of this project.
As I perused through several hours of interviews which were market- and product-led, I realized that documentation didn’t exist for how Risk Reports was performing in its current manual state. The only metric I could find was the number of Risk Report PDFs requested, which meant we didn’t have a baseline of how helpful the actual Risk Report was to our customers.
In the team alignment meeting, I highlighted why getting a base metric would inform future iterations of the design and overall product: any designer coming after me would be able to see the data and make adjustments as needed.
Internal interviews validated the value behind Risk Reports as well as the target user persona, allowing me to pull appropriate levers while designing.
When I was first working on this project, the landing page was a part of my UX audit, and I was personally very confused: who was actually benefiting from the Risk Report? Was it a general contractor? A subcontractor? An entity above that? My understanding was coming from many different places, so I wanted to learn how our Account Managers sold Risk Reports.
I wanted to learn how it was sold; the customer type it was usually sold to; and what AMs did when they couldn’t sell a Risk Report. I like to learn about what causes turnover, because those calls can be very telling — and it’s not surprising that a budget-savvy customer will want their opinions to be heard. I listened in on past sales calls and shared my observations in the research synthesis presentation, and those customer quotes garnered a fair bit of user empathy with the cross-functional team.
I further defined the expectations of our users with a handy flowchart; this asset solidified team alignment, and also helped our new PM get acquainted with the actual user flow.
The original user flow was clunky, but reflected the best use of available resources to test a new concept.
My suggested user flow iterated upon the original by containing the processes within the app, as planned, rather than having the customer wait for a PDF.
With the directions cleared up thanks to the user flow, I took us through a series low-fi MVP wireframes. This level of fidelity allowed for swift changes, creating a collaborative discussion that developers felt empowered to weigh in on.
This was imperative, since the team was used to thinking high-fidelity from the get-go, which distracted us from what our users were actually looking to accomplish from the Risk Report.
Feature 1: Searching for a Risk Report
The simpler of the two features was searching for a risk report. This had to work alongside another project I was working on at the time, so risk report availability had to be distinguishable from job alerts.
Feature 2: Viewing a Risk Report
In the example below, I utilized color blocks and descriptions of the content that would show up, rather than using final copy. This was a conscious choice: when I’d used final copy in previous jobs, it shut down a lot of conversations. What this did was open up the conversation around the technical feasibility of the type of information we wanted to show our users for each bucket.
I’m glad to say that my engineering partners said I was one of the best designers they’d ever worked with so far! Collaboration with our developers has always been my favorite part of the job; it’s one thing to have crazy design ideas, but another thing entirely to know if it’s actually possible.
Handing off higher fidelity wireframes was a simple process, since I had involved the developers in succinct, efficient meetings from the get-go.
By this point, I lead the small team since our PM had been pulled into other projects. I coordinated all the meetings, ensured they were useful and timely, and always checked in with the developers to make sure I wasn’t taking work time away from them. This was especially important, since a majority of the team was based in different time zones.
Final Iterations for Testing
Searching for a Risk Report
Viewing a Risk Report
I ensured that the team had all my documentation and suggestions for hypotheses and further testing, since I was preparing to move to the Design Systems team for the next quarter.
Final Thoughts
We achieved the first phase of an in-app experience, ready to build and survey in live testing. This was a massive step up from the highly manual process, where Risk Reports existed only as a static PDF emailed to a recipient.
Today, you can check out the marketing page with Risk Reports, which has by this point transformed from its humble beginnings as a simple PDF. This project was one of my favorites, mainly because I got to know my developers so well! Being able to collaborate closely with them gives this project the kind of zest I seek out in my work.
🫖 Would you like to hear more?
Drop me a line at hello@robbinarcega.com and I’d love to chat!
©2024 Robbin Arcega. All rights reserved.