It's on This Page. Somewhere.
How I redesigned schema-driven detail pages to communicate meaning, not just render data.
Client
Locus
Product
Detail Page Framework
Year
2026
Timeline
3 weeks
Role
Senior Product Designer
Team
1 Product Manager 4 Engineers (FE+BE)
Outcome
Shipped to production across 14 entity types
0 custom page exceptions. Piloted with 5 clients. 4.5x faster task completion. Zero custom page exceptions.
At Locus, we are re-architecting our platform to scale across customers, geographies, and operational complexity. That means moving away from handcrafted screens and toward schema-driven UI, where every page renders from structured data in the form of JSON, instead of custom frontend logic.
Each entity is defined as a backend JSON schema.
A generic frontend renderer turns them all into detail pages.
Detail pages are the highest-traffic screens in the platform. Order details alone sees 2.57M views over 180 days. Tour and Quote details add another 0.51M. Across just three entities, that's nearly 3M views every six months.
Detail pages are also decision surfaces.
Operations teams use them to assess delays, trace routes, and identify downstream impact, all under time pressure. In some teams, a coordinator checks a detail page 40-50 times a day. Every extra second spent parsing compounds across hundreds of decisions. A wrong call means a missed SLA, a fleet re-routed mid-day, or a client escalation that puts the contract at risk.
Architecturally, schema-driven UI is the right decision. It is how you build an enterprise platform that lasts.
But detail pages exposed the limitations first. V1 prioritized data completeness. Every field was on the page. None of them communicated anything.
"Is this shipment late?"
Simple question.
The answer was on the screen, buried across two fields. To answer it, users had to find the planned pickup time, find the actual pickup time, and mentally calculate the difference themselves.
V1: Every section rendered identically.
Routes, contacts, timestamps, all flattened into the same label-value grid.
I also noticed a pattern.
Users were pressing Ctrl+F on pages they had seen hundreds of times. Not because the data was missing, but because scanning a flat wall of label-value pairs was the only way to even begin answering basic questions.
Ctrl+F on a page you've seen hundreds of times.
That's a design failure, not a user one.
These were Technical Account Managers reviewing V1 of our new schema-driven detail pages. People who know Locus inside out and use these screens daily.
Their feedback was consistent:
"All the detail pages look the same."
"I can't tell what I'm looking at."
"It is very difficult to find what I am looking for."
A shipment and a driver profile.
Two different entities, one identical page.
Because the schema only knew how to list fields, it rendered all entities identically.
This was not a usability issue. It was a semantic one.
The schema was a data contract. It described what fields exist. It had no way to describe what those fields mean.
And if the detail page framework couldn't solve this within schema constraints, the alternative was building custom pages per entity, which would break the principle the entire platform was being re-architected around.
Why visual fixes failed
The first instinct was to fix layout.
Each approach improved one entity's page but couldn't generalize. Indentation worked for shipments, where origin-to-destination creates a natural hierarchy. Applied to a Hub entity with flat, peer-level attributes, the same indentation implied parent-child relationships that didn't exist. What works for a shipment (journey visualization) is meaningless for a Team entity.
And the schema had no way to know which entity needed which treatment. Every visual fix was fighting the same root cause: the schema could describe what fields to show, but not what those fields mean.
Exploration 1
Early explorations that addressed layout but not meaning.
Exploration 2
Caption 2.2
Exploration 3
Caption 2.3
Exploration 4
Caption 2.4
Every visual fix was fighting the same root cause: the schema could describe what fields to show, but not what those fields mean.
The problem was not how things looked, it was what the system could say.
The constraints and the gap
I took ownership of V2 of the detail page framework as a cross-functional product and design effort under three non-negotiable constraints.
Schema-first UI:
All UI must render from backend schemas. No custom frontend logic per entity.
Multi-entity scale:
The same framework must support 20+ entity types without fragmentation.
No escape hatches:
No one-off pages. No entity-specific exceptions. No fallback to custom designs.
If the framework can't express it, evolve the framework.
Within those constraints, the schema already had hierarchy: headings, subsections, field groups. What it lacked was vocabulary.
It could say:
"Render these 12 fields under this heading."
It could not say:
"These fields together describe a journey", or
"This information represents a person."
The schema had hierarchy. It did not have vocabulary.
Without that vocabulary, every attempt to improve clarity was cosmetic.
The new framework
From data contract to communication contract
The breakthrough came when I stopped asking:
"How do we render these fields?" and started asking:
"What should this page communicate at a glance?"
We designed the ideal shipment detail page without constraints. Then worked backward: what would the schema need to express to make this possible, without custom UI?
The answer was a new semantic layer in the schema contract. This required convincing backend teams that schemas are not just data contracts but communication contracts.
The resistance was real: adding semantic properties meant changing a contract that orders, shipments, tours, and all other entities depended on. If we broke it, we'd delay everything. We introduced semantic primitives incrementally, proving each addition was backward-compatible before proposing the next.
Slots
Slots are containers within a heading level.
They allow related fields to be grouped intentionally.
For example:
• Movement details (origin, stops, destination) in one slot.
• Measurement details (weight, volume) in another.
• Notes and attachments (images, documents) in a separate slot.
Detail types
Detail types define what the data represents.
They give a group of fields meaning, so the system can present it accordingly.
For example:
• Movement renders a journey as a visual path with origin, stops, and destination.
• Location + Map renders coordinates alongside spatial context.
• Contact renders a person/company as a card with name, phone, and address.
Slots define grouping. Detail types define semantics.
By separating the two, I avoided a common failure mode in schema-driven systems: encoding layout decisions as meaning.
Together, they allow the schema to say:
"This is a journey. Show it like one."
Before, it could only say:
"Here are four fields."
Detail types on the left. Slot-based layout on the right.
Any block plugs into any slot.
Enriched label-value pairs
I applied the same principle at the atomic level. I redesigned the label-value pair itself to carry meaning. Optional tags, icons, and supporting text turned individual data points into self-explanatory units.
Meaning at the atomic level. Label and value are required.
Everything else is a semantic enrichment.
Before: two fields, no logic. After: one answer.
Before and after
Same data. Different comprehension speed.
We ran a task-based comparison with 6 TAMs using the same three tasks on V1 and V2: find whether a shipment is late, locate the pickup agent's contact, and trace the route from origin to destination.
4.5x faster
Average time to answer "Is this shipment late?" dropped from 18s to 4s.
0 Ctrl+F
Zero participants searched on V2. Two out of six did on V1.
1st fold
Route tracing visible without scrolling. Down from 3 scrolls on V1.
Scaling across entities
Using this framework, we designed detail pages for 14 entity types. Three anchor entities (shipments, orders, and tours) were designed at full depth to validate real-world complexity. The rest were validated structurally to ensure the framework handled diverse data models without breaking or requiring exceptions.
Most entities became visually distinct, not through custom UI, but through semantic expression. Some, like Team detail pages, had no related data that warranted meaningful grouping. For those, the framework falls back to default label-value presentation.
The goal was not to force richness everywhere. It was to enable meaning where it exists.
14 entity types. One framework. No custom pages.
Internal validation
5 PMs reviewed the framework across their entities. Zero custom page requests. Zero exceptions. PMs had full authority to request them. None did. The only feedback was missing backend fields, not framework limitations.
TAMs confirmed the shift. One looked at the shipment detail page and said: "Oh, this finally looks like an order."
External validation
Rolled out to 5 clients: 3 existing, 2 new.
Existing clients noticed the difference unprompted. One operations lead who had previously escalated about shipment pages:
"I can find what I need faster. These pages make so much more sense now."
New clients onboarded faster than expected. One team lead:
"Team is taking less time to get onboarded on Locus's system."
Faster onboarding had been an org-level goal for a long time. It wasn't the goal of this project. But when pages communicate what things are, new users don't have to learn where everything hides.
Governance
Semantic systems are harder to govern than visual ones. Engineering flagged early that teams might misuse slots as layout hacks. I addressed this: new detail types require joint design-engineering review, must demonstrate cross-entity reuse, and cannot duplicate existing capabilities.
For example, one team requested a custom card layout for a specific entity. I rejected it because the existing Contact detail type already handled the pattern. Three of the first four requests were rejected on similar grounds.
What I'd do differently
Instrument V2 usage. We validated with task-based testing but didn't instrument the live product. Heatmaps, time-on-task tracking, and Ctrl+F frequency in production would have turned a strong qualitative signal into hard behavioral data.
Test with end-users, not just TAMs. TAMs are power users who know the system deeply. Dispatchers and logistics coordinators, the people making 40-50 decisions a day on these pages, would have tested the framework under real cognitive load. Their feedback might have surfaced different problems.
What this changed
This wasn't just a redesign. It was giving a schema-driven system the vocabulary to express meaning, so that as Locus scales to new entities, new geographies, and new operational complexity, the product doesn't just remain configurable. It remains understandable.
The unexpected lesson: the same semantic clarity that helped experienced users find information faster also helped new users learn the system faster. We optimized for recognition and accidentally unlocked learnability.