Case study
JWMaps: Turning a Drawn Boundary into a Usable Field Document
Role
Solo product designer & full‑stack developer
Tools
Node.js, Express, Leaflet, ArcGIS REST (Texas StratMap Address Points, FEMA/ORNL USA Structures)
Status
Live in production
JWMaps solves a problem most mapping tools ignore: finding addresses inside an area is easy, but turning that result into something a person can actually use on foot is the hard part. JWMaps lets someone draw a boundary directly on a map and instantly pulls every matching address inside it — tested at 2,000+ addresses in a single query — then turns that raw result into a printable, street‑grouped field report instead of leaving it as a pile of pins on a screen.
The interesting design problems here weren’t really about maps. They were about accuracy and structure: which data source to trust, and how to take an unordered list of address points and turn it into a document a person could hold, scan, and check off in the field.
Key design decisions
01
From map to field document
A list of 2,000 address pins on a screen isn’t usable in the field — nobody can scroll a map while walking a route. The print feature reframes the same data as a landscape report: addresses grouped by street and sorted numerically, paired with a live map view of the boundary, markers, and house numbers, plus an optional custom headline for context (a route name, a date, a team assignment). This is an information design problem before it’s a printing feature — deciding what a raw dataset needs to become before a human can act on it.
02
Choosing accuracy over convenience
Address and building‑footprint data come from Texas StratMap and FEMA/ORNL’s USA Structures — not OpenStreetMap, despite that being the more common default. That choice came from testing: OSM has real, known coverage gaps in the Brownsville area, so a “good enough” community‑sourced dataset would have quietly produced incomplete results. It’s the same judgment call as sourcing and fact‑checking in written content — preferring the authoritative source over the convenient one, even when the convenient one would have been faster to wire up.
03
Interface language that stays out of the way
Every control is named for what it does, not what it’s called technically: “Show house numbers,” “Show building outlines,” a plain Street/Satellite toggle. The boundary polygon itself is styled with a near‑invisible fill (5% opacity) so it never competes with the data plotted inside it — an interface should disappear into the task, and that applies as much to a map’s visual weight as it does to a button’s label.
04
Access as a default, not an add-on
Like Journal, JWMaps sits behind a single bcrypt‑hashed password and server‑side session — no public entry point. It’s the same underlying philosophy across both projects: build for a known, trusted user first, and treat access control as a starting assumption rather than something bolted on later.
What I’d highlight for a hiring manager or client
Judgment outside of writing. Choosing StratMap and USA Structures over OSM, or deciding how a printed report should group and sort data, are the same kind of decisions a content designer makes when structuring information for someone to act on — they just happen to be about map data instead of paragraphs.
Designing for the moment of use. The print report exists because the on‑screen map isn’t the artifact someone actually needs in the field — recognizing that gap and designing for the real end context, not just the interface in front of me.
Full ownership, technical and otherwise. Backend, data sourcing, interaction design, and every label in the interface were mine to decide and build.
Tech stack