Fallstudie
Dice Cat: En matchmaking-app för bordsspel
Skala
1,413
Commits
~72,300
TypeScript-rader
87
React-komponenter
10,000+
Spel i databasen
86
SQL-schemafiler
<500 ms
Matchningsfrågans tid (från 3-5 s)
Problemet
Bordsspelare samlar på sig stora samlingar och har starka preferenser, men det är verkligen svårt att hitta lokala spelare som äger samma spel, har samma tidspunkter och passar ihop spelstilmässigt. De alternativ som finns - Facebook-grupper, Discord-servrar, Meetup - kräver manuell samordning och erbjuder ingen matchning av spelbibliotek.
Det viktigaste kravet: skapa en applikation i stil med Tinder för brädspel som verkligen känner till ditt spelbibliotek.
Översikt
Produkten började som ”Meeplr” - ett UX-koncept som byggde på omfattande forskning redan innan en enda rad kod hade skrivits.
- ·Konkurrensanalys av befintliga verktyg för community- och matchmaking
- ·Utveckling av användarprofiler - en spelare som har flyttat och saknar en lokal spelgrupp
- ·Tre omgångar av användbarhetstestning med högt tänkande med 15 deltagare
- ·Kano-analys: alla planerade MVP-funktioner har bedömts som antingen prestandamässiga eller attraktiva
- ·Namnet ändrades till Dice Cat efter att en varumärkesundersökning visade att det ursprungliga namnet inte kunde användas - namnet visade sig vara lättare att komma ihåg i tester
Viktiga funktioner
- ·Flerdimensionell matchning: spelbibliotek, geografisk närhet, schemaläggningsöverlappningar och preferenser vad gäller spelstil
- ·En speldatabas med över 10 000 titlar, med lokal fuzzy-sökning och möjlighet att lägga till titlar manuellt
- ·Visuell verktyg för att skapa veckoscheman med funktion för att upptäcka eventuella tidsmässiga överlappningar
- ·System för anslutningsförfrågningar med ömsesidig matchning före meddelandeutbyte
- ·Krypterad meddelandefunktion i appen för planering av möten
- ·Push-meddelanden via Firebase Cloud Messaging
- ·Anpassad SVG-avatarbyggare med ett system av lagerindelade komponenter
- ·Karta över spelare i närheten med hjälp av geospatiala sökningar i PostGIS
Skärmdumpar
Teknisk arkitektur
Tekniska höjdpunkter
Databasens prestanda
JOIN-frågor med flera tabeller för matchresultat tog ursprungligen 3-5 sekunder att köra. Genom strategisk PostGIS-indexering och omstrukturering av frågorna kunde tiden minskas till under 500 ms.
Fel i beroendet av externt API
BoardGameGeek avbröt API-åtkomsten mitt under utvecklingsfasen. Vi bytte istället inriktning och byggde upp en lokal databas med över 10 000 spel, som fylls på av användarna - vilket ger bättre funktion offline och eliminerar risken för framtida beroende av tredje part.
Arkitektur för behörigheter för push-meddelanden
En triggerbaserad lösning stötte på behörighetsfel i produktionsmiljön. Vi flyttade logiken till Supabase Edge Functions, vilket löste problemet med behörighetskontexten på ett smidigt sätt.
Vad jag lärde mig
En matchningsapp för bordsspel bedöms på om folk faktiskt hör av sig till varandra, vilket visar sig vara ett annat mål än om matchningen är korrekt.
Ett kompatibilitetsbetyg är ett produktbeslut, inte en beräkning
Användarna rapporterade att poängen genomgående låg under 20 %, vilket ledde till att ingen kände sig motiverad att ta kontakt. Beräkningarna var rimliga; produkten misslyckades ändå. Genom att justera baserna och vikterna, så att en bra matchning visade 76 % istället för 65 % medan svaga matchningar fortfarande tydligt visades som svagare, förändrades beteendet utan att rankningen ändrades. Ett poängtal som visas för en person är en inbjudan, inte ett mått, och det måste kalibreras för det beslut som personen ombeds att fatta.
Att hämta allt fungerar tills någon är storanvändare
Det tog ungefär tio sekunder att öppna konversationer med över tusen meddelanden. Genom att ladda de hundra senaste meddelandena i fallande ordning och vända på dem inför visningen gick det på mindre än en sekund, och det påverkade inte korta konversationer alls. Sökningen fungerade utmärkt i alla avseenden som gällde när den skrevs, vilket är precis anledningen till att den här typen av problem är så besvärlig.
Ett obligatoriskt fält som inte är obligatoriskt för alla
Profilverifieringen krävde att alla angav en plats, även spelare som enbart spelar online och inte har någon användning för detta, vilket ledde till att en hel användargrupp inte kunde slutföra registreringen. Genom att göra platsangivelsen beroende av spelpreferenser och ange vilket fall som gäller i etiketten istället för i en anmärkning kunde man lösa både hindret och den förvirring som låg bakom det.