Most recommenders learn from behavior without showing the user what they concluded.
Most recommendation systems ask for a rating and move on. I wanted Tastemake to show the patterns behind its recommendations too. If it decides you like something because of atmosphere, pacing, characters, or another pattern, you can tell it whether that read is right.
The question became less about making a smarter recommendation list and more about whether the user could understand and improve the model behind it.
Feedback gives Tastemake a working theory, not a permanent label.
Loved, Liked, and Didn’t like come from something the user actually tried. Saving or browsing does not count as taste evidence on its own.
Tastemake shows the patterns it is using instead of hiding them inside a recommendation score.
A user can say a pattern is right, partly right, too strong, or just wrong. Tastemake keeps that correction separate from the original AI guess.
The biggest improvement was showing what actually changed.
Earlier versions could build a Taste Profile, but the user still had to guess what their feedback changed. I redesigned that part so Tastemake explains what it learned and how that will affect future recommendations.
Neon Gods → Loved.
A broad romance pattern gets narrowed to mythic atmosphere and morally messy characters.
Future picks can lean on those traits without assuming every similar romance will work.
Recommendation explanations use the same approach: why this might work, what Tastemake is testing, and what could still be wrong.
The product only worked if feedback meaningfully improved future recommendations.
The current version uses live model calls for two distinct AI functions: ranking recommendations and generating the Taste Profile. The surrounding product logic stays deterministic, including catalog constraints, saved-versus-tried state, and the controls that decide what evidence is allowed to influence the profile.
Live AI ranks recommendations and builds Taste Profile hypotheses. Software still decides what counts as evidence, which catalog items are allowed, and whether model output is valid.
Recommendation generation was taking roughly 10–16 seconds in testing, with model inference dominating the wait. At that point the delay was part of the user experience, not just a backend metric. I reduced unnecessary prompt context and changed the loading experience so the flow stayed understandable while the model was working.
Tastemake pulls from real catalog sources, then applies its own rules and stored metadata so the product is not limited to a hand-written demo set.
I built coverage around recommendation quality, AI output validation, evidence rules, profile corrections, accessibility, mobile layout, and the first learning loop.
How I split the work
- defined the product model and UX rules
- redesigned the Taste Profile so Tastemake explains what it learned and how that will affect future recommendations
- moved deeper taste questions behind the first reaction so the recommendation card stays simple
- led evaluation and testing, including using a confident miss to refine the underlying taste pattern rather than just suppress that one result
- research
- implementation
- debugging
- test support
The more interesting product was the editable taste model behind the recommendations.
The product got more interesting when feedback became part of the taste profile itself. A useful correction should change how the system understands someone’s taste and what it recommends next.