Background
Introduction
Inspect empowers inspectors and building managers with data storytelling by providing comprehensive tools and features to collect, manage, and analyse field data efficiently.
One of the standout features of Inspect is its ability to transform collected field data into engaging reports. Inspectors can create professional reports incorporating rich media, such as annotated images and sensor data from their NDT devices to convey their observations effectively.
Problem Statement
An inspection reporting workflow is dynamic by nature. Inspectors often annotate photos of building defects, arranging them in a manner that is coherent and paints an accurate story of the state of the infrastructure.
However, the current reporting workflow in the app is rigid. The user is expected to complete the report generation in one linear flow with little flexibility.
- No way to edit or reselect images for reporting: The user only gets one chance to select the defects (known as “Spots”) for reporting. To edit or select missing defects, he must abandon and restart the entire selection process again.
- No way to preview spot details or enrich photos of defects during the selection: It can be frustrating to select pictures for reporting when all you can see are tiny thumbnails. The user is not able to select specific photos for reporting. There is also no way to zoom in and identify photos most recently taken.
- Impossible to know the sequence of the items in the final report. It is troublesome to reorder spots with the existing workflow. Customisation to report templates can only be done on the web app, with little flexibility on report preview and details on-the-go.
Design Goal
Oftentimes, the inspector may show different data types depending on the report’s purpose. For example, to give a simple status update for a project, the inspector may only want to select defects based on a specific date range.
The idea: The report generation flow should be as fluid as when you shop for items on an e-commerce app. Users should be able to curate and review shortlisted data for reporting.
To kick off the experiment, we decided on the epic story to guide the concept designs:
As a user, I want a flexible report-generation process that allows me to add, remove, enrich and review the report items freely without losing my selection before generating the final report.
Design Process
Testing the “Add to Cart” Concept
We were inspired by the “add-to-cart” concept commonly seen in e-commerce. We needed to validate if the idea made sense for users of an inspection app. I mocked up crucial flows for some early user testing.
Concept Validation
I conducted user interviews with 2 of our in-house professional civil engineers and unmoderated testing with 8 internal users, including stakeholders from the commercial team who may not already have biases about the app.
Research Synthesis
I used the Rainbow Spreadsheet for a visual representation of critical observations. It is easier to identify a pattern among testers.
Insights
✅ Users were quickly onboarded onto the “Add to cart” concept for reporting. After getting the first visual feedback when items are added to cart, they seem to get the hang of it.
✅ Most users could locate the “report cart” on the top right of the global nav bar. The interactive counter on the cart icon helps communicate the idea of a “live” cart.
💡 The idea of reporting by report type is still not explicit enough with the dropdown design.
Uncovering a flaw in the solution
Inspectors can capture various data types, such as images, building components, and sensor data for a defect. Due to how the data infrastructure was set up, users could only report one data type at a time, whether a spot, photo, or checklist. This proved to be a friction point for users, as they had to “check out” the cart multiple times based on their selected data types.
Iteration After User Testing
How to gracefully navigate a technical constraint: Guiding users to generate report by report type
To fulfil the ideal state where the user can do combined reporting of the different data types such as spots, checklists, and photos would mean substantial technical effort. As an interim solution, I found a way to explicitly show the user that they can only generate one report type at a time.
I tried out a few UI options to address the user confusion about selecting the data type before tapping the “Generate Report” button.
In the initial design, I tried using a dropdown to show the user they can select the report type before clicking “Generate”. This proved too passive, users didn’t realise it was a mandatory action to proceed. In the new iteration, I tried using a brightly-coloured teal banner at the top to inform users and an alternative design using a side panel to indicate the different report types in the “cart”.
Outcome
After a month of work on concept validation, user testing, and different design iterations, the feature, unfortunately, did not get prioritised in the final product roadmap.
(As of time of writing in 2023) The app is going through a change in data infrastructure that will open up opportunities for us to do combined reporting in the future.
Building the research foundations
The need for flexibility for reporting within the Inspect app is already growing in importance. After digging through some customer-reported tickets in Jira as well as talking to stakeholders in Sales, I’ve been seeing more customer feedback around customisation for their reports.
Despite the feature not making it to the product roadmap in 2022, the design prototypes and insights from testing sessions resulted in many innovative ideas that will add to the case of the feature improvement soon.
