Node( )
Every disaster plan assumes you can still reach someone. A mesh radio you can carry, and an app that runs on it, for the hours after that assumption stops being true.
It took two attempts. The first — Ezra — had five features and a directory of phone numbers to call for help, which is a reasonable product for a world where the phones work. This page spends as long on that mistake as on the thing that replaced it, because the pivot is the only part of twenty weeks that was actually hard.
- Role
- Product lead → product designer
- Team
- The Naturalists — five
- Span
- 20 weeks · Fall 2021 – Winter 2022
- Course
- SCAD UXDG 450 + 490
The infrastructure people plan around is the infrastructure that fails first.
Power goes, then cell service goes, and every arrangement anyone made in advance — the group chat, the meeting point, the number for the shelter — goes with it. Our interviews kept returning the same shape of story: not that help was unavailable, but that people could not find out where it was, and could not tell anyone where they were.
“Most search and rescue after a disaster is done by people in their communities.”
That line moved the target audience. Nine expert interviews said the same thing in different words: local volunteers and neighbours are the real first responders, and formal relief takes days to arrive. So the system to design for is not the one that connects a citizen to an agency. It is the one that connects a citizen to the person four streets away.
- 111
- Survey respondents
The wide pass — who has been through one, and what they did when it started.
Context onlyEstablished the window: the problem is not the event, it is the days after it, when the phone is dead and nothing is decided.
- 20
- User interviews
People who had lived through a hurricane, a wildfire or an ice storm.
Load-bearingThe same story shape, repeatedly: not that help was unavailable, but that people could not find out where it was or say where they were.
- 9
- Expert interviews
Emergency managers, relief coordinators and volunteer responders.
Load-bearingMoved the target audience. Local volunteers are the real first responders and formal relief takes days — so the system to build connects neighbours, not citizens to agencies.
- 8
- Sensory-cue studies
What people actually reach for in the first hour, before anything is decided.
Context onlyFed the industrial design — the twist gesture that works with cold hands, in the dark, without looking. It did not influence the app, and I would not claim it did.
Two of those four changed what got built. The other two are marked as context because that is what they were — a survey of 111 people is the kind of number that looks decisive on a slide and, in this project, mostly confirmed the framing we already had. Marking them honestly costs nothing; the nine expert interviews are the ones that moved the target, and they are the smallest number on the row.
HF radio wins the analysis outright — it scores top marks on accuracy, real-time delivery and reliability, and it keeps working when everything else stops. It also scores 1 out of 5 on cost and 2 on accessibility.
So the gap was never a technology gap. Radio already solved the hard part decades ago. The gap is that the thing which works is expensive, ugly and requires a licence and a hobby — and the things ordinary people own stop working exactly when they are needed.
The first answer was a good app for the wrong ten minutes.
Ezra was a companion radio device and a five-tab app: news, a community-vetted resource map, shared preparation checklists, a directory of radio frequencies, and a profile holding your medical details. I was product lead for it. It presented well, it won the room, and it was built on an assumption nobody had said out loud.
Five tabs, one of which was a list of phone numbers to call for help. The whole project exists because the phones are down.
That contradiction sat inside a well-made deck for ten weeks without anyone catching it, including me. It took putting the screens in front of people who had actually lost service.
The process book records the conclusion in one sentence: Ezra had too many features, so we cut the excess and focused on the ones most significant in natural disaster communication. What that sentence compresses is that participants could describe what almost every tab did, and could not say which one they would open first — and in an emergency the tab you open first is the only one that exists.
Five features became three, and the interesting part is where the other two went.
A before-and-after screenshot can show you that a tab disappeared. It cannot tell you whether the job disappeared with it. Two of these were deletions and two were relocations, and confusing the two is how products get quietly worse while looking simpler.
- News→FeedRenamed
Filtered alerts and weather updates for your location.
Survived unchanged in substance. Renamed because “News” describes a source and “Feed” describes a behaviour, and the thing people actually did with it was scroll.
- GuideKept
A community-vetted map of which shops still have what.
The one feature nobody in testing wanted changed. It is also the only one that gets *better* as the disaster gets worse, because stock information decays in hours.
- Plan→Cut
Shared preparation checklists — home, safety, resources, evacuation.
The feature people praised in interviews and never opened in testing. Preparation is a calm-weather behaviour, and Node is opened in an emergency — a tab that is only useful before the event is a tab that is empty during it.
- Radio→ConnectAbsorbed
Frequencies and phone numbers for local disaster organisations.
A directory of numbers assumes the phone network is up, which is the assumption the whole project exists to remove. The job — reach an organisation — moved onto the mesh instead of onto a list.
- ProfileKept
Medical details, emergency contacts, saved routes.
Kept, and demoted. It stopped being a feature and became the thing that makes the other three work — the reason a Node Helper can say what they can help with.
One deletion
Plan. Preparation is a calm-weather behaviour and Node is opened in an emergency.
One relocation
Radio's job — reach an organisation — moved onto the mesh instead of onto a list of numbers.
One demotion
Profile stopped being a feature and became the data that makes the other three true.
Cutting Radio is the decision the rest of the project hangs off. Once you accept that a directory of numbers is useless without a network, the only honest options are to give up on communication or to bring your own network. Node is what the second option looks like.
A mesh has at least two ways to reach every node. So break one.
That definition is the product's entire warrant, and it is the kind of claim a case study normally asks you to take on faith. It does not have to be. Below is the topology, drawn to the ranges the devices publish — 0.6 miles between nodes, 2 miles from a beacon — with every link computed from geometry rather than drawn by hand.
Take the tower down. Then start removing people. The route recomputes each time, and the badge above it is calculated the same way the claim is worded: remove each hop in turn and see whether anything survives. When one of them cannot be removed, the network stops being a mesh — and the readout says whose device everything is passing through.
Two hops, because the tower reaches everyone. This is how it works on a normal day — and it is also a network in which exactly one object matters. Take it away.
- You
- →Cell tower
- →Relief centre
Then click any node or beacon on the map to knock it out. The route re-computes on every change.
Beacons are the cheat code
An organisation's beacon reaches 3× further than a personal node, which is what a public building buys you. Knock both of them out and the mesh still works — it just gets long.
Density is the product
One Node is a paperweight. The value curve is entirely about how many neighbours own one, which is also why the pricing sells three at a discount rather than one.
Failure is allowed to be visible
When the graph partitions, the map says so rather than showing a spinner. A device that cannot reach anyone should say that clearly and early enough to change what you do.
One you carry. One a building owns.
The personal Node is a two-part block that separates: twist it and it fires an SOS to your emergency contacts, and it works as a standalone voice radio with no phone involved. The Beacon is the version an organisation bolts to a school or a clinic — more antenna, more range, mains power.
- 0.3–0.6
- miles · node reach
To a phone, or to the next node.
- 1–2
- miles · beacon reach
Roughly 3× a node. This is what a public building contributes.
- $47
- node · bill of materials
Wi-Fi, radio, antenna, battery, amp, speaker, mic, assembly.
- $74
- beacon · bill of materials
Same list, bigger battery and radio.
The first form was a cylinder with an exposed antenna, and it tested badly for reasons no render would have surfaced: it rolled out of people's hands, and it would not sit in a pocket. Testers liked the twist gesture and disliked everything holding it.
So the production form is rectangular with a rounded corner profile, and the antenna retracts into the body. The twist survived — it is the one interaction that works with cold hands, in the dark, without looking.
I built the part that could be built.
A concept device is easy to draw and easy to disbelieve. The claim worth testing was the narrow one: can a battery-powered board host its own network, serve an interface to whatever phone is nearby, and pass messages between two people with no infrastructure in between?
An ESP32 with a mini power bank, an ESP8266 and a NeoPixel ring. The board runs a web server and its own access point; you join it from a phone browser, type a name, and you are in a conversation. No app install, no account, no signal — which also answers the adoption question the product design could not, because the thing already in everyone's pocket becomes the screen.
A page served off the board at 10.146.102.1. Two devices, one conversation, nothing else in the room. It is a long way from a self-healing mesh — it is a single access point, and the routing in section 04 is modelled rather than implemented.
Saying so matters more than the demo does. What it proves is the interface premise: you do not need to have installed anything before the disaster for the device to be useful during it.
Four tabs and the real transitions. Connect is the one to spend time in — it is where the cut in section 03 ended up.
- Connect is a map, not an inbox
- The default view is who is nearby and what they said they can help with — not a list of threads. In an emergency the useful question is “who”, and only then “what did they say”.
- Helper and Seeker are declared, not inferred
- You pick your own tags — food, first-aid, water, pick-up. An algorithm guessing who needs help is a system that can be wrong about the most consequential thing on the map.
- Four tabs, and one of them is dormant
- Profile does nothing on its own. It exists so the other three can say something true about you when you are not typing.
What I would argue with now.
- 01
The pivot took ten weeks longer than the evidence did
The expert interviews said local volunteers are the first responders in week three. Ezra kept a phone-number directory until week twelve. The research was not wrong and it was not missing — it just was not allowed to overrule a feature set we had already presented.
- 02
The projection at the back of the deck is not a finding
A four-year curve reaching 100,000 people protected sits in the business section. Nobody measured that; we drew it. It is the one artefact in twenty weeks I would remove rather than caveat.
- 03
The mesh was modelled, never built
The prototype is a single access point serving a chat page. Everything in section 04 about self-healing routing is a simulation of a claim, and the honest version of this project's next phase is two boards actually relaying for a third.
- 04
$2 per megabyte is a strange thing to sell a disaster victim
The pricing model bills by data on a device whose entire premise is that you are having the worst day of your life. It made the business case work. I do not think it survives contact with a real user.
Five people over twenty weeks. Naming everyone is the only honest way to present team work, and it costs nothing to be specific about which parts were mine.
- Isabella RiveraProject lead
- Mikayla KimUX research · UI
- Sathvik KothaProduct design · prototype
- Jiyoung LeeVisual design
- Tang TantivirunUX engineering
- Product lead through the Ezra phase — the feature set, the interaction model, and the sitemap that turned out to be the problem
- Product design through the Node phase — device behaviour, the Connect model, and the Helper/Seeker distinction
- Built the working prototype: ESP32 firmware and an on-device web server any phone could join over Wi-Fi and chat through
The two bands on this page borrow their colours from the source documents rather than choosing them — Ezra's cream and clay off the Fall deck, Node's off the brand sheet the team published in the process book. Two of the published values cannot be used the way the sheet implies, and the audit prints the deviations at the bottom of every run rather than letting them become folklore.
| Token | Change | Why |
|---|---|---|
| blue → blueText | #0072C4 → #5AB4F2 | the brand blue scores 3.55 on #101828 — fine for a 2px edge or a 40px numeral, short for a 13px label |
| deep | field only | #080660 scores 1.02 against the void it sits on — very nearly the same colour; it can hold a shape but it cannot hold type |
Node stayed a concept. 222 is the same instinct, with awards on it.
Another SCAD hardware ecosystem — two devices, a dual-sided app, and a live sanitisation cycle running the whole case study.
222