The product

Revalo lets you explore and analyze land parcels across the United States. You open a map, tap a parcel, and get the record behind it: who owns it, what it last sold for, what it's assessed at, what the taxes are, where the flood risk sits, what's being built nearby.

The complexity is real. Eight togglable data layers, from parcel boundaries and contours to electric transmission lines and floodplains. Four base maps. A parcel record spanning ownership trusts and mailing addresses, transaction history with dates and deltas, assessed valuation, land market value, improvement value, price per square foot and tax area codes.

The people using it make decisions about property with money attached, so the job was to make the data legible enough to act on.

Discover mode

Parcel record

Financial view

How I ended up owning it

I joined through Zaelot to assist Marcela Abal, the designer leading the product. For the first six months we defined the work together, and for a stretch I designed the website while she designed the app. The client asked to keep me on. When Marcela moved to another product, I stayed with this one, and for the last 18 of 24 months I was its only designer, with ten people building from the designs.

The problem

Capabilities had arrived one at a time and been designed one at a time. The result was fragmented navigation, inconsistent interfaces, and no mental model a user could carry from one part of the app to another. In the design files that looked like the same feature explored in two places, five competing proposals for map interaction, and a parcel record that had collected fields faster than anyone had organized them.

01The map is the ground

The organizing decision. Instead of treating the map as one destination among several, it became the persistent ground the product sits on. Search, the layer panel and the parcel record are sheets drawn over a map that never goes away, so context is never lost and no transition costs a person their place.

Sheets over the map

• Searchregion-scoped
• Layersbase + data
• Parcel record4 views
• Notespins

Persistent ground

Mapalways present · keeps position, zoom and active layers

Modes and nav

• Saves
• Discover
• Feedback

02Sixty fields, four questions

The parcel record was the center of gravity and the most rewritten screen in the project. Roughly a quarter of all the design work sat on it, and I rewrote it fifteen times. Presenting everything the county knows as one list made all of it equally unimportant.

The restructure grouped fields by the question being asked rather than by where the data came from. Four views, each answering one thing, with the header carrying identity and the two actions people actually wanted: directions to the parcel, and the assessor's own record.

03Three kinds of layer, three rules

Layers had been one undifferentiated list, which hid the fact that different layers behave differently. Base maps are mutually exclusive, you get one. Data layers are additive and independent. Interaction layers resolve against whatever is currently drawn.

Naming the three tiers made the panel designable. It also showed which layers need explaining, because Public Lands or Floodplains mean something specific and legally loaded that a user should be able to check.

• Base mapPick one
  • Default
  • Light
  • Dark
  • Satellite
• Data layersStack freely
  • Parcel Boundaries
  • City Boundaries ⓘ
  • School Districts
  • County Boundaries
  • Public Lands ⓘ
  • Floodplains ⓘ
  • Transmission Lines
  • Contours
• InteractionResolves against what's drawn
  • Crosshair
  • Long press
  • Measure
  • Multiple selection
  • 3D

04Two intents, one input

Search was carrying two unrelated jobs. Someone typing an address, an APN or an owner name already knows what they want and needs to be taken there. Someone scanning a region wants to be shown what is there, and no query expresses that.

Splitting them let each become good at one thing. Search gained region scoping and input detection, so the field recognizes what kind of identifier it has been given. Discover became its own mode: filtered pins, development cards with status and acreage, and 3D.

Before

One search field

• Lookup and exploration at once
• No way to say "show me what's here"
• Ambiguous across identifier types

→

Targeted

Search

• Address · APN · owner name
• Region-scoped by default
• Detects the input type

Exploratory

Discover

• Developments and place names
• Cards with status, type, acreage
• Points of interest, 3D

05Designing toward what Mapbox does natively

In Discover I had first designed points on the map that rendered as images. The product runs on Mapbox, and the honest answer there was pins. I learned enough Mapbox to know how far it could be customized, and redesigned toward what the platform does natively.

06One library instead of two loose files

When I took over there was an in-progress file and a ready-for-dev file, both loosely componentized. I unified them into one linked component library plus a workspace where a screen was sealed once it was ready. Color, spacing and radius became tokens that components bind to, and by handoff 989 components were bound to those variables. For the team that meant specs nobody had to interpret, and the same decisions on every screen.

