Badger Town
A location-based collection game where exploration, character customisation and dynamic digital ownership become one journey.
- UX/UI co-design with the technical founder
- Jul 2024
- Launched · short lifespan
- Onboarding · Map and proximity mechanics · Collection systems · Dynamic NFT customisation · Reward logic
An independent side project, shipped
Badger Town was an experimental location-based game launched in July 2024 by a fintech technical founder. Working with him, I co-designed a mobile experience that connected city exploration, clue solving, collectible items, character customisation and dynamic digital ownership.
The product needed to make a technically complex journey feel playful and coherent. Players had to understand where to explore, how to collect items, what each item changed, when a wallet interaction was required, and how their progress unlocked new rewards.
Seven behaviours, one journey
- IdentifyENS or ETH address
- Catch a Badgeryour character
- Explore the mapcity-scale
- Open a clueapproach a place
- Collect an itemwithin 500 m
- Build an outfitfrom inventory
- Update the NFTand unlock rewards
Reduce wallet friction without hiding the requirement
Separate identity, browsing and full participation
Wallet connection is the highest-friction step in a consumer product like this, and putting it first turns a curious visitor into an immediate dead end. Hiding it entirely is worse: people discover the requirement after investing effort.
Players could identify themselves with an ENS or ETH address and defer the wallet connection, with an exploratory path available before they had even caught a Badger. When connection was finally needed, the sequence exposed two explicit steps (connect the wallet, then sign a message) rather than one opaque action.
Proximity, clues and irreversible actions
The experience makes location constraints explicit. When a player is outside the collection radius, the interface says so and states the rule (you must be within 500 metres) instead of failing quietly.
Hints could be consumed and then closed permanently, so the product adds a confirmation step before that information disappears. The value here is not the map illustration: it is the handling of spatial rules, irreversible actions and proximity feedback.
Making a dynamic NFT update understandable
Changing an outfit was not a UI preference. It rewrote what the player owned.
Show the consequence before asking for the signature
Saving a new look required blockchain actions that removed the previous outfit and applied a new one. A single Save button would have asked people to authorise a transaction whose result they had not seen, and whose failure mode they could not predict.
The flow separates preview, wallet connection, removal of the previous outfit, application of the new one, loading, confirmation and optional sharing. It also protects the player from losing unsaved changes and supports reverting to a previous configuration.
Collections turn exploration into a visible goal
Collection sets gave exploration a shape: recent items, grouped sets and visible progress. Reward eligibility was then explained as a checklist of the collection and customisation actions still required, never as a locked box with no stated condition.
What shipped, and what I would change
The product launched as an independent side project in July 2024 and had a short lifespan. What follows is a reflection on the interaction model, not a claim about scale.
If your product has more rules than screens, we should talk.