<aside> 🤝
Six days of research, decisions, prototypes, and feedback turned an open-ended resilience challenge into the Resilience Atlas.
</aside>
The team selected the open-ended challenge “Energy Infrastructure Vulnerability in New York City.” We gathered public evidence, compared different climate and energy pressures, tested several ways of presenting the information, and used feedback to shape a map-centered experience. Over six official program days, that work became the Resilience Atlas.
The team chose a broad challenge without a predetermined solution. We agreed to understand the condition first and allow the evidence to guide what we built.
Useful information was spread across public datasets, reports, research, and case studies. The team divided the research, brought findings together, and began seeing how flooding, heat, energy demand, buildings, and other pressures can overlap.
The research contained useful depth, but it needed a clearer form. Dashboards and early visual experiments helped the team learn what was understandable, what needed simplification, and why geography could make the relationships easier to explore.
After continued experimentation between the official sessions, the team converged around a map-centered experience supported by deeper analysis. Research, feedback, design, and implementation came together in the first Resilience Atlas.
With the product taking shape, the team refined the experience, worked through deployment, and aligned the evidence, the product's purpose, and the presentation story. This stage also helped reveal a reusable collaboration pattern that later became the Resilience Alignment Sprint.
The team presented the working Atlas through a shared narrative and live demonstration. The response generated visible curiosity and questions, while also reinforcing that a strong product and a shared way of explaining it both require attention.
Everyone contributed throughout the six days through some combination of research, questions, analysis, feedback, documentation, prototyping, design, implementation, and presentation work.
The project did not depend on every person doing the same kind of work. Its strength came from bringing different inputs together, learning from them, and allowing those inputs to influence what happened next.
Our working rhythm was simple: