Project Setup for Construction Project Managers in the Field — UX/UI Case Study
Designing Software for Subcontractors
BRIEF
Our client, a tech startup whose software takes account of every part of construction from timecards to material quantities, needed an easy registration and first project setup process in order to bring in smaller companies. It had to be simple. It had to be doable in the midst of an active construction site. And it had to scale — all the way up to the enterprise level.
TEAM
During a two week sprint, I worked with the supremely talented visual designer Erica Krivda, as well as advertising-manager-turned-UX designer Brandon Cherry, to research and design the onboarding and project setup process. I had worked for a tech startup before, but the construction world was completely new to me.
RESEARCH
While my teammates wrote interview questions and our clients prepared a list of both clients and potential clients they wanted us to speak with, I set to drawing up a competitive/comparative analysis so we could hone in on what other construction software companies had found most productive.
I soon added to that the biggest players on the planet — Google, Facebook, Twitter, Instagram, and others, reasoning that their design teams had more funding — and more reason — to their sign up process. I was right.
Adding to this I assembled from dozens of UX articles a set of UX best practices (you can read my article on that here), and in one day our team had the background research, discussion guide, and a series of interviews scheduled.
We spoke with 4 individuals, stepping into a world of crew problems, construction delays, and legal requirements like safety training. The world of subcontractors has yet to be touched by tech, and many states still require daily paper submissions by foremen. But paper gets lost. Foremen don’t show up. And you don’t want to get a project manager started on what happens if it rains — your voice recording software will learn some new words.
REGISTRATION DESIGN
Across a wall we listed side-by-side UX Best Practices for registration forms, psychology principles that lended themselves to these practices, and the competitor forms that utilized them.
From this, we assembled a Moscow map.
We brought in the CTO of our client company and ran a design studio. Soon, we had a brief registration process that was easy and distraction-friendly.
But we also had a problem.
We affinity mapped the results of our interviews — overwhelmingly, the most time-consuming part of the process for our project managers was setting a project up. Even with this new software system, they had to manually input each team member individually… into three different places.
So even though our job was to design a registration process, we had to pivot to project setup.
“You can buy growth. You can’t buy retention.” — Nir Eyal
PROJECT SETUP DESIGN
I wanted to know our starting point. So I took the current client start page to 5 tech-savvy users and tasked them with starting a project. 1 of 5 succeeded. The other 4 could not find the button.
From the interviews we had built our persona, Project Manager Bob, who stared down a host of metrics he had to submit… daily… to a number of stakeholders… pulled from a number of teams… with no errors at all.
Sound like fun?
From this we got our problem statement:
Bob has difficulty creating projects due to the complicated, time-consuming setup process. How might we simplify the project creation process to help him save time and minimize mistakes?
Features
First, we wanted to eliminate the chance for Bob to make a mistake by leaving his project setup partway through — so, in alignment with UX Best Practices and every major company’s registration page, we hid the primary navigation throughout the project setup process.
To get him started, Bob, as a first-time user, registers and lands on an overlay taking him directly into the project setup process. After all, he cannot use any software tools until he has set up his first project. And to calm Bob in case he finishes setup, gets distracted, and now is not sure where his setup went, he ends on a confirmation page letting him know it’s all saved.
We talked to users, potential users, and stakeholders to cut as many input fields as possible. Those we couldn’t cut we put into vertical alignment (with he names of fields directly over the inputs and directly over the next button) in order to keep Bob focused and chugging along at a fast pace.
Since we still had a lot of information we needed from Bob, we divided this into 4 steps in the process, and showed Bob which step he was on with every screen. Pulling in another UX Best Practice, we ensured that should users make an error while inputting information, they would be notified of it by an error message (telling them how to fix the problem, NOT telling them they did something wrong) as soon as they tabbed out of that field.
Why?
I witnessed during my usability test on the current site that 4 of 5 users, once taken to the project setup screen and told to complete setup, filled out a long litany of fields only to be given an unresponsive save button at the end.
Not only were users confused as to whether the save had gone through or not — with no confirmation and no reaction from the save button to show it had been selected, much less processed the info, users had no clue — but users then had to scroll through all of their fields to find that one now had red text beside it, telling them they’d inputted their phone number incorrectly. One user reformatted it twice before discovering what was incorrect about it — it wanted dashes.
This was a huge frustration for users who had already gone through a lengthy setup process only to be declined at the end of it. By showing errors as they occur, we turned a surprise stop sign into a road bump.
USABILITY TESTING
4 of 4 users succeeded in creating a project with our paper prototypes. But 2 of those 4 hit the save button, thinking it would save the project so they could hit next.
Instead, the save button takes them out of the project setup and into the tools page, a demonstrated need by clients who set up multiple projects at such an early point in the process that the rest of the information hasn’t been created yet.
This is at the enterprise level, while we’re trying to make the process easy for small companies who will have to input all info right away — they’re not waiting on another department, they’re the only department there is.
So we needed to keep the save button, as well as allow for clients to skip steps they’re waiting on other departments for, but make it rank so low in our page’s visual hierarchy that only those who are looking for it will find it.
In mid-fidelity, 3 of 3 users progresses through all steps to successfully create a project. The Save/Next issue was gone for good.
But now smaller clients didn’t have parent projects, a field required for enterprise clients, and were alienated that something they didn’t deal with frequently was their very first entry point. It risked alienating them from our software entirely, making them think it’s only for huge companies.
So we dropped the field to lower on the page, and added it to our backlog (how can we change the terminology so it’s still recognizable to enterprises, but not alien to small companies?). We had saved the majority of enterprise clients for our high-fi usability test, so we added that field to our discussion guide, and hurtled forward.
The hi-fi prototype was built on tablet, a breakpoint that project managers utilize in the field on construction sites large and small. We also built it our for desktop, since project managers rotate between the field, the work trailer, and the office.
8 of 8 users succeeded in creating a project. This included individuals who had never worked with our clients’ software, individuals who were tech-savvy, and individuals who were not. The team traveled all over Manhattan and Long Island City to do the tests, me with a tablet and my teammates with a laptop, all of us getting drenched in the process.
RESULTS
We had succeeded. Our project setup resulted in comments such as “That was it? Wow, that was easy,” and “That’s better than I’m used to being treated in a project setup.”
In terms of the actual testing, it felt a bit like getting a black eye. I love testing and interviewing users, I always learn something from it. Still, users all wanted different things from the software, and some were very angry our software hadn’t yet resolved their problems with the product — showing them the weather or aggregating info into a simple daily report.
I promised our clients, “This is only the beginning.”
(And that pesky parent project field? In speaking with enterprise clients, it looks like most enterprises use the address. So we may be able to have our address field do double duty, and cut our number of fields even further.)
Amelia is a UX Designer in New York City. Check out her portfolio or connect with her on LinkedIn.
