Maatrum Site Inspector: Designing property verification tools for civil site inspectors
Company, 2022
•
Visit Website
Metric 1
Metric Description
Metric 2
Metric Description
Products
Desktop App
Mobile App
Team
Sr. Product Designer (Me)
Head of Design
Product Lead
What I Did
User Research
Design Thinking
UI Design
User Testing
About Maatrum
Maatrum is an India-based full-stack legal verification and property valuation service provider for banks and NBFCs. Their civil site inspectors physically visit properties across the country — from dense urban lanes in cities to remote rural plots — to collect the data that ultimately becomes a legally binding valuation report for mortgage approvals and loan processing.
The Site Inspector App
The Maatrum Site Inspection App is a mobile web application used by civil site inspectors to conduct on-site property valuations. An inspector arrives at a property, verifies their presence via OTP, captures attendant details, photographs, GPS coordinates, boundary information, building measurements, and neighbourhood context — all of which feed into an automated valuation report for the bank.
The app replaces what was previously a fully manual process: inspectors carried a printed A4 data sheet, filled it in by hand, photographed or scanned it, sent everything via WhatsApp, and a separate back-office team re-entered every data point into a web portal. The goal was not just to digitise the form, but to productize the entire field workflow.
Business Requirements & Constraints
I worked closely with Maatrum's product and operations teams to understand the project goals and the realities of field deployment across India.
Maatrum's objectives for the app
Completely eliminate the pen-and-paper workflow and the redundant data-entry step.
Use GPS capture, OTP verification, and mandatory photo evidence to increase transparency and prevent fraudulent "desk-side" inspections.
Ensure every digital data point maps precisely to its location in the final legal valuation report.
Design for inspectors who are often outdoors, holding a phone in one hand and documents in the other, frequently under bright sunlight and on unreliable mobile networks.
Key constraints
The app had to be a mobile web app (browser-based), not native — meaning no access to background sync, push notifications, or native offline capabilities. Every design decision had to account for browser chrome eating 15–20% of screen real estate.
Inspectors ranged widely in tech literacy. Many had used only WhatsApp and basic phone functions. The transition from paper had to feel natural, not intimidating.
Connectivity in the field was unpredictable. An inspector might have full 4G on the main road and zero signal two minutes later at the property site.
Challenges
The core challenge was deceptively simple: take a single A4 sheet with 50+ data fields and turn it into something an inspector could complete on a phone, one-handed, in the sun, with patchy internet — without losing any data or trust in the process.
The paper sheet was unstructured by nature
Inspectors could skip sections, scribble notes in margins, and fill fields in any order. A digital app imposes sequence, which can feel restrictive if designed poorly.
Field conditions are hostile to digital input
Bright sunlight washes out screens. Sweaty fingers cause mis-taps. Inspectors are often moving between rooms, climbing stairs, or measuring walls while trying to enter data.
Inspectors didn't trust the app initially
During early pilots, many inspectors filled out both the paper sheet & the app — doubling their work — because they feared losing data to a crash or connectivity drop.
Regional measurement diversity
Different parts of India use different units — square feet, square yards, acres, cents. On paper, inspectors simply wrote the unitThe app needed to accommodate this flexibility.
Research
Without access to a large pool of users for formal studies, I relied on contextual field observation and direct conversations with inspectors during a 6-week pilot deployment.
I accompanied inspectors on site visits to observe how they worked with the paper sheet — where they paused, what they skipped, what they wrote first, and how they communicated with property attendants. These sessions revealed patterns that no survey could capture:
Inspectors naturally followed a physical journey through the property: arrive, meet the attendant, verify the address, look at the land, go inside the building, then step back and assess the neighbourhood. The paper sheet didn't follow this sequence — it grouped fields by category, not by physical location.
The most error-prone moments were mental math (calculating built-up area from length and width) and unit confusion (writing "30" without specifying feet or metres).
Inspectors treated photos as proof, not documentation. They took far more photos than required and dumped them all into WhatsApp without labels, making it difficult for the back-office to match photos to properties.
The biggest emotional frustration was uncertainty about data safety. Inspectors repeatedly asked: "Did it save? Is it gone?"
I also analysed the existing paper-based data sheet itself, mapping every field to understand which data points could be pre-filled from bank records, which required free-text input, and which could be reduced to a simple tap.
Design Approach: Mirroring the On-Site Journey
The most consequential design decision was to structure the app as a chronological narrative of the inspector's physical arrival and investigation, rather than as a digital replica of the paper form.
DIVIDING FIELDS INTO SEQUENTIAL STEPS
I divided the inspection into eight chronological steps, each corresponding to a real moment in the site visit:
1. Attendant Details → Meeting the person at the site, taking a selfie for proof of presence.
2. Verification → Confirming the address, boundaries, and GPS coordinates against bank records.
3. Land / Plot Details → Assessing the property type, road width, and land size from the outside.
4. Building / Interior Details → Moving inside to capture structure type, dimensions, and condition.
5. Additional Information → Stepping back to assess utilities, amenities, and tax status.
6. Caution Areas → Looking around the neighbourhood for environmental or social risk factors.
7. Comparable Sites → Reviewing nearby reference properties for market comparison.
8. Land Market Value → Providing a final valuation estimate based on everything observed.
This sequence mirrors how an inspector physically moves through a site — from the front gate to the interior to the surrounding area. By the time they reach the valuation step, they've built a mental model of the property in the same order the app asked for data, making the final estimate feel like a natural conclusion rather than an arbitrary number.
I implemented this as a step-by-step progress stepper at the top of the screen. The inspector only ever sees 3–5 fields relevant to their current physical location. This solved the "paper overwhelm" problem: instead of 50 empty fields staring at them, they see a focused, manageable set of inputs with a percentage indicator showing how far they've come.
Selected UX/UI Improvements
Here are the design patterns that formed the backbone of the entire system.
Reducing Redundant Typing
For fields like boundaries, address, and owner name, the inspector isn't discovering information — they're verifying it against bank records. I designed these fields to arrive pre-populated with official document data.
Instead of making inspectors retype what they already see on paper, I implemented a binary Green Check (✓) / Red Cross (✗) validation pattern. One tap confirms the data matches. An "Edit" button appears only as a secondary action — the inspector types only when they find a discrepancy. This dramatically reduced keyboard usage in the field.
Calculators Over Manual Entry
The Built-up Area (BUA) calculation was one of the most error-prone steps on paper. Inspectors measured length and width, then did mental arithmetic — often incorrectly.
I replaced the single "BUA" input field with dimensional inputs for length and width, with the app computing the square footage automatically. A "Calculated based on Building/Elements details" label gives the inspector confidence that the math is handled. They measure; the app calculates.
Contextual Photo Capture
On paper, inspectors took photos freely and sent them all via WhatsApp without structure. I designed labelled photo slots directly within the flow — "Front side," "Left side," "Right side" for land, six dedicated slots for interiors. Each slot uses a one-tap camera trigger with a clear placeholder, so the inspector knows exactly which photo they've taken and which they haven't.
Modular & Adaptive Sections
During the pilot, I noticed inspectors at vacant plots struggling to find building-related fields that didn't apply. On paper, they'd simply skip the section. The early app version forced them to scroll past irrelevant fields.
I made the UI modular: selecting "Plot/Land" as the property type dynamically removes the entire Building/Interior section from the stepper. This "if-this-then-that" logic made the app feel as flexible as paper, but smarter.
Unit Flexibility
To address India's regional measurement diversity, I added unit-selector toggles to dimension and valuation fields. An inspector in Tamil Nadu can work in square feet while one in Kerala uses cents. The app handles normalisation for the backend report — the inspector stays in their comfort zone.
Designing for Extreme Conditions
The "Bulletproof" Offline Strategy
Since this is a mobile web app with no native background sync, I treated the browser's local storage as a temporary vault. Every time an inspector moves between stepper sections, data is automatically cached locally. If the browser crashes or the tab closes, the "In-progress tasks" dashboard lets them tap "Continue" and resume exactly where they left off, because data is tied to the unique MTR case number in the local cache.
Communicating Sync State
Uncertainty about whether data was saved was the inspectors' biggest anxiety. I implemented a bottom-sheet modal that triggers on every "Proceed" or "Submit" tap, displaying "Saving..." or "Syncing with Server" with explicit cautionary text: "Please do not close the app or press the back button while information is being saved."
For heavy media like photos, I designed an async upload queue — photos stay in a "pending upload" state in local storage. If the network is too weak at the site, the inspector finishes data entry, travels to a better signal area, and triggers the final submit from there.
Visual Identity & Design System
Because Maatrum operates in a legal-financial domain but deploys its tools in dusty plots and sun-drenched streets, the visual identity had to balance institutional trust with field usability. I developed the entire design language from scratch, built around three pillars.
1. The "Trust & Comfort" Palette
I built the colour system around deep blue and soft beige.
Deep blue for primary actions, navigation accents, and status elements — signalling professionalism and the institutional seriousness that banks and NBFCs expect.
Soft beige as the base surface, inspired by e-ink readers like the Kindle, to reduce eye strain in bright sunlight and avoid the blinding "white block" effect of standard mobile UIs.
White cards layered on beige for key data groups (Land, Building, Caution Areas), giving structure without heavy borders or visual clutter.
This combination lets the interface feel both official and calm — serious enough for a legal valuation report, comfortable enough for two hours in the field.
2. Typography: Plus Jakarta Sans
I chose Plus Jakarta Sans as the single typeface across the entire app, for its high x-height, clean geometric forms, and excellent legibility at small sizes on mobile screens.
Bold weights are reserved for the most critical identifiers — inspector name, property owner, earnings figures, MTR IDs — so inspectors can scan the screen at a glance while moving or holding equipment.
Regular weights for labels, field descriptions, and secondary information keep the UI quiet and let the content take centre stage.
When a single misread door number or square footage value can invalidate an entire valuation report, typographic clarity isn't aesthetic — it's functional.
3. Tactile Components for Field Use
Given the mobile web context and one-handed outdoor operation, I leaned on tactile affordances rather than flat, ambiguous elements.
Blue gradient buttons on primary actions like "Login," "Send OTP," and "Proceed >>" create a depth effect that clearly signals where to tap — even with sweaty fingers or rushed movements.
Generous touch targets on every input field, dropdown, and button account for outdoor conditions and imprecise taps.
Consistent status indicators: green checkmarks for verified fields, percentage badges in the stepper, and the large green success modal on completion. These give inspectors — and the back-office — immediate visual confirmation of data integrity at every stage.
Together, these elements form a compact, reusable design system: buttons, input fields, stepper states, status chips, photo slots, and cards that can scale to new features without fragmenting the experience.
Results
The app was deployed through a 6-week pilot with active inspectors across multiple regions. During the initial weeks, many inspectors performed "double work" — filling both the paper sheet and the app — which we expected and used as a learning phase to identify where the app didn't yet match the flexibility of paper.
By the end of the pilot, 95% adoption was reached, with inspectors voluntarily abandoning the paper sheet entirely.
Key outcomes:
The redundant data-entry step was completely eliminated. Back-office teams received structured, geo-tagged, time-stamped data sets ready for final valuation — no more deciphering handwriting or hunting through WhatsApp threads.
The step-by-step stepper reduced average inspection completion time compared to the paper-then-data-entry workflow.
GPS capture, OTP verification, and mandatory selfies established a verifiable chain of proof, increasing transparency and trust for the banks commissioning the reports.
The modular UI and unit-selector patterns proved scalable across regions with different property types and measurement conventions.
Summary
By mirroring the inspector's physical journey rather than digitising a paper form, I transformed a 50-field data sheet into a focused, step-by-step experience that earned the trust of field workers operating in some of India's most challenging conditions.
Metric 1
Metric Description
Metric 2
Metric Description
Metric 3
Metric Description
By mirroring the inspector's physical journey rather than digitising a paper form, I transformed a 50-field data sheet into a focused, step-by-step experience that earned the trust of field workers operating in some of India's most challenging conditions.
James Cao
CEO at Company