The clearest piece of that work: 243 icons had accumulated under six naming conventions, including Material export filenames and about thirty auto-generated names that meant nothing. Finding an icon meant remembering where it came from.

Six conventions

• baseline_edit_black_24dp
• owner_names_map
• mdi:map-marker-alt
• ic:round-search
• Bookmark Outline
• Property 1=Icons

→

One schema

Category = actionIcon = edit243 icons · 23 categories

07Making handoff survive time

The pipeline existed to guarantee that what a developer built was the state that had actually been reviewed, and that anyone returning to a ticket months later would land on the same thing.

1. One ticket, one sectionWork happens as a Figma section inside the feature's page, in a work-in-progress zone.
2. Promotion is gatedThe feature page moves to handoff only when every section carries a ready-for-dev status.
3. Refinement is versionedAfter each refinement meeting, a named, dated file version is saved with the tickets it covers.
4. The version returns to the ticketThat link goes back into the ticket, so future work opens exactly the state that was agreed.

What shipped

The app shipped on iOS in June 2026 and is live at revalo.io, with two subscription tiers gated through RevenueCat: restricted layers, gated parcel information and 3D mode, a cap on saved parcels, and owner search behind the paywall.

It was late. The paid launch was planned for August 2025 and moved three times, while the product kept adding surface: notes, Discover mode, new map layers, and a story mode that generates a narrative from parcel data. The structure absorbed all of it. New work landed in one of its slots instead of becoming another destination.

What I would do differently

We never tested any of it. No interviews, no usability sessions, no metrics, no iteration loop. Every structural decision here, including the ones I still believe in, rests on reasoning rather than evidence.

The product also kept adding features instead of finishing the ones it had. Parcel detail, the screen that mattered most, never got the usability pass it needed.

I would sequence it differently: about three months of design, six months building what was designed, and then testing it in the market. And I would spend the first month talking to users instead of organizing screens.

Credits

• Design: Marcela Abal, then Marcela and me, then me
• Product owners: Anthony, then Ethan and Nate
• Product managers: Mateo López, then Gustavo D'Andrea
• Development: Manuel Acuña, Aquiles Mariani, Jorge Zammit
• QA: Natalia Antinori, Jorge Perozo, Vladimir Ostapoff
• Delivery lead: Emmanuel Calle · Data architect: Bruno Cerecetto

Two products, one condition

EWTN is a global Catholic media network: television, radio, publishing and a large content website. Two products were in flight when I joined, a native iOS app being designed from scratch and EWTN.com being rebuilt. The design lead was designing the whole ecosystem, with a PM, a media lead and a UI designer building screens and components.

Different teams, different files, the same condition. The files recorded what had been drawn, and nothing connected the screens to a shared set of decisions, so each new screen re-decided the same things slightly differently. I came in part time to work on that layer.

01The recommendations I later had to implement

The engagement began as an assessment of handoff quality. The file had no clear structure for handoff, no consistent component system, ambiguous versioning, and no way to tell which screens were final. The recommendations were short and enforceable: split the system from production, four zones per file, only ready-for-dev screens are buildable, every reusable element is a component, a dated version after each refinement meeting, auto-layout with at least one more breakpoint.

The assessment also stated its own limits in writing. That clause matters because of what happened next.

Assessment scope · April

Explicitly excluded

• Design system creation or implementation
• File restructuring or cleanup
• Component creation or refactoring
• Ongoing support or validation

→

Delivered · April to July

All four of them

• A token system across five dimensions, applied file-wide
• File restructured into components, modules, widgets, templates and handoff zones
• 214 component sets built, relinked and renamed
• Three months of continuous implementation

02A language before screens

The app needed a vocabulary before it needed more views, so the first deliverable was a design language. Twelve core color tokens with a single vermilion accent doing all the brand, live and primary-action work, and two full surface stacks, because dark mode here is a desaturated navy that keeps long scripture legible, not an inversion. Three type families with a job each, one line icon set on a 24 grid, six corner steps, eight spacing steps, six elevation levels, fourteen components at five states each.

