Structural Analysis Platform

Snapshot

Nireekshan is a structural health monitoring platform for bridges that replaces slow, dangerous, manual inspection with a digital pipeline. That pipeline already produced large volumes of accurate structural data when I joined, but it could not yet turn that data into a decision a stakeholder could make in one look and defend. I designed the layer that closes that gap, and I owned three surfaces: the structural asset dashboard and its visualization, the alerting system, and the AI assistant. The central design problem was not "make it look good." It was trust and clarity under accountability: how do you show comprehensive structural truth to a mixed-expertise audience that carries life-safety liability, without burying the one fact that should drive the next decision?

I delivered the information architecture, visualization logic, severity model, and AI assistant experience for three decision surfaces, and pressure-tested them through working sessions with civil-engineering domain experts and professors who study structural health monitoring. My academic background is civil engineering, so I owned the domain signal rather than inheriting it. Scope is honest: I designed the decision layer that sits on top of a team-built capture-and-detection pipeline, not the pipeline itself.

---

Context: what Nireekshan was solving

India's bridges are ageing, and the country still inspects most of them by sending people to look. Manual visual inspection is slow, physically dangerous, and incomplete. It depends on whichever expert showed up that day, which introduces perspective bias and safety blind spots, forces expensive traffic shutdowns, and routinely misses early-stage damage. Extreme weather now accelerates deterioration faster than this method can keep up.

Nireekshan's bet was that you can remove the human from the dangerous capture step without removing human judgment from the decision. The platform gathers and grades the evidence; a person still decides what to do. My surfaces are the seam between those two halves, and that seam is where the hardest design constraint lives.

That bet creates the hardest design constraint in the whole product: the user is personally accountable for a life-safety decision, so the cost of getting the interface wrong is not a bad experience, it is a wrong call on whether a bridge is safe to carry traffic. Every design decision downstream answered to that constraint.

Primary user: a Public Works Department (PWD) officer, accountable for prioritising which assets get attention and budget and for declaring a structure fit or unfit for service.

Primary user: a railway or metro authority, accountable for operational safety, including whether traffic runs over a structure today.

Secondary user: a civil engineering and maintenance engineer, accountable for diagnosing the defect, specifying the repair to code, and signing off that the work restored integrity.

The UX north star the team set was "one-look, one-decision": a stakeholder remotely diagnoses structural health and acts with confidence. Speed, clarity, and trust in the data were the three pillars I designed against.

---

My role and what I actually owned

I owned three surfaces, and I want to be precise about the boundary, because the precision is the point. Nireekshan is a large system built by a team, and the capture-and-detection pipeline that produces the structural data was built by engineers and researchers, not by me. What I designed is the layer where that output becomes a human decision. I worked directly with the engineering team on what the data could express and with civil-engineering domain experts and professors on whether the information surfaced matched how an accountable engineer reads a structure. Being honest about this matters more than it looks: claiming you single-handedly built an entire platform invites skepticism, while owning a clearly-scoped surface and naming your collaborators reads as senior.

What I owned:

---

How I approached it

My civil engineering background is the reason this work is mine and not a generalist's, and it inverts the usual early-stage division of labour. The common pattern is that a designer inherits domain framing from a stakeholder and translates it. I did the opposite. I read defect reports the way the user reads them, which meant I could decide which fact matters to which role in which moment instead of asking someone to tell me. I then took that reading into working sessions with researchers who actively study structural health monitoring and reframed the platform's information architecture with them, so the right data surfaces in the right context rather than all data surfacing at once. That is the difference between collecting requirements and owning the domain signal, and it is where I held the user truth on this project.

My working sequence was deliberate. First, understand each user's accountability and find where their decision actually stalls. Second, map what each role needs to decide and therefore needs to see first. Third, identify the riskiest surface, the one where a wrong read causes the worst outcome. Fourth, design outward from that surface so the highest-stakes decision sets the standard for everything else. I treated the structural-health dashboard and the alert that fires off it as the spine of the product and let every other surface support the decision they drive.

