SiteLens

SiteLens 2.0 is a B2B enterprise web application for property inspection, construction quality management and QC operations. It brings project, unit, inspection, defect, contractor and quality information into one operational system.

• What it manages: projects, units and inventory, inspections, defects, contractors, QC teams, quality checks, re-inspection and final status.
• How it works: inspection teams capture quality information and evidence, which then moves through review, assignment, rectification, re-inspection and QC validation.
• Why it was complex: six web roles worked with the same information, but each needed a different view of what mattered, what needed attention and what came next.

Product name and selected details are anonymised for confidentiality.

The client already had a working product that had grown one requirement at a time, without becoming a coherent operating model. I spent about 1–1.5 weeks with stakeholders learning the business, user responsibilities, roles and workflows before starting the audit. The guiding question: how does this business move a property from inspection to a validated final state?

• Operational efficiency: less effort to create, assign, review and manage inspection work.
• Faster defect resolution: shorter time from identifying a defect to validating the fix.
• Project visibility: clearer view of project health, failed units, defects and QC status.
• Quality governance: a clear trail from inspection to remediation, re-inspection and validation.

The aim was not six separate experiences. It was to understand how each role worked with the same operational data.

• Information overload: everything was shown to everyone, with little role-based priority.
• Deep navigation: simple questions like which unit failed, who owns it and whether QC validated it took several clicks.
• Duplication: the same information appeared in several places, blurring the source of truth.
• Weak hierarchy: primary decisions competed with supporting detail.
• Role-blind structure: six roles shared one broad structure despite different responsibilities.
• Fragmented experience: features worked individually but didn't feel like one system.

“I know the information exists, but it takes too much effort to find what matters to my responsibility.”

I deliberately postponed the visual redesign. Restyling an inherited enterprise product would only have polished the fragmentation.

1. Screen and feature inventory to separate real capabilities from repeated ones.
2. Navigation mapping to find deep paths and information far from the task.
3. Duplication analysis to find overlaps and consolidation candidates.
4. Role-to-screen mapping to see which roles used which screens, and why.
5. Stakeholder walkthroughs to confirm the business intent behind each feature.
6. Workflow mapping around responsibilities, decisions, actions and connected workflows.

Six roles could have meant six dashboards, but that would multiply maintenance and inconsistency. Every role used the same entities: projects, units, inspections, defects, contractors and QC status. What differed was the decision each role had to make.

The data could be shared. The priorities could not.

• Shared across roles: navigation, tables, filters, cards, status patterns, detail views, visual language, components and states.
• Adapted per role: information priority and KPIs, primary actions and permissions, content hierarchy, decision context and next actions.

The product was reframed around the operational lifecycle instead of a set of screens, and every dashboard answers four questions: what is happening, what needs my attention, what should I investigate, and what do I do next.

A Project Head needs to know which units need attention. The redesign moved that decision onto the project overview and revealed supporting detail progressively.

Principle: surface the decision first, then provide the detail.

Benchmark figures for this case study, to be validated against production or usability data.

• North Star: operational workflows completed, from inspection through defect resolution to QC validation.
• Efficiency: time to review, rectify and close a defect; navigation depth; task time.
• Usability: task completion, discoverability, error rate and workflow abandonment.

AI sped up synthesis, exploration and documentation. Product judgment stayed grounded in business context, role responsibilities and stakeholder validation.

• Clustering the audit inventory into duplicates, overlaps and consolidation candidates
• Drafting a role × responsibility × information matrix from stakeholder notes
• Exploring alternative navigation structures and workflow models
• Challenging journeys for missing states, extra steps and edge cases
• Exploring clearer status names, labels, empty states and copy
• Speeding up component notes, handoff annotations and UX rationale

• Product strategy: moved the conversation from screens to workflows, responsibilities and decisions.
• Information architecture: rebuilt the structure around a shared data model and role-specific contexts.
• Role-based experience: defined how six personas see, interpret and act on the same data.
• Component strategy: reusable interaction patterns instead of isolated screens per role.
• Design direction: a shared mental model for stakeholders, designers and engineering.

The most important decision wasn't a component or a dashboard. It was recognising that the product needed a clearer model of the business behind it. The answer wasn't six products, but one shared foundation that lets different people make different decisions from the same data.