As the mobile platform team defined our product strategy for the long-term vision, we identified a key element to improving engagement. Our users were struggling with adopting Procore on the field and the team needed to determine how to increase engagement and delight to our field customers. After working with the implementation team and talking with existing customers, we found that building a more personable onboarding experience will drive adoption to our experience. Curating a frictionless onboarding experience that allows users to get into the app, see the value of the app, and learn how to effectively use the app are the 3 key areas of focus for this specific initiative.

As lead mobile platform designer for this initiative, I worked with product and engineering to define the team’s success metrics as well as conduct discovery calls with internal/external customers, strategize the project roadmap, and design a new onboarding experience for our customers.

As Procore solidified our mobile product strategy, the team determined there was a lack of engagement with our mobile app. Working with the data scientists, the mobile team believed there should be higher engagement with the app. A large hypothesis is that increasing engagement and improving our onboarding experienc will drive retention and network effects to our product. Currently, Procore does not have a fluid onboarding experience for the mobile application. The team was tasked with understanding the onboarding space and defining if it’s a current problem. After speaking with customers and understanding how new customers use the mobile app, it was clear that this is a huge opportunity to not only think about the onboarding experience within Procore but think about the entire customer experience.

The mobile platform team defined our product strategy into three key categories – Onboarding, Engagement, and Network Effects. The team’s hypothesis was if we improved our onboarding experience, we would drive higher engagement, which would then create a lasting network effect. This was found to be true after working with the data team and speaking with the customer success team, we found that there is a significant drop-off when a user downloads the app, to log in (almost 60% drop-off). We also found that if users start using the app within the first 4 days of downloading the app, there is a higher chance they will become a standard user. If we can reduce the drop-off rate and get users to actively use the app after downloading, there will be higher engagement.

One of the biggest challenges to this initiative was how do we as a team scale down all the work that can be done for this onboarding experience. Procore doesn’t have any onboarding experience, so this is an opportunity to rethink how people engage with the app. We can do everything, but we needed to make sure we were strategic. What was going to bring the most value to our users? Can we break down the initiative to multiple sprints so we can get “small wins” as we continue to improve the experience? These questions need to be defined as we completed our research. Working with the product manager, we were able to strategically focus on key areas in the onboarding experience that gave our customers more autonomy and confidence with the app.

The mobile app is about mobility, meaning that anyone on the go should be using the app. However, a majority of our users are labeled as the “field team”. The users that are always on the actual job site, working with the office team, and doing the actual labor. The field team (superintendents, foremen, laborers, and subcontractors) are always on the go and can’t carry a laptop with them everywhere they go.

Within the field team, we identified three use cases of a team starting to use Procore.
‍

Understanding how Procore Onboards our Customers
‍

For the mobile team to fully grasp the scale of this initiative, we needed to understand how Procore’s implementation team introduced the mobile app. We managed to speak to over a dozen implementation managers from multiple segments and map out the typical flow they take their clients. We created a journey map that highlights the expected process of Procore’s implementation team. This process highlights all segments and customer types.
‍

+ Procore doesn’t offer formal training to the mobile experience.

+ Typically, the first introduction to the mobile app is with our Quality and Safety tools.

+ Implementation managers train IT/people in leadership, and rarely work with the customers using the mobile app.
for

The initial impression after working with the internal team is that there just wasn’t a high emphasis on the mobile app. Our implementation process focused so much on the web product and hardly communicated the mobile app. This made it difficult as the customers being implemented, had to now show value to the app without really understanding the value of the app themselves.

Following our research with the implementation managers and customer success team, we set out to do discovery calls with existing customers. We used services such as Uservoice and Builder’s Club to find new potential customers to speak with. We managed to talk with 25 customers ranging from different roles (training coordinators, superintendents, project managers, etc) and different segments (enterprise, mid-market, emerging, etc) to understand their typical journey of using the app. Following our discovery calls, we designed a journey map for how customers onboard the rest of their team.
‍

As the team was finishing our research calls, we felt it was necessary to start involving the engineering team. We synthesized the research we conducted and set up an afternoon to have a fun workshop that also allows the engineers, QAs, and other designers the opportunity to share their thoughts as well as contribute to the decision-making process. One of the key exercises we did as a team was inspired IBM’s Big Idea Vignettes stating the problem and allowing the team to think of some of the most intuitive solutions. This was a great kickoff not only because it gave the entire team context on the work that we are doing, but it got the team involved. Everyone shared great ideas and allowed us to get alignment on the expected user flow.
‍

The first underlying problem we found is that users are struggling to get into the app. This is ultimately the biggest problem we identified and the first area we were looking into when it came to onboarding. Either users didn’t know how to navigate through the app/play store or they saw it as too much of an inconvenience. Users only download the app when they need it and that can be difficult as it can take some time to complete the task.

There is immediate resistance to some users as they are not familiar with tech, already use other tools, or are hesitant about changing their process.

The biggest problem with this pillar is that users can’t create an account through the mobile app. Procore only allows the user to create an account through the web product and cannot access the app without it. Because of this, the field team, who would never use the web product, has to go into the app and create an account only to get access to the app. We found that a huge barrier to entry that needed to be addressed.
‍

Imagine this scenario – you have a process that you’ve been following for the past 10-15 years. You’re comfortable with what you’re doing and it works. Then all of a sudden you’ve been told by your leadership team that you need to start using Procore. You need to figure out how to integrate the product into your day-to-day with minimal support. The first question many people ask themselves is – “Why should I use Procore? What makes Procore better then what I’ve been doing for the past 10 years”. This is a common theme that many of our users ask. And they’re right. Procore has never communicated why the product will help the users become more efficient. On top of this request, users are asked to watch hours of training videos and spend a considerable amount of time learning how to use the app.

Talking to customers, it was very apparent that we not only needed to communicate the value of Procore, but offer the user “quick wins” so they can see how easy it is to use. With the data that we collected, if we can get the user to start using Procore within 4 days of downloading the app, they have a much higher chance of continuing to use the app. When conducting our discovery, we asked what the users what features they look at first when using Procore. With the qualitative data and the quantitative data, we found that the most used functions of our app are the Drawings tool, the Photos tool, and the Daily Log tool. So we wanted to push those tools upfront so the user can quickly see what each of them can do.

While conducting research and understanding the problem space, we realized a pretty significant barrier as to why users aren’t able to fully use the mobile app. It’s a combination of having minimal support but most importantly, there is a level of anxiety that users don’t want to explore the app because they are actively working on an item that can impact the project. So we found that users aren’t engaging with the product as much because they don’t want to do anything that can negatively affect the project.

With the problem in mind, the team started to design early iterations of the ideal flow of the overarching support challenges that our customers face. The team thinks “blue sky” in terms of what our solution can be and we work together to scale down what it should be given our constraints. Because of our fleshed-out design system, we are quickly able to mock various iterations of onboarding and support. Shown below are some ideas the team had early on that created a few debates within the onboarding experience.

One of the key areas of emphasis that we wanted to design for is sharing Procore’s mobile app. Due to users not knowing how to navigate the app/play store or not wanting to, we needed a solution to increase accountability to download the app. We did a few iterations but came down to two options in which we tested with users. One idea had a high emphasis on sharing Procore, while the other concept had a progressive disclosure experience.

Within the onboarding experience, we wanted to configure the user’s settings when it came to notifications. Procore typically needs access to the user’s camera, library, location, and potentially allowing the user to receive notifications. These messages appear throughout the mobile app so we wanted to see if there was an opportunity to configure all settings within the initial experience. Or – if we should only ask the limited messaging and ask the user to give access to the others only when they need it. Ultimately, we decided to only ask the user for notification due to that function being an integral piece to the experience but did not ask permission for the camera, photos, and location until they needed to use that experience, with the idea that they would be more open to accepting if they are actively trying to use the experience, camera for example.
‍

An idea that floated around early on was how do we build a more personable relationship with our users? One idea that was talked about was including a Chatbot functionality or a live support feature that allows the field team to ask any questions they have. This will give the user confidence that they can get any answer right through Procore. We did early explorations but ultimately ended up putting the idea on hold as we determined it wasn’t within the scope of the initiative.
‍

As the team got to a place where we felt comfortable getting feedback, the team started to work closely with the research team to develop a strategy around testing our new experience. With the affordance to test the experience with training coordinators, superintendents, and project managers, we were able to iron down the experience and validate our assumptions while also making changes to the experience. One of the key experiences we needed to evaluate was whether the “My Project” experience made sense to the user and they knew that was the space to test new functionality. Due to COVID-19, testing these ideas was challenging as we needed to conduct our tests virtually. We still felt the need to test and worked diligently with the research team to define a strategy that allowed us to validate a majority of our ideas.

Because there is an innate fear of affecting a live project, the team wanted to include a “sandbox” project that allows the user to playfully explore the app however they please. This will allow the user to engage with the app and explore new functionality without the anxiety of accidentally affecting the project. On top of the “My Project” experience, users can have an interactive onboarding experience. The team wanted to make sure that users were going to skip through the onboarding experience, so we curated a non-linear experience where dialogues will pop up if the user interacts with a specific function.
interacted

This is a massive project that requires a ton of heavy lifting from the technical side. This initiative is currently in the planning phase and is expected to be completely built by the end of the 2020 year. This was such a fun experience for me as I was able to work very closely with the product manager and think about the overarching customer experience. I am fortunate to have experienced the full end-to- end design process – defining the problem, talking to users, collaborating with engineers and designers, and iterating on a brand-new experience that positively impacts the mobile app.