A principle I held throughout: reduce noise until only the decision remains, then make the supporting truth reachable in one more step. One-look clarity on top, comprehensive structural truth one layer down. Never one at the expense of the other.

---

The three surfaces, framed as decisions

I will walk through the work the way I designed it, leading with the decision and the tradeoff in each, not just the screen.

1. The dashboard: default the view to the decision each role owns, not to the full dataset

Decision: Make the dashboard role-aware, so the first screen answers the question that specific user is accountable for, and let the full structural data sit one deliberate layer below.

Why: A PWD officer and a maintenance engineer look at the same bridge to make different decisions. The officer needs to know which assets across a portfolio demand attention and budget, and whether this structure is fit for service. The engineer needs to know exactly where the damage is, how severe, and what the code says about it. Showing both users the same dense defect view fails both: it buries the officer's prioritisation signal in detail they cannot act on, and it makes the engineer hunt for the specifics they need. So each role gets a default tuned to the decision they own.

The actual design problem: how much engineering detail to expose before it becomes noise for a non-specialist decision-maker. The SHI exists precisely to compress structural complexity into one objective score, which makes it the natural one-look anchor, but a single score can also hide the very thing an engineer needs. I resolved this with progressive disclosure organised the way engineers already think about a bridge, and I held three structural decisions together to do it.

First, role-based defaults. The officer's default leads with the SHI, the assets ranked by it, and what changed since last inspection, because their decision is prioritisation across a portfolio. The engineer's default leads with the span-wise breakdown, the damage heatmap, and the defects in context, because their decision is diagnosis and repair. The railway or metro authority's default leads with the single fitness-to-operate read and any active risk, because their decision is whether traffic runs today. One dataset, three front doors.

Second, a disclosure hierarchy that matches the user's mental model. The structure reads SHI for the whole asset, then span by span, then the specific defect with its location on the heatmap. Span-wise organisation was not a layout choice. It mirrors how inspection reports and engineers already segment a structure, so the interface matched an existing mental model instead of imposing a new one. Detail unfolds downward in the order the user would ask for it.

Third, the heatmap as spatial truth. A defect described in text is a fact; a defect shown in its place on the span is a diagnosis. The damage heatmap carries location so the engineer reads where the structure is failing, not just that it is, and so the officer can see at a glance whether damage is concentrated or spread. The heatmap turns the SHI from a number into something a viewer can interrogate in one more step.

Tradeoff I accepted: the officer's default view deliberately withholds detail at first glance, which risks an officer feeling they are not seeing everything, and it depends on the disclosure path being obvious enough that no one mistakes the summary for the whole truth. I accepted that risk because the alternative, showing everything to everyone, defeats one-look on the surface where speed of judgment matters most. I treated the summary as a promise that the underlying truth is always one reachable step away, never as a substitute for it.

2. The alerting system: an alert is a decision waiting to happen, not a notification

Decision: Define an alert as a code-relevant state change that demands a human decision, separate it cleanly from information that does not, and make every alert carry the next action with it.

Why: A monitoring platform that detects defects continuously can generate noise endlessly, and a stakeholder accountable for many assets will start ignoring alerts the moment they stop meaning something. The well-documented failure mode in any alerting system is alert fatigue: fire too many low-value notifications and people learn to dismiss all of them, so the one that mattered gets dismissed with the noise. In a life-safety system an ignored alert is the worst possible failure, so scarcity is a feature. An alert has to earn its interruption.

The severity model. I tied severity to the defect classification the Indian Standard codes already define rather than inventing a parallel scale. Engineers are trained on those classifications and carry them in their judgment, so an alert that speaks in the language of the codes is one they trust on sight and can defend to whoever they answer to. Severity communication had to be unambiguous at a glance and consistent with what the engineer would conclude if they read the underlying report themselves. The colour and weight of an alert encode severity, not decoration, so the eye reads urgency before it reads words.

The problems I solved at once:

