Procore Technologies — Mobile Filters
--
Year: 2016
Client / Company: Procore Technologies, Inc.
Role(s): User Experience Designer
Contributions: General Feature Concept, Main User Flow and Story Map, Contextual Inquiry, Usability Calls, Wireframes and Mid-Fi Mockups, Clickable Prototypes.
Final Result / Deliverable: Final design pattern with all the development requirements. The new feature was developed and released in the iOS and Android Native Apps resulting in a 40% time improvement in data searching.
Problem
The Procore Mobile App is used by thousands of Construction Field Workers to capture issues, track progress and measure quality/safety. Procore Mobile is widely used by superintendents, project managers, foremen and other on-field workers.
One challenge that appeared with the growth of the product and the addition of more comprehensive issue capturing tools, was the cumbersomeness around finding specific groups of issues.
As a construction project move forward thousands of items are collectively recorded by different workers and stakeholders. Those items need to be referenced in later stages to be effectively addressed. Procore users were having an sub-optimal experience when it came to find and reference previously created items.
I was tasked with creating an scalable and re-usable UX pattern to solve this problem…
What kind of solution can provide an agnostic filtering pattern and an fast way to find specific groups of items with easiness?
Process
The first step I took to solve this problem, was to analyze anecdotical and quantitive data, in order to build an insight around the problem. Anecdotical data was gathered from 3 main sources: User Feedback Tickets, Customer Support Tickets and User Sessions Recordings.
Quantitive data was gathered from our analytics software (Google Analytics and AppsSee). I extracted pertinent information from the main events dataset and analyzed sessions that mainly occurred in our specific tools lists views. I analyzed funnels and focused in understanding the behavior behind the available filtering methods (Segmented Controls and String Search).
After gathering all the data and analyzing the general user requests, the problem became evident: Users wanted more granular control to filter down the items lists, but they had an special interest in filtering items by two specific properties (Assignees and Locations).
In order to create the right filtering pattern and filtering mechanics it was also important to understand the behavior behind data searching in Procore, particularly the nature of datasets and the nature of the filtering parameters. One clear challenge was the fact that Procore users are likely doing two types of data search. 1) Locating a know item within a fairly large list of items. 2) Locating a unknown item based of a set of known input parameters.
This is usually very unusual for filter paradigms since most of the time filtering mechanics are created to address specific dynamic searches or fuzzy searches, bur rarely both.
I did several analyses to dissect the problem. My first approach was analyzing the existing patterns (Segmented Controls and String Search) and determining what “Jobs To Be Done” were being satisfied by the existing patterns. Once I determined which JTBD we not being correctly addressed I started working in the a first pattern that could potentially solve the missing cases.
I then use that pattern to expand into other existing problems and issues and formulated new questions around problems like context and scalability.
One of the problems I unveiled in this phase was the limitations with screen real estate and the need to keep the users in context.
To solve this, I explored several solutions using virtual real estate (drawers and sliding views) as the baseline of the design. After several explorations I created a semi-realistic prototype of the filters view and functionality.
This gave several ideas to address these issues. The first one is that context wasn’t going to be lost as long as I designed clear feedback loop mechanisms.
The second idea is that as long as I kept a hierarchy of filters and a consistent message around the content and the mechanics, users were going to have an easier learning curve.
Here is a photo that illustrates my design approach to dissect the problem and conceptualize a solution:
After having an initial clear idea and a set of mocks and early prototypes, I went through a formal design critique process in which I got feedback from other UX designers and major stakeholders.
Finally, I performed a series of usability calls to validate the new real estate paradigms and did two onsite interviews in which I put the prototype on the hands of our customers. The calls and interviews proved that the paradigm was usable, easy to learn and highly functional.
The new filtering paradigm also was huge improvement in the use of screen real estate. The main two optimizations I did to achieve this were:
1) Segmented Controllers were deprecated giving extra room for the list elements and other potential UI elements.
2) A complete new view for filters was adopted, taking advantage of the virtual real estate that until now was rarely used in Procore.
Here is the first prototype that contains all the initial patterns and elements including a feedback loop mechanism:
Solution
Since the initial design iterations proved to be successful, I decided to move into creating the production ready design.
After discussing the feasibility of the design with the engineers I started re-working the User Interface elements. At this point it was clear that we wanted to stay close to the Apple Design Guidelines, so I created a new view using only UI-Kit elements.
The new designed contained all the required filters. I also took the decision of going with a full height view and rely on the slide-in animation to keep the users in context. My initial process and testing proved that as long as a feedback loop mechanism was in place, it was possible to take advantage of the complete screen viewport.
I did a new round of testing and interviews with the updated design and got a hugely positive response. After polishing some details, I created the final specs for the feature and the interactions. Here is the final prototype that follows Apple’s HIG with dynamic filters adding and filter clearing flows:
Results
The Mobile Filters Initiative brought to life a very demanded feature that was needed to keep the mobile platforms in parity with the web app.
Before releasing the feature I gathered time duration data for actions like closing items, issue navigation and search.
I watched more than 4 hours of user sessions that happened mainly in the views that were getting the new filters. By doing this I was able to detect hundreds of user navigation bottle necks. Since I was confident those blocks were going to disappear with the new feature, I manually created a list of the top issues and used it as a baseline for measuring success.
After releasing the feature and getting and overwhelming positive response from our mobile users, I did a new round of data gathering and user session exploration. It was clear that the feature was a success.
The filters reduced the navigation time (within the item lists) by 40%. They also reduced the amount of n0-action sessions (sessions in which users navigate within a tool but don’t perform any workflow related action) by 20%.