“If a value is not in this section, it shouldn't appear in production.”

03Inventory-rich, system-poor

The website's library was a different problem. Almost every screen had been drawn, and some atoms were reused thousands of times: the poster card alone appeared 2,184 times. What was missing was the connective tissue: tokens, naming, consolidated variants, one source of truth.

Type

70font styles across at least eight families

Color

6+competing brand reds, typed as raw RGB

Naming

7copies of one button, Button to Button7

Tokens

0.3%of nodes bound to a variable, 696 of 213,625

I added a section on automation readiness, because the team was considering pointing codegen tools at the file. Those tools transcribe structure and amplify whatever is in it: a variant property still called Property1 becomes a prop called Property1. The useful consequence is that there is no separate AI backlog. The hygiene that makes a library good for people is the same work that makes it usable by machines.

04The layouts weren't linked to the system

The handoff layouts looked like they used the design system. The layers were named Button, Card, Row, Footer, exactly like the components. They were local duplicates with no relationship to them, and some pages pulled from two other libraries entirely. Changing the system changed nothing on the pages that were supposed to consume it.

So I built real component sets, one per widget with breakpoints as variants, and relinked 762 instances across 19 component types. Before any type was swapped in bulk, one instance was swapped, measured against its visible text and dimensions, and reverted. All nineteen passed and the swap ran with zero errors, but the gate caught a variant mapping I had reversed, which would have silently crossed two states on every instance of that card. 200 instances were left pointing at the remote library on purpose: icons with no local twin.

Sets

214component sets, 1,444 components

Relinked

762instances, 0 errors

Renamed

2,005default-named layers

Left alone

200icons with no local twin

Where I got it wrong: the Litany of St. Joseph

The devotional pages needed local components that didn't exist, so I built them from scratch, matching the originals as closely as I could read them, and relinked the pages to my versions.

It degraded the pages. The original Litany of St. Joseph component was 3,760px tall: forty-odd invocations, a byline and a closing prayer. Mine was 836px of about sixteen generic rows. Relinking replaced real liturgical content with my approximation of it, quietly, because the swap reported success.

I reverted those three pages and rebuilt them by deriving from the originals: instance the external master, detach it to get an exact copy with its nested instances, then turn that into a component. Exact by construction instead of by effort. When an operation reports success, check the content, not the operation.

05Tokens, and what I left alone

With components in place, I bound color, typography, spacing, radius and effects across the file, roughly 22,000 bindings. Each pass was checked on a sample of representative surfaces before it ran at scale. Part of the deliverable was naming what I didn't touch: about 5,300 paints carrying transparency stayed raw, because they are scrims and overlays the opaque ramp would have flattened. Italics and oversize display type stayed raw because the system has no styles for them. About 62 multi-effect stacks were skipped rather than overwritten.

Effects needed a reclassification before they needed styles.

As authored

792 nodes with a drop shadow. One category, by the file's own account.

→

• ~490 true elevationtranslucent and blurred, a surface lifting off the one beneath it
• ~300 faux borderszero offset, zero blur, opaque spread: a stroke drawn with the shadow tool
• 180 background blursfrosted-glass surfaces at seven radii
• 7 one-offsinner shadows, layer blurs, noise fills

06Handoff

The remaining templates were going to be built by EWTN's in-house team, so the last phase was aimed at them: a playbook inside the design system file, with five rules, the naming conventions, and step-by-step guides for building a widget and a page. It teaches the manual Figma workflow, not the scripted one I had used, because the people maintaining it needed a procedure they could follow by hand.

07I re-measured the file, and coverage had fallen

To write this I re-ran the coverage audit across the library's component pages, 16,674 authored nodes. It was not the number I expected.

Typography94.4%

Color85.1%

Spacing73.9%, was ~99%

Radius73.7%, was 94%

Effect styles68.0%

The likely cause is growth. A dozen component pages I never touched, plus a whole Modules layer, were added after the token passes ran. I measured the aggregate, not old pages against new, so growth is the probable cause, not a proven one. The direction is the finding either way.

The benchmark

