Wauke Webapp

Wauke Webapp is an interactive mapping dashboard tracing where wauke (paper mulberry, the primary source material for Hawaiian kapa) is currently cultivated across Oʻahu. The dashboard visualizes ecological conditions at each cultivation site and models potential outputs of expanded propagation. It exists. The current work is to ensure it makes the argument it was built to make.

The product framing that shaped every design decision: this is not a data dashboard. It is a proposition. Most tools built for land and resource management ask what can be extracted from a place. Wauke Webapp inverts that logic entirely: it asks what can be grown back, and makes the spatial case that the conditions for that restoration already exist.

Wauke cultivation in Hawaiʻi is fragmented. Practitioners who work with kapa know the plant exists in certain places, but there is no shared spatial intelligence about where it grows, under what conditions, and what would be required to expand it. The result is that cultural restoration work, specifically the revival of kapa making as a living practice, happens without a clear picture of whether the material conditions for that revival are in place.

The product problem isn't data collection. Ecological data about Oʻahu exists. The problem is framing and argument: there is no tool that takes that data and uses it to make the affirmative case that wauke can come back, that the soil conditions are right, that specific sites are viable, and that expansion is spatially possible. The tool that makes that spatial argument does not yet exist.

This is a solo product design engagement. Conception, UX architecture, data visualization design, and ongoing refinement are all my work. The Applied Product Lead dimension here is in the product argument itself: defining what the platform claims and ensuring every design decision serves that claim.

• Defined the product thesis: documentation versus proposition. That distinction shaped every UX decision that followed
• Designed the information architecture of the mapping interface: determining which ecological data layers to surface, how to present them, and what order of operations a user follows to understand the argument
• Made the palette and visual language decisions that ground the platform in ʻāina: warm ecological tones, wauke cream, forest greens, amber soil tones, not a generic data dashboard aesthetic
• Integrated ʻōlelo Hawaiʻi into the interface: place names, data layer labels, and instructional copy evaluated for cultural legibility to practitioners and community members, not tourists or external audiences
• Structured the propagation potential visualization to communicate dynamism. This is a living map, not a static report. The interface is designed to feel like something in motion, not a fixed document
• Conducted a refinement audit against the product thesis to evaluate every design decision before finalizing the portfolio submission

The decisions that define this product are not feature decisions. They are argument decisions: choices about what the platform claims and how it makes that claim spatially legible:

• Proposition over documentation. The map does not describe what exists. It argues for what could. That distinction required designing toward a specific conclusion, not neutrally presenting data and letting the user draw their own conclusions. That is a harder and more purposeful product design choice
• ʻŌlelo Hawaiʻi as a design requirement. Place names, data layers, and interface copy were evaluated for cultural legibility to practitioners: the people for whom wauke cultivation is a living practice, not an academic subject
• Ecological honesty in the visual palette. The color system was built around the plant and the land: wauke cream, forest green, amber soil tones. A generic data dashboard palette would undermine the argument the product is making about relationship to place
• The "living" quality as a design constraint. The title claims a living map. That word is a product requirement. The interface must communicate that this data can change, that the practice is growing, that this is a document of something in motion. Static data presentation would fail the argument
• Designed for practitioners, not external audiences. Every interaction and label was evaluated against whether it serves a kapa practitioner or community member, not a researcher, tourist, or policymaker approaching the subject from outside

Wauke Webapp is the most literal piece in this portfolio. It is about the actual plant: where it grows, where it could grow, and what its expansion would mean for a living kapa practice. Every other product I've built presupposes the existence of material. This one asks the prior question: is the material there? Can it come back?

That question is not abstract for me. I practice kapa. I work with wauke bark. The research and design decisions in this platform are grounded in practitioner knowledge, not just ecological data. That's what makes the argument credible rather than speculative.

Design as a restoration tool means the map is not describing what exists. It is arguing for what could. That distinction, documentation versus proposition, is what makes this a product, not a report.

The webapp exists. The core mapping functionality, ecological data layers, and propagation potential visualization are built. The current work is a refinement audit: evaluating the existing product against the thesis before finalizing it as a portfolio piece.

The audit questions: Does the visual language feel grounded in ʻāina or generic? Is ʻōlelo Hawaiʻi present where it needs to be? Does the interface communicate dynamism or fixed documentation? Is the plant itself visually present, or abstracted into data points with no material grounding? Every change made in refinement must serve the argument, not just improve the aesthetics.