From a problem worth solving to a product people can use.

Discover

Start by understanding the real problem.

Greenridge began as a camping tool for Maryland’s Green Ridge State Forest.

I spent time understanding how people actually find campsites, what information is available before they arrive, and where that information breaks down. One of the most useful sources turned out to be something very simple: a clipboard posted at the campground showing which sites were occupied.

That changed the problem.

The opportunity was not just to build a better campground directory. It was to make scattered, temporary information easier for people to use.

Build

Make enough of the product to learn from it.

Once I had a direction, I built the product rather than stopping at screens.

Greenridge became a working web and mobile application with offline support, image capture, OCR, and a review step for information the system could not confidently interpret.

Building it exposed questions that would have been difficult to answer in a prototype alone. How reliable was the image recognition? What happened without a network connection? When should the system ask a person to verify something?

Those became design questions as much as technical ones.

Test

Test the assumptions.

I tested the reader against 86 real campground photos, with glare, blur and hurried handwriting.

No reader was right every time.

That ruled out a product direction. Instead of designing around the assumption that the model would usually be right, I kept human review in the workflow and used confidence thresholds to decide when the system should ask for help.

The implementation changed because of what the testing showed.

Reframe

Follow the problem when it changes.

Working on Greenridge also changed how I thought about the product itself.

The same pattern exists well beyond one campground: useful information is often scattered across signs, photos, websites, PDFs, and local systems. People nearby frequently know something that would make the information more useful to everyone else.

That led me to explore Greenridge as a broader system for gathering and improving place-based information, rather than only as a camping application.

That shift came from building and observing the product, not from deciding on a larger vision at the beginning.

Deliver

Stay with it through the build.

This is generally how I work.

I spend enough time with users and the domain to understand what is actually happening. I make the product concrete early. I work closely with engineering because implementation exposes things the design process cannot predict. And I use testing to change the direction when the evidence says it should change.

The process moves back and forth, but the goal stays simple: understand the problem well enough to build something useful, then keep learning from the thing you built.