Confidentiality
This case study omits or anonymizes certain details (data, copy, and internal documentation) to respect client confidentiality. It is shared here privately for portfolio and discussion purposes only.
Full Case Study: This project is large feature wise. If you wish to review, please have a look below with the same password as this site:
Full Case Study: This project is large feature wise. If you wish to review, please have a look below with the same password as this site:
Nova (TrueSpark)
Enterprise web app · Residential Real Estate Appraisal · 1-year engagement · 2-person design team
Nova automates the most time-consuming parts of building a Uniform Residential Appraisal Report (URAR): data import, market analysis, and comparable adjustments, bridging legacy form-filler tools with a defensible, regulator-compliant output.
The Problem
The client's existing tools (Spark and Synapse) were two separate products with no shared design language, inconsistent interaction patterns, and a UI that appraisal professionals described as harder to use than the 1990s-era government forms they were meant to replace. The core design challenge wasn't styling but rather merging two complex professional tools into one coherent product without disrupting a workflow that appraisers had practiced for decades.
My Role
Senior UX Designer: Co-led the audit that reframed the engagement from a UI refresh to a full end-to-end redesign. Led interaction design and IA across Session, Data Manager, Market Trends, Grid, and Adjustments. Owned the design system and developer handoff.
Design Constraints
Desktop-first for professional users (50+, transitioning younger). URAR/1004 compliance non-negotiable. Fundamental data structures fixed due to engineering timeline. One year to ship.
This case study is in three parts:
Section A — Workflow How we restructured two fragmented tools into a single, navigable appraisal workflow without disrupting how appraisers think about their work.
Section B — Data Legibility How we made dense, regulation-driven data readable and actionable without sacrificing the precision professionals require.
Section C — Design System How we built and maintained a component library in parallel with production, and how it enabled a non-technical stakeholder to navigate the product independently.
Section A — Designing the appraisal workflow
Reframing Spark and Synapse into a single Nova workflow that matches how appraisers actually think about sessions, data, and reports. Both tools began as companions to legacy form-fillers, but had grown into a workflow of their own. The first step was to understand where that workflow was breaking down.
Full Map of the existing production app of Spark as current appraisers experienced them.
Left: Upon logging in, the user is prompted to upload property information. The subject is a single property that would be analyzed for the purpose of appraising its value.
Right: The Comparative Grid, where the subject property is compared to similar properties in the neighbourhood.
Zoomed-in view of the Market Analysis area, where an entire neighbourhood would be analyzed to describe where the general market is trending. This data is then calculated to help prove the accuracy of the appraisal. Here, there are many separate steps and screens appraisers had to navigate to analyze trends and cost data.
Function sitemap / Nova structure
With testing the production app and the screenshot map as reference, we broke down the app into an exhaustive map of all functions that can be done. This became the central argument for restructuring the product's information architecture rather than reskinning the existing one.
Snippet of the Market Analysis, with functionality that can be done for each page.
Full Function Map of the current Nova SaaS.
Function Map
The audit revealed a core tension in the legacy tools. Spark and Synapse were built around maximum customization, giving appraisers flexibility to configure nearly every aspect of their workflow. In practice, this created high cognitive load and a structural problem. With so many configuration paths, appraisers could inadvertently produce outputs that drifted from the URAR/1004MC structure required for regulatory submission, or customize in a way that makes the tool unintuitive for future uses. A tool that lets professionals customize their way out of compliance is a liability, not a feature.
Nova was restructured around user intention instead. Rather than leaving appraisers to configure their own path through a flat grid, the app organizes around a clear default sequence: upload data, review market trends, build the grid, run adjustments, calculate cost approach, export. Appraisers can still work within any section independently. For example, evaluating market trends, or filling in the grid without a full upload. The structure provides a coherent through-line that reflects how a defensible appraisal is actually built. Ambiguities in how to group functions were worked out with the client team during the mapping phase, using the Miro board as a shared working surface before any wireframing began.
In the legacy Spark grid, blue text served multiple purposes simultaneously. To indicate the comp columns are draggable, clickable feature labels, and general styling. Clicking a feature label mid-analysis could navigate away from the grid entirely, or cause that row to disappear after a settings change (a bug).
The legacy tool embedded configuration directly in the working view. Feature labels in the grid were clickable — opening dropdowns to swap what data appeared in each row. Changing a feature mid-analysis could cause that row to disappear entirely, with no explanation of why. An appraiser had no reliable signal for what clicking would do versus what dragging would do, since blue text served both purposes simultaneously.
Nova separates the two. Settings made once live in a dedicated area, accessed contextually from the grid. Decisions made during an appraisal stay in the grid. The principle behind the restructured IA was straightforward: the interface should reflect what an appraiser is trying to do at that moment, not offer a configuration system disguised as a workflow.
Nova Intention Sitemap, organizing the app into a single flow based on user intention: Home → Session → Get Data (Upload) → Market Trends → Grid → Adjustments → Cost Approach → Export.
Nova Intention Sitemap - Snippet. Top: For comparisons between individual comps, the user would go to Property Information to upload this data first, particularly for the subject property. Bottom: Based on the features of the subject properties and its comps, the true appraised value can the calculated in another screen called Cost Data.
Process – from flows to UI
User Story Flows
With an understanding of the functionality of the current app, and user needs, we made an exhaustive list of user stories. For major stories, flows illustrate how a user can navigate effectively.
User story flow of creating a new session (a document) and uploading capturing each action an appraiser takes—from creating sessions and uploading data to confirming comps and exporting reports.
Information Architecture
Connecting user stories together, a 'proto-wireframe' of the new app can be built which creates a high level of the new application's backbone.
Information architecture for the revamped app, mapping user stories into a coherent navigation and page structure.
Page User Flow
Then for each page, needs and functions are drawn as flows in granular fashion. This builds out what and how functions, modals, etc. would be used for the redesign.
Page-level user flow showing how appraisers move through Nova from starting a session to exporting a report.
Wireframing
Lastly, wireframes are made to define structured functions.
Early wireframes translating flows and IA into concrete layouts for sessions, Market Trends, and the comparable grid.
Home & Session model
Nova introduces sessions as the unit of work. The design team's initial proposal used "file" or "document" as the container model, familiar mental models with low overhead. The product owners pushed back for a specific reason: in an appraiser's workflow, "file" already refers to the 1004MC export, the deliverable submitted to regulators. Using the same word for the working container would create direct ambiguity at the most consequential moment in the workflow. "Session" was the chosen compromise, unambiguous if not perfectly intuitive, and one a professional user learns quickly with repeated use.
Home / Sessions screen where appraisers can create, open, and manage appraisal sessions by subject property.
Session header keeps property context, status, and navigation to Market Trends, Grid, and Adjustments visible throughout the workflow.
The Sidebar which acts as the navigation throughout the entire experience.
The legacy tools placed section navigation in the top-left, a location users expect to find a logo or home link, not workflow navigation. A persistent sidebar resolves the pattern conflict while adding a secondary benefit: icons are ordered top-to-bottom to mirror the recommended appraisal sequence. Appraisers develop an implicit sense of progress, reaching the Export icon signals the work is done, without requiring explicit progress indicators. Because appraisers sometimes work non-linearly, jumping to a single function rather than following the full sequence, the sidebar supports both workflows without privileging one over the other.
Get Data & Data preview
The Get Data flow consolidates upload, dataset typing, preview, and validation so issues surface before appraisers reach the grid.
Get Data step where appraisers drag-and-drop MLS and other files, assigning each to the correct dataset type in a single place.
Section B — Making appraisal data legible
Turning dense MLS, grid, and adjustment data into views appraisers can quickly scan, trust, and defend in their reports.
Market Trends & 1004MC
The legacy Market Trends view was built to mirror the 1004MC form exactly, a regulatory requirement at the time. When Fannie Mae updated their guidelines mid-project, the 1004MC was no longer mandatory, giving more room to design a system from first principles.
The legacy Trend Dashboard had a critical discoverability problem: the charts, the visual evidence appraisers need to defend their conclusions in their report, were hidden behind a button. An appraiser had to already know they existed.
The two-column layout borrows a pattern appraisers use every day: email. The left column shows a compact summary of every market indicator. Reviewing and confirming the calculated values on the left is sufficient to complete this section. The right column shows full chart detail on demand, for appraisers who want to inspect how a trend developed before confirming it.
The client team questioned whether the right panel added value and suggested collapsing to a single column. An A/B test with appraisers was run. They unanimously preferred the two-column layout and could not explicitly state why. Seeing numbers alongside trend charts in the same view appears to provide confidence in the data without requiring extra navigation. The right column was not redundant, it was reassurance.
The 1004MC form view remains available for appraisers who prefer working directly within the legacy format.
The original Market Trends layout presented all indicator data in a single scrolling column. Reviewing an indicator required reading across the page without a stable reference point. Two layouts were tested: the single-column format carried over from the legacy tool, and a two-column layout with the indicator list on the left and expanded details on the right.
Appraisers consistently oriented faster with the two-column version. Having the list visible while reading details reduced re-navigation and matched how appraisers described the task: checking a set of indicators against each other, not reading them sequentially. The two-column layout shipped.
Comments panel open
The auto-generated narrative comments were not a Nova invention. They existed in the legacy tool and were one of the few things deliberately kept. The philosophy driving Nova is anti-engagement: the tool should handle the boring copy work so appraisers can focus on judgment, site visits, and professional expertise rather than transcribing figures into form fields. Auto-generated comments are a direct expression of that philosophy. Nova drafts the narrative from the data, the appraiser edits and confirms. The appraiser's expertise stays central; the clerical work does not. Instead, we made it more intuitive. On clicking a sentence, a popover shows where the sentence comes from with the user being able to remove or edit the comment.
Comparable Grid
The Grid allows appraisers to compare subject and comps across sales, rentals, and listings in a structure that respects legal forms but improves usability. Once a particular property has been verified, the user can confirm with the designated 'Verify Property' at the bottom. If the property was previously verified, it would auto-verify.
Sales grid showing subject and comparable properties across key features, aligned to the traditional Sales Comparison Approach format.
Hovering over any grid row reveals a tune icon. Clicking it opens a scoped popover with contextual options for the selected row: hide it, edit it, group it, or include it in the report. Choosing to edit navigates directly to that feature's settings section, opening a right panel of settings scoped to that feature. The appraiser can then edit without leaving the grid.
The data entry popover lets appraisers search for values from connected databases such as MLS sources, industry-defined standards, or entries previously logged by teammates. From the same popover, they can propagate a value across all columns or flag the cell with a contextual message to a teammate.
Adding new parameters works differently. Because this happens during active appraisal work, it's handled through the data entry flow rather than through settings. On-the-fly creation is treated as part of building the report. The distinction between "setup" and "in-session work" is deliberate and consistent throughout the grid.
The message button lets appraisers flag a cell for a teammate's review without leaving the grid.
Grid Data Entry Helper. When the user clicks to edit or add data, this popover allows for searching and adding data quickly.
Warnings like “Lot Size isn't bracketed” flag statistically weak areas so appraisers can adjust their comp set or ranges.
Map view gives spatial context; hovering markers reveals property details so appraisers can confirm proximity and neighbourhood comparability.
Grid responsiveness & density
The grid uses a hybrid responsive system. Fixed breakpoints define layout zones, and ems handle proportional scaling within each zone. This was necessary because the grid responds to both horizontal and vertical viewport changes simultaneously, an unusual constraint for most web interfaces, unavoidable for a spreadsheet-style view used across hardware ranging from the small 600px-height older laptops to large desktop monitors.
By resetting the root em value at each breakpoint, every element scales proportionally from a single value: cell height, font size, and padding move together. The spec defines four vertical breakpoints, each incrementing cell height and font size so the grid never loses its proportional rhythm. For appraisers in their 60s, 70s, and 80s on aging hardware, legibility scales to the screen available without the development team maintaining separate layout rules for every configuration. Browser zoom accessibility is handled correctly as a byproduct.
By resetting the root em value at each breakpoint, every element scales proportionally from a single value: cell height, font size, and padding move together. The spec defines four vertical breakpoints, each incrementing cell height and font size so the grid never loses its proportional rhythm. For appraisers in their 60s, 70s, and 80s on aging hardware, legibility scales to the screen available without the development team maintaining separate layout rules for every configuration. Browser zoom accessibility is handled correctly as a byproduct.
Upper Row: Like standard responsive browser experiences, the comps columns scale at fixed sizes as the width increases.
Lower Row: At smaller viewport heights, cell height and font size decrease to ensure at least ~15 visible rows without sacrificing readability. At larger heights, text and cell size scale up so appraisers with bigger monitors gain visibility and comfort instead of wasted space. With the Root Em set at 10px, rows and font sizes scale and remain proportional as the vertical viewport scales.
Section C — Design System
Client/Developer facing Figma File, on the Design System page. The pages are organized to allow for easy recall of components.
Figma page of the Grid section. On the left, the pages are organized and labelled by major feature of the app, on the right, are pages and components listed by user stories and functions. The pages are designed to ensure developers and stakeholders can understand how features work and be able to quickly find the screen.
The Challenge
Property appraisal software is data-dense by nature. Grids, charts, financial inputs, adjustment panels, and comparative analysis all compete for space on a single screen. Without a coherent system, UI decisions become inconsistent as developer hand off becomes a bottleneck, and leads to confusion and tech debt.
The Goal
The TrueSparks design system was developed alongside rapid production, by building and iterating upon components and instances as features were in development. Building components alongside production rather than ahead of it kept design debt to a minimum. For a product at this scale, with patterns that only became clear through use, this was the more pragmatic approach.
7 Categories
A–F component sections
Dual-size icons
20 / 24px system-wide
260+ Icons
20px & 24px variants
Responsive type
4 breakpoints
Miro as Staging Layer
When iterating on the Figma files, Miro served as an intermediate organization step. Components were screenshotted, reviewed, and organized in Miro before being committed back to both files, referenced but independent. Miro provided a neutral staging layer, separate from both Figma files, where organization decisions could be made before being committed. This gave thinking space to understand how to organize.
The client-facing Figma file was rebuilt from scratch three times over the course of the project. The issue was not that previous versions were wrong but that iteration accumulates entropy: multiple versions of the same component used across different screens, outdated layouts kept for reference but gathering space, instances that had drifted from their source. Over time this creates a maintenance burden, and ambiguity about which version is canonical.
Rebuilding at key intervals meant components were brought to their cleanest state at a point when the product's patterns were mature enough to define them properly. Each rebuild was faster than the last. The third version benefited from a full year of iteration: components were stable, naming was consistent, and nothing was carried forward that did not earn its place.
Foundations
Three primitives underpin the entire system. The color palette uses the warm forest earth tones in reflection of the brand. To create emphasis, blue is used as a break from this color scheme. Typography uses Roboto across a semantic scale (h1–h6 → Label → Value → Statistic) with four responsive breakpoints tied by ems. All 260+ icons ship at both 20px and 24px to support data-dense table contexts alongside standard UI placement.
Components in Scale
The library covers Actions, Communications, Selection, Containment, Navigation, and Inputs. These are each documented with full state coverage. Many of these components were designed to do away with the gigantic clunky tables used to adjust settings in the previous app, instead making data more visual, understandable and scannable. This reduces cognitive load significantly without sacrificing the precision appraisers need.
Handoff Without Meetings
Specs were prepared throughout the project to communicate component behavior to the front-end team asynchronously, reducing back-and-forth and keeping implementation moving between collaborative sessions. Exact CSS values, measurement constraints, state variations, and edge cases were documented directly on the design.
Impact
The result was a system that scaled across a year of production without accumulating design debt, and that a non-technical stakeholder could navigate without design team support.
A Product Owner and development team actively involved in a year-long build could independently navigate wireframes without design team support
Consistent naming convention (Type · Attribute · Size · State) made components developer-ready without a separate spec document
A dual-file structure kept the client reference stable throughout rapid, iterative production
Nova was delivered as a v0 product. Over the course of the engagement, a product owner with deep industry expertise and initial skepticism about design's strategic role became an advocate for involving design from discovery. The product direction shifted as a result. That change in perspective was as much a deliverable as the product itself