Three years ago at Zaelot, the same kind of widget and componentization work on Chime Central took two designers working full time for seven months. It was the project that took me from intern to junior. On EWTN I did comparable work part time, with an AI-assisted, scripted workflow, in a team that wasn't using AI.

What I would do differently

The gains don't hold themselves. Twenty-two thousand bindings felt like the achievement. What holds coverage is enforcement: a checklist that gates publishing, a lint pass someone runs, an owner who says no. My own audit recommended exactly that. I delivered a playbook instead, and a playbook is documentation, not a gate. The chart above is what that looks like a few weeks later.

"Dev-ready" is still my opinion of the file. No developer has built from it yet. I criticized the original file for handoff claims that handoff hadn't tested, and finished with one of my own.

The April clause was right. The assessment left implementation to the team because that is where a team's practice forms. I did the implementation instead. It produced a much better file and left the practice roughly where it was. Next time I would trade a third of the migration for pairing sessions with the people who maintain it.

Context

Manuel Dubra and I wrote this as our degree thesis at the Universidad de la República, in the first semester of 2025. The question: how should lighting work in a home where one room has to hold every activity of the day?

A previous thesis had found that about 70% of daily activity happens in the bedroom and the living room. We narrowed it further, to homes where all of it happens in one room. Studios and one bedroom units were 75% of apartment demand in Montevideo in 2024, and since the pandemic that room is also the office.

What we did

• Theory on visual ergonomics, Norman's emotional design and levels of experience, ERCO's lighting handbooks, and research on artificial light at night.
• Two interviews with young people living in compact apartments in Montevideo, one studying and one working, both in south-facing units with no direct sun.
• One interview with an electrical engineer with a master's in architectural lighting design who directs a lighting studio.
• A benchmark of seven products, from Philips Hue and Nanoleaf to IKEA's hubs and a CoeLux skylight simulator, scored on the same criteria.

What people told us

The interviews were small, but the pains were specific and they repeated:

• Reading in bed, then getting up to switch the light off, because the only switch is by the door.
• Cooking in your own shadow, so the range hood light becomes the kitchen light.
• Video calls under a ceiling light that puts shadows on your face.
• Turning on every light in the room to see one corner of it.

Both described the white ceiling light as cold, closer to a hospital than a home. Nobody asked for an app. They asked for light per zone, a dimmer, warm light, and quieter gestures.

“Close the book and the light goes off by itself.”

The expert reached the same place from the other side: forget a lux target, design dimmable zones and combine them into scenes. He also warned that home automation only earns its place when it removes effort.

What the market offers

The seven smart lighting products we benchmarked scored highest on tech compatibility and aesthetics, and lowest on improving the light a home already has. So the requirements put usability, zoning, visual ergonomics and comfort first, and apps, sensors and automation last.

The system concept

A user-centered, layered lighting system for compact homes: several light points that combine into scenes, one per activity. It lets the person living there shape the light around what they are doing, without moving furniture or buying a lamp for every problem.

Indispensable

• Usability: scenes and lights operable without friction.
• Zoning: enough light points, placed per zone and function.
• Visual ergonomics: the right level and type of light per activity, without glare or fatigue.
• Comfort: warmth and balanced contrast, a space that still feels like a home.

Desirable

• Predefined scenes, so nobody rebuilds a setup every time.
• Modularity, so a basic version can grow.
• Feedback that tells you which scene or layer is on.
• Integration into furniture and walls, so the system takes no floor space.

Optional

• Fixture quality, form and material.
• Central control from a phone or a voice assistant.
• Sensors for presence, daylight or time of day.
• Tunable color, temperature and intensity.

Where it stopped

We started out wanting a tech product and ended up studying light itself: its physics, how it bounces, how it is perceived. The thesis closes in the middle of the double diamond, with four directions for a next stage: control interfaces, a lighting product system, architectural integration, and guides for residents.

Why it is here

Most of my work is interface design. This project is where I learned to start from the activity instead of the object. Several of its requirements, like knowing which scene is on or switching without friction, are interaction problems before they are lighting ones.

Credits

Ignacio Arrospide and Manuel Dubra. Licenciatura en Diseño Industrial, Perfil Producto. Escuela Universitaria Centro de Diseño, FADU, Universidad de la República. Montevideo, 2025.