Where The Wild Beasts Roam turns 14+ years in Yellowstone and Grand Teton into a live wildlife-planning product. It began as a map of delayed field observations. It now builds a route around the user’s starting point, wildlife priorities, available time, and time of day, then adds field notes, directions, scenic stops, and a backup move. I owned the product from the first field problem through research, UX/UI, code, content, checkout, launch, analytics, and support. The rule never changed: help people plan better without turning wildlife into live targets.
See how the product evolved. Map-first MVP, route logic, AI guardrails, commerce, heatmaps, and iteration.
The assignment
I started with a problem I had watched for years in Yellowstone and Grand Teton. Visitors had maps, apps, Facebook groups, and plenty of opinions. They still did not know where to begin. I turned that gap into a live paid product, then used real behavior to rebuild the core experience from a map-first tool into a route-first planner.
The problem
Most visitors entered the parks with hope, not a plan. They pieced together old tips, watched traffic, and burned their best wildlife hours deciding which road to take. The obvious answer was a live sightings map. That would have made the product more exciting and the wildlife less safe.
The product tension Make the information useful enough to change the day, but never immediate enough to turn an animal into a destination.
Give someone a clear place to begin, a reason for the route, and a backup when the day changes.
Use delayed or less exact information, safe pullouts, distance guidance, and honest limits instead of live targeting.
Keep the important choices readable on a phone, in bright light, with weak service, traffic, and very little patience.
Show enough value before checkout, keep access simple, and make the product manageable for one founder to maintain.
Research in the real environment
I combined years of field observation with user questions, working-product tests, search behavior, support messages, checkout friction, and what people did after the product went live.
I watched how habitat, light, roads, seasons, weather, traffic, and human pressure change the quality of a wildlife plan.
Context that does not come from a list of popular stopsWhere should we start? Which road fits the time we have? When should we turn around? Those questions defined the real job.
Problem framing in the visitor's languageI put real flows in front of users, watched where the planner became unclear, and changed the order, language, controls, and states.
Prototype, observe, revise, releaseHeatmaps, search terms, page paths, support questions, purchases, and drop-off exposed problems a polished mockup could not.
The operating product became the research labBehavior after launch
I used the heatmap as a diagnostic, not a scorecard. It helped me see where attention was strongest, where it thinned out, and where the website still took too long to show the value of the finished route.
The opening was earning attention. The harder question was whether people reached enough of the product story to understand what they would actually leave with.
I brought the result forward. The newer experience shows the route, the phone flow, the reasons behind the recommendation, and the sample earlier instead of making people learn the whole system first.
Let people see the route and what it gives them before explaining every feature.
Lead with where to start and how to use the day, not internal product names.
The preview should let someone feel the planning logic before deciding whether to buy.
The product reframe
The first product asked people to open a map and make sense of it. The current product asks about the day first, then uses the map to support a decision.
Every wildlife entry is dated and added after fieldwork. Precision can be reduced when it creates more risk than value.
The route explains habitat, timing, field patterns, and why an area belongs in the plan. It never promises an animal.
A few plain questions remove more work than another layer of filters, pins, and settings ever could.
The guided path recommends a first move. The full map remains available for people who want to choose every stop.
Distance, pullouts, traffic, animal response, and when to move on are part of the experience, not a footer disclaimer.
A free sample route, a working preview, clear limits, and transparent access help people understand what they are buying.
The visible transformation
The product had changed, but the website was still explaining the old idea. I rebuilt the message, page order, visual system, and purchase path so the acquisition experience finally matched what the planner had become.
The original mobile experience made the map the starting point. The current version gives a first-time visitor a guided way in, then keeps the full map available when they want more control.
The promise changed from seeing pins to building a day around where the visitor starts and what matters most.
The page now shows what someone leaves with before it asks them to understand every tool.
The working sample, current screens, customer messages, safety language, and clear limitations do the convincing.
Preview, price, guarantee, checkout, account access, and return use now read as one connected experience.
The current product
A first-time visitor can move from a few simple choices to a route they can understand, open, save, print, and use. Someone who wants more control can still move directly into the full map.
The current experience removes the hardest work from the first screen. It asks only what it needs, then returns a route with enough reasoning for the visitor to trust the next move.
The route begins where the visitor will actually start driving, not at a generic park entrance.
One clear priority gives the route a job and keeps the first plan from becoming a list of everything.
Available hours, visit timing, and time of day shape which corridor makes sense.
The plan explains why the route fits, what to watch for, which field entries matter, and where scenic stops belong.
Open the map, get directions, print the route, save it as a PDF, and keep a backup move ready.
From field problem to working product
This was not a clean handoff from research to design to development. The same decision had to survive the flow, the interface, the code, the sales page, the checkout, the account state, and the support message after purchase.
Years in the parks exposed the gap between the tools visitors had and the decision they still could not make.
Output: problem evidence and visitor questionsI made the ethical rule part of the product definition: useful planning without live animal targeting.
Output: product promise, audience, limits, and tradeoffsI moved from rough wireframes into working flows for maps, filters, route questions, field notes, and product states.
Output: flows, wireframes, interface system, and copyI built the responsive map experience, route logic, content model, access states, and details that make the product usable live.
Output: working product across desktop and mobileI created the sample, offer, checkout, membership, account path, field guides, trust language, and acquisition pages.
Output: paid access and a complete customer pathI watched behavior, read support questions, tested new flows, and changed the product and the promise together.
Output: major releases instead of cosmetic updates
The operating system
I built the full path from discovering the idea to returning with a plan. Every vague promise became a support question. Every missing state became friction.
Search, wildlife stories, photography, press, social posts, and field content introduce the problem.
The website explains the outcome, the limits, the two planning paths, and who the product is for.
A free sample route and working map state let people experience the thinking before they pay.
One-time pricing, guarantee, checkout, account creation, and access states make the exchange clear.
Suggested routes, full map control, field notes, directions, scenic stops, PDFs, and backup moves support the day.
New field entries, route updates, guides, email, account access, and support keep the product useful.
Building the whole system forced me to treat acquisition, onboarding, payment, access, content, trust, safety, analytics, and support as one experience. A customer does not care which layer owns the problem.
Trust and responsibility
A wildlife product could chase engagement with live locations, constant alerts, and the promise of certainty. I chose a calmer model. The planner helps people use uncertainty better instead of pretending the wild can be scheduled.
Observations are posted after fieldwork and can be made less exact when precision would create more pressure.
The product says what it is not: live tracking, a guided tour, a sighting guarantee, or a replacement for current park alerts.
Legal pullouts, animal response, traffic, and the 25-yard and 100-yard distance rules appear inside the planning experience.
The route and planning assistant support a decision. They do not automate the field or pretend conditions stay the same.
Continuous product work
The product did not move in a straight line from idea to success. Each release answered one question and revealed the next one.
The first release proved the field knowledge could become a usable product without becoming a live feed.
Real use showed that the product needed to explain the first move before it exposed every control.
Park, starting point, wildlife, time available, and time of day became the inputs for a suggested route.
The free sample route, map preview, clearer limits, field guide, and guarantee made the offer easier to judge.
Directions, route reasoning, scenic stops, field context, a printable PDF, and a backup move completed the field workflow.
The latest release aligns what the site promises with what the planner now delivers across desktop and mobile.
Outcomes
The product is live. A visitor can discover it, try a sample, purchase access, build a route, save the plan, use it in the field, and influence what gets improved next.
The product, website, code, content, commerce, account access, and support path operate in the real world.
Customers have moved beyond interest and purchased lifetime access to the planner.
Years of field knowledge now power routes, filters, timing, notes, safety context, and planning decisions.
Yellowstone and Grand Teton share one product while keeping different wildlife patterns, roads, and route logic.
The product now begins with the day, recommends a route, explains the reasoning, and keeps the full map available.
One person stayed accountable for the promise, the interface, the implementation, the sale, and the next release.
The stronger proof is more useful to a hiring team. I found a real problem, built a paid product, put it in front of users, watched the original model fall short, changed the core workflow, rebuilt the website around the new value, and kept the business and experience connected.
What this project proves
I can join a team at one stage. This product proves I understand what happens before it, after it, and at every seam where a good decision can weaken.
Turn a repeated field problem into a focused product with a clear promise, audience, business model, and boundary.
Combine field observation, user questions, working-product tests, heatmaps, search behavior, purchases, and support signals.
Turn complex map and route logic into a short flow that still handles choice, uncertainty, and advanced control.
Explain a nuanced promise in plain language without false certainty, generic claims, or hidden limits.
Connect product screens, maps, wildlife art, field guides, marketing pages, safety language, and trust cues.
Carry responsive behavior, map states, route controls, content, commerce, membership, and accessibility into the live build.
Use a planning assistant where it helps, set explicit limits, and keep the product from acting more certain than the field allows.
Connect search, social, sample use, checkout, account access, analytics, support, and release decisions.
Reflection
Building this as the founder changed the way I design. Every vague flow becomes support. Every shortcut becomes maintenance. Every promise becomes trust debt when the product cannot carry it.
Once the product asked where the day begins, what matters most, and how much time exists, the map became easier to use.
Refusing live tracking forced the experience to create value through field context, route judgment, timing, and planning.
Coding the experience exposed missing states, weak language, and technical friction that a polished mockup could hide.
More selected work
The domain changes. The work still comes down to finding where people get stuck, making the decision clear, and carrying it into the live experience.
A strong fleet product was making buyers work too hard to understand it. I rebuilt the path from first question to trial or demo.
Read case study →Designing complex enterprise workflows where clarity, speed, and consistency matter. The case study will use reconstructed, sanitized visuals rather than client screens.
Read case study →Available for full-time roles
I am looking for a full-time Senior Product Designer or UX/UI role where I can work closely with product and engineering, make complex systems easier to use, and stay accountable after the design review.