First, what triggers an alert versus information. A detected defect becomes an alert only when it crosses a code-defined threshold of concern or changes state in a way that affects a decision. Everything else stays as reviewable information on the asset, present and inspectable but not interrupting. The threshold is the gate, and the gate speaks the codes.

Second, how to avoid alert fatigue. I biased the system toward fewer, higher-fidelity alerts and let borderline items live as information the engineer can choose to review. The goal was a credible stream a user actually reads, not a complete one they learn to tune out. Severity decides prominence, so the load on the user's attention stays proportional to structural importance.

Third, how to keep an alert from being a dead end. Every alert routes to a decision. It links to the affected span and defect, surfaces the relevant code guidance, and presents the next action, whether that is inspect, restrict load, close to traffic, or schedule repair. An alert you can only dismiss is a failure of design, so I built each one as the front of a workflow rather than the end of a notification.

Tradeoff I accepted: biasing toward fewer alerts accepts a real under-alerting risk on borderline cases. I judged that a credible alert stream the user actually reads is safer than a complete one they learn to ignore, but this is the trade-off I would most want to validate with real threshold data and user behaviour over time.

3. The AI assistant: scope it down until it is trustworthy, not up until it is impressive

Decision: Design the LLM assistant as a workflow-embedded advisor scoped to two things, structural codes and repair strategy, reached from the defect the engineer is already looking at, never as a free-floating general chatbot.

Why: Engineers carry liability for the decisions they make on this guidance. A generic chatbot that answers anything confidently is exactly wrong for a liable user, because confidence without provenance is a trap. The assistant earns its place only if it makes the engineer faster at decisions they can defend, not if it makes decisions for them.

The actual design problem: designing for trust under liability. I held three decisions together.

First, placement. The assistant opens in the context of a specific span or defect, so its answers are grounded in what the engineer is actually deciding rather than in a blank prompt. The question the engineer brings to it is already half-formed by the screen they are on, which keeps the interaction precise.

Second, scope. It answers what the code says and what the repair options are, and it stays away from the one question the engineer must own, which is whether the structure is safe. Drawing that line is the design. The assistant advises on the knowable, code-defined parts and refuses to impersonate the accountable judgment.

Third, provenance. Guidance points back to the code clause or source behind it, so the engineer can verify and cite it rather than trust it blind. For a user who signs off on public safety, a citation is worth more than a confident sentence, because it is the thing they can defend.

How I kept it from being a generic chatbot. The framing throughout is that the assistant proposes and the engineer decides, the same trust contract that governs the alerting and the dashboard. It is contextual, scoped, and sourced, so it reads as an instrument inside the workflow rather than a chat window bolted onto the side of the product.

Tradeoff I accepted: a scoped, citation-backed assistant is less dazzling in a demo than an open chatbot that appears to do everything. I accepted a narrower, less flashy tool because for a user who signs off on public safety, trust beats breadth every time.

---

The hardest design tension, stated plainly

Every meaningful decision in Nireekshan traced back to one tension: comprehensive structural truth versus one-look clarity, for a decision-maker who is both liable and of mixed expertise. The whole value of the platform is that it captures more complete structural truth than a human inspector ever could. The whole promise of the interface is that a stakeholder can act in one look. Those two pull in opposite directions. Show everything and you destroy the one-look. Simplify too far and you hide the fact that should have stopped a truck from crossing. My job was not to pick a side. It was to design the seam between them: keep the top layer honest about risk and ruthless about noise, and keep the full truth one reachable step beneath it, organised the way the user already thinks. The same principle governs the tension between objective machine data and the expert judgment these users are trained to trust. The design never positions the AI as a replacement for that judgment; it positions AI output as evidence that supports the accountable human's decision and shows its sources, so the expert stays in charge of the call they are liable for. That balance is the actual product.

---

Outcome and impact

In three months I took the decision layer of Nireekshan from a data pipeline without a human verdict to a complete, validated design across three surfaces: the role-based dashboard and its SHI and heatmap visualization, the alerting system with its code-tied severity model and action routing, and the workflow-embedded AI assistant.

The impact I can point to concretely:

I designed each surface around the decision a specific accountable user owns, which is what makes "one-look, one-decision" real rather than a slogan. The dashboard gives each role a first screen aligned to the call they make, the alerting model turns a potential firehose of detections into a credible and action-bearing signal, and the AI assistant became a tool a liable engineer could defend using, because it cites the codes instead of merely sounding authoritative.

I validated the riskiest parts with the people whose judgment the product has to match. Working sessions with civil-engineering domain experts and the professors researching structural health monitoring pressure-tested whether the information I surfaced matched how an accountable engineer actually reads a structure, and they specifically confirmed that the role-based prioritisation and the code-aligned severity language matched professional practice. Validating the highest-stakes parts with real domain authorities before development is the cheapest possible time to find problems.

I owned the decisions that define how the product feels to a clinician of structures: the role-based default views, the SHI-to-span-to-defect disclosure, the code-grounded severity model, the alert-to-action routing, and the advise-not-decide contract on the AI assistant. These are the parts an accountable user feels, and they were design calls, not features handed to me.

(Out of respect for the company's confidentiality, I have described the thinking and the decisions rather than showing the proprietary screens or internal data.)

---

What I learned

Domain fluency lets you set defaults, not just gather requirements. I came in able to read defect reports as a user rather than as a translator, and the most valuable thing that bought me was the authority to decide what surfaces first for each role instead of asking users to configure it or asking a stakeholder to tell me what mattered. In a one-look interface, the choice of what appears first is the whole product, and I learned that domain knowledge is what earns you the right to make that choice with conviction.

In a life-safety system, the absence of an alert is itself a claim. Deciding what not to surface carried as much weight as deciding what to show. Every defect I let stay as quiet information rather than an alert was an implicit statement that it did not need a decision today. That reframed alerting from a notification feature into a chain of consequential editorial judgments, each of which had to be defensible against the code, and it taught me that in high-stakes UX the quiet decisions are often the loud ones.

Trust from a liable user comes from showing your work, not from sounding sure. The AI assistant taught me that for a professional who signs off on consequences, fluency is a liability and provenance is the feature. Citations, scope limits, and a clear line between advising and deciding did more for trust than any amount of conversational polish. The smart feature is only unlocked by the user trusting it, and trust is built in the moments where the system shows its sources and hands the call back.

Clarity for mixed-expertise users is a layering problem, not a subtraction problem. I stopped trying to find the one view that worked for everyone and instead designed the right top layer per role with the full truth reachable underneath. Simplification hides risk; layering reveals it on demand. Treating domain constraints, the codes, the liability, the mixed expertise, as the thing that sharpens the design rather than the thing that limits it produced a cleaner result than an unconstrained approach would have.

---

What I would do differently

Two things, both honest and specific to this scope.

I would validate the one-look hierarchy with a timed first-decision test on the administrative user, not just the engineer. I designed the role-based defaults from the expert sessions and my own domain reading, and the engineer's view got the most expert scrutiny because the experts are engineers. The PWD officer's prioritisation view leaned more on inference about how an administrator decides under time pressure. Given more runway I would put an officer in front of the default screen and ask them to make a fit-for-service or budget-prioritisation call from it alone, to confirm the summary holds without the detail and that no one mistakes it for the whole truth. That is exactly the kind of gap a designer cannot close from their own desk.

I would design the disagreement path for alerts, not just the happy path. I tied severity to the code classification, but I did not design what happens when an engineer judges an alert's severity to be wrong, and for liable users that path matters as much as the alert itself. I would add a lightweight recalibrate-or-dismiss-with-reason action that captures the expert's override in an audit trail, both because liability demands a defensible record and because those overrides are exactly the signal needed to tune the thresholds I admitted were the riskiest trade-off in the alerting system. Designing the seam where the expert overrules the machine is the part of the trust model I would most want to finish.