The Problem
What the feature looked like before. Plain and functional.
For outdoor recreation clubs, photographs serve multiple purposes. They are informal records of attendance, and they help attendees remember and share the experience long after the trip is over.
In the application today, the problem for organizers is that a library of photos is not very useful as an informal record of attendance unless the organizer knows WHO was in each photo.
For attendees, it is challenging to find specific photos and memories if an entire library of photos is lumped together without the related metadata about WHO was in each photo.
Trailwerks supported photo galleries and this was good enough for sharing and scrolling through event photos. Admittedly, it was just not a very “polished” feature in the app. It just looked kind of raw.
Appetite
As the founder and engineer, my appetite for a feature like this is approximately 1 afternoon.
Solution
Rapidly generated AI mockup for inspiration
The solution is to provide a way to tag people in the photos. This makes it simple to create and maintain the metadata that will make photo libraries query-able and useful as informal records of attendance.
Of course this can be done manually, but we can lighten the burden on users by automating identification with a tool like Amazon Rekognition.
Also, it will just look a whole lot better.
Places and Affordances
Event album - filter by person, chips on the card (Maya +2), empty “no photos of Maya yet,” click into the viewer.
Photo viewer - two-column look: photo well, event UI, caption, who’s here, comments, filmstrip. Named boxes stay hidden until you hover a chip.
Add someone - search; on this hike first, then the rest of the group; guest name if they are not on Trailwerks.
Place a tag - tap the person, or tag without a spot. Save is the one clay action.
Unnamed face - question-mark box. Looks like Maya? then that’s them / not them / pick someone else / skip.
Remove a tag - chip ×, or that’s not me on yourself.
Comments - oldest first, like, post. Secondary next to a tag CTA. (nice to have)
Profile, on the trail - photos they are tagged in, not outings they joined. Thumb opens that photo.
Group settings (admin) - face suggestions on/off for the whole group. No member toggle. No vendor name in the UI.
Trust is the feature
Face matching is off by default. Every group starts with it disabled and a
group admin (not an organizer or member) has to turn it on. If it's off,
nothing is detected, nothing is indexed, and no image ever leaves the app for
analysis. Off is a real no-op, not a hidden UI toggle over a running pipeline.
When a group does turn it on, the constraints are enforced in code, not policy:
Faces never cross groups. A face learned in one club is invisible to every other
club on Trailwerks.Only confirmed tags teach the system. A detected face is never indexed. A
reference face is stored only after a human accepts a tag. The library is built from human judgment, not from guesses.Suggestions are limited to people who said they were there. A match is only
surfaced if that person has a confirmed RSVP for that specific event."Not them" sticks. Rejecting a suggestion records that decision against that
face permanently. It won't be suggested again.Deleting means deleting. Delete a photo and its face vectors are deleted from
the provider.
Result
The end result works effortlessly. Rekognition builds a libraries of faces that are scoped to each individual group as new photos are uploaded and tagged. Then familiar faces are automatically identified and tagged. The benefits are clear.
Photographic confirmation of the RSVP list for group organizers
A more query-able photo library for event attendees
Additional data for community analysis calculations
Users can now comment and like photos for better interactivity
And all it took was one afternoon. Stakeholders and project managers love an accurate timeline.
Did I mention that it just looks better?