
Overview
Two Tableau dashboards built for Trudanda, a data processing company serving the mortgage industry, and delivered through Trudanda to a mortgage lender whose production teams had never been measured. Trudanda’s model is to link a client’s data from multiple systems into production dashboards and scorecards; I was the developer behind this client’s processor scorecard and cycle time dashboard.
The processor scorecard reports per-processor KPIs — funded units, closing exceptions, clear-to-close counts, suspended loans, underwriter touches, and several stage durations — each with a trailing twelve-month lookback, a month-to-date or full-month toggle, and color keyed to distance from the group average. The cycle time dashboard covers roughly thirty-four stage-to-stage durations across processing, underwriting, and closing, plus distribution and Pareto views where a manager can select a duration band and see exactly which loans fall in it. Four scorecard iterations and three cycle-time iterations went out over about two weeks.
The mechanism that made this work was not the visualization, it was the date logic underneath it. Which date field anchors a metric decides what that metric actually means, and the answers differed per metric: production and cycle times keyed off the funding date, suspended loans off the underwriting submittal date because a suspended loan may never fund at all, and shipped-to-purchased off the investor purchase date. Get that wrong and the dashboard is confidently incorrect rather than obviously broken. I worked from a static sample extract rather than the live warehouse, so every iteration shipped with a numbered list of assumptions and open questions the client could correct before the logic hardened.
The constraint that shaped the whole engagement was the audience. These were teams new to measurement, and a dashboard that is technically complete but hard to read does not get adopted — it gets ignored, and the reporting investment produces nothing. That pushed the design toward fewer, plainer views, tooltips that explain a distribution in plain language, and honest reporting when a layout stopped rendering usefully at normal screen sizes. It also meant naming the trade-off on polish directly: formatting can absorb unlimited time, so I asked for a time budget for it rather than pursuing pixel-perfect layouts against an open-ended clock.
The pattern worth reusing is the sequencing. Correct metric definitions first, working interactions second, styling last and time-boxed — with a short written list of open questions attached to each iteration so the client’s domain knowledge, not the developer’s guesses, resolves the ambiguities.