Ye Olde Procore Photos
Procore’s Photos tool circa February 2017 hadn’t been touched since it was built in 2014. Users were able to capture photos through our mobile apps or upload photos that have already been taken. Every photo must exist in a manually created album. Photos that exist elsewhere in Procore are siloed, in no way connected back to the broader Photos tool.
By the time my squad, Project Management Core (PM Core), turned our attention to address this tool user frustration was beginning to bubble over to an all time high. The request for ‘sub-albums’ within the parent album grew to become the third most voted on feature within our feedback collection system, garnering over 125 up votes. Our largest customers had given up on Procore’s Photos offering altogether and were instead managing their construction photos through an integration parter Smartvid.io.
Through careful data analysis, discovery, and competitive analysis, PM Core was able to deeply understand user’s needs around construction photos and develop a long-term strategy for their existence within Procore. Since February, we have iteratively approached solving the aforementioned problems. Before I delve deeper into the details of this project, it’s important to show the tool we inherited.
Some things to note…
- It takes 4 taps to get to the camera upon launching the mobile application.
- A user must choose between ‘QuickSnap’ mode and ‘Photo’ mode
- A user must select or create an album before they are able to take a photo.
- Users can only view photos within an individual album, never across albums.
Defining a Direction; Sub Albums?
Early on their was no greater problem than the central ‘sub-album’ conundrum. Users were asking for it, but to our team this was a greater sign at their underlying issues to successfully organize photos in Procore. User interviews often went like this;
- “So, you requested sub-albums.” – PM Core
- “Yes I did.” – Users
- “If we were to provide you this feature, how would you organize your photos?” – PM Core
- “Always by date and then by location. Then maybe by type of work, the name of the subcontracting company, phase, or something else random.” Users
A competitive analysis of modern photos solution also disproved the sub-albums path. They all solved photo organization issues in more intelligent ways, leveraging faces, places, and things to tag photos, instead of manually created sub-albums. Upon deeper digging it became very evident to our team that building sub-albums would be a pivotal mistake that would lock users into an even more rigid photos organization structure. Still needing to explain this direction to countless stakeholders I challenged myself to convey the rigidness in a simple manner yielding this presentation that I’ve given many times internally to various stakeholders.
In summary, we will be using a combination of manually and automatically applied tags to photos to solve there organization needs instead of building out sub-albums.
Defining a Direction; Timeline, All Photos, QuickSnap?
In studying user-defined album names in Procore it was sometimes difficult to find an album that wasn’t representing some sort of date whether it be day, week, month, phase, or year. With more and more photos captured from mobile phones, these dates lived in photo exif data and could be organized automatically instead of manually. Out of these insights the idea for a Timeline view was born where users can view photos by day, week, or month & jump to photos from any specific day in the past.
Data from current behavior affirmed some other assumptions our team had about photos usage in Procore. For one, 15% of the three million photos taken this past June existed outside of the Photos tool, with the vast majority of these photos existing in our Daily Log tool. In talking with users, we’re confident this number could and should be much higher with hopes of 50%+ of photos in the future existing elsewhere in Procore. To do so, our team build a foundation for a future where all photos taken in Procore exist in the photos tool, but link back to the respective tools and items in which they came from. On the flip side, we sought to use the camera on the mobile app to drive the creation of items outside of Photos. These seemingly simple concepts (referred internally as photo-first workflow & photo aggregation) were new at Procore and extremely important in creating a seamless user experience within an ever-expanding software application.
On the mobile front, our team felt strongly about making the photo capturing process as simple as possible. Today, users were four taps away from capturing photos upon launching the application. Additionally, they were given two camera modes that were extremely confusing to users, ‘QuickSnap’ and ‘Photo’. After visiting six construction job sites and meeting avid photos users it became evident that the difference between the two modes was extremely unclear. Data supported these anecdotes as 80% of users who took a photo in ‘Photo’ mode did not actually markup the photo on the markup screen immediately following capture. Dead simplicity inspired by consumer applications was a must for the mobile camera experience.
The majority of the design work on this project existed on the mobile front of things, where I worked collaboratively with a colleague Denise Orozco to solve. Below you can see Denise and my first attempts at solving these issues around capturing and organizing photos.
Some of the key things we focused on were…
- Applying the Procore field ‘Location’ to a photos
- Allowing users more control over the privacy surrounding their photos
- Allowing users the option to markup their photo, but not requiring them to
- Allowing users to apply custom tags to their photos
- Allowing users to create items elsewhere in Procore with the photos they’ve taken
- Making all of this available & discoverable, but not required or to feel like a burden when needing to quickly capture photos
Converging 1.0; A First Prototype
Capturing Photos: With some small changes, we moved forward almost entirely with Denise’s thoughts around capturing photos. Getting to the camera is one tap or swipe from application launch, instead of the four taps away today. We both moved to remove the speed bump where users could choose between ‘Gallery’ & ‘Camera’ as well as the in camera modes ‘Photo’ & ‘QuickSnap’. Instead, a user clicks the camera, the camera launches, and they begin taking photos whether it be one or one hundred. Inspiration for this part was largely taken from the native Android and iOS cameras as we felt users were most likely to be familiar with these experiences.
Organizing Photos: Denise & I met in the middle in designing for a seamless way for users to organize their photos quickly and at scale. In the end we moved more towards my concepts as they defaulted to organizing in bulk, while Denise’s defaulted to organizing one-by-one, with the option to organize in bulk. I also explored patterns for the photo-first workflow concept where users can initiate items elsewhere in Procore from the initial camera. Inspiration for this part was taken mostly from Instagram and FaceBook who shared the user stories around taking and organizing photos in bulk, with the secondary option to organize individually. Specifically, I’m referring to the relatively new multiple photos feature released on Instagram as well as the ability to share multiple photos on FaceBook in a post.
Convergence 2.0; Approaching Development
Using the above prototype to shop around with product managers, fellow UX designers, and engineers we were able to seek prioritization help, design critiques, and developer estimates that assisted with the next stage of designing. Specifically, we cut scope on ‘Tags’ which had yet to be built into the backend nor exposed as an API for mobile developers and the photo-first workflow concept (with plans to work towards in 2017). We also shifted more attention towards the Timeline view, the individual photo editing experience, and the full screen photo viewer. These facets had been prioritized and had been somewhat looked over in the prototype above. Google Photos & FaceBook were the biggest inspirations for the the full screen photo viewer, while Apple Photos & Google Photos were for the Timeline view.
Worth mentioning, one of the key improvements we made to the bulk photo editing screen, was displaying the un-editable metadata of ‘Date Taken’ and ‘Uploaded By’. This information was added following a design critique in which the director of UX (known for simplicity), was wary about the net added effort existing in the concept vs. the current state. These fields made the bulk edit screen feel halfway filled out instead of entirely empty as in the last iteration.
Tracking Success & Future Plans
Today (August, 28th 2017), we are in the middle stages of development and release for this project across platforms. On web, we launched the Timeline view first back in March and have seem more usage each month since launch with minimal promotion. On mobile, we will be rolling out these changes on Android before iOS as a pseudo-beta test. Within Android, we’re working inside out, starting with the full screen photo viewer, then towards the new Timeline view, and finally with the capturing & organization overhaul. The entire prototype above will be released in Android by the end of September with iOS following in the early fall.
We’re still thinking hard about photos across Procore and have done some things already and have a plan for where we’re going next. Apart of the photos schema, we’ve added an ‘Origin Type’ and ‘Origin ID’ field that allow for photos to be pulled in from other tools. Below is a screenshot of a piece of the photo metadata when taken from the Daily Log tool, but viewed in the Photos tool.
On the flip side, we’ll be launching the photo-first workflow concept as a follow up ticket to the capture & organization mobile overhaul I mentioned above with a focus on the Daily Log too. This concept has been heavily validated by users and if successful will expand to other tools within Procore. We plan to track the success of this project with a simple pie chart showing the percentage of photos that exist exclusively within the Photos tool versus other tools in Procore. With a baseline of 15% of photos associated with external items before we’ve begun these aggregation, we’re aiming for upwards of 50%+ over the next year as user behavior shifts.
Regarding the infamous sub-album and photo categorization dilemma, success will not be as easy to determine, but more of something we track over time. For starters, we’re looking to promote the ‘Location’ field within Procore and see a greater percentage of photos exist with a ‘Location’ over time. Similarly, we’re hoping a greater percentage of photos exist in an album-less state and less manually created date albums (likely to be tracked with an average albums per project metric). Qualitatively, we’re expecting less pressure for sub-albums as this solution solves the same core organization issues.
Going forward we have plans to…
- Use the photo exif data to recommend a Procore ‘Location’ instead of having it always applied manually.
- Automatically tag the contents of the photo using image recognition AI either built in-house or leveraged from Google Cloud Vision.
- Displaying these locations, tags, & origin attributes in ‘Smart Albums’ akin to Google & Apple within the traditional ‘Albums’ view on both web and mobile.