Wellmate: Gamifierad hälsoapp för arbetsplatser

Brief

"För att uppmuntra mer fysisk aktivitet och socialt utbyte i ett team kan en användare skapa en 'träning i veckan' som alla ska genomföra - fem knäböj före lunch, etc"

Kärnproblem

Skapa en gamifierad social wellness-app som tar hänsyn till de olika motiv människor har för att delta.

Bonusutmaning

Detta var ett internt projekt på Bright Skills där jag praktiserade. Det var tänkt som ett proof-of-concept för junior-utvecklarna som lärde sig OutSystems low-code-plattformen, så utöver applikationsbriefet hade jag också några tekniska krav:

• Enkel design utan animationer
• Ingen SVG eller annan inbyggd grafik (endast PNG)
• Måste använda AI i någon kapacitet

Resultat

Levererat: Interaktiv Figma-prototyp och visuella tillgångar till Bright Skills utvecklingsteam.

Implementation: Utvecklad som ett icke-funktionellt proof-of-concept i OutSystems av junior-utvecklare som lärde sig plattformen. Gränssnittet implementerades; utmaningsgenerering och sociala mekanismer förblev endast platshållare.

Affärsresultat: Bright Skills lade till detta i sin portfölj som ett showcase-exempel på snabb mobilapp-prototyping i OutSystems, som demonstrerar LLM-integration (detta var tidigt 2024, tidiga dagar av LLM-adoption).

Användarresultat: Appen distribuerades aldrig eller användes av faktiska kontorsteam. Den existerar som en teknisk demonstration, inte en validerad produkt.

Meta-mål uppnått: Projektet demonstrerade framgångsrikt Bright Skills förmåga att snabbt iterera på mobilklara applikationer och integrera framväxande AI-kapaciteter—båda viktiga försäljningsargument för deras konsulttjänster.

Jag hade två veckor på mig att leverera en färdig design, med en wireframe-leverans halvvägs. För att komma igång snabbt, och eftersom denna app var en undersökande MVP snarare än grundad på en befintlig hypotes, gjorde jag konkurrentanalys för att försöka bedöma mekaniken och mervärdet hos de mest populära gamifierade spelen och uppgiftsorienterade apparna.

Detta tillvägagångssätt är fullt av bekräftelsebias eftersom gamifiering ofta riktar sig till människor med ett visst beteende, inte nödvändigtvis representativt för människorna på ett typiskt kontor, vilket var vår målgrupp.

Ändå kunde jag identifiera några användbara trender:

• Vänlig ton och lekfulla färger
• Uppriktiga och personliga utmaningar
• Minimal skambeläggning av icke-deltagare

Många av de framgångsrika tillvägagångssätten låg utanför räckhåll för oss - fancy grafik, ljuddesign, spelelement, avancerade progressionsstegar, etc - och vi hade inget incitament att locka användare med mikrotransaktioner eller belöningar, så jag kunde säkert ignorera sådana funktioner.

Eftersom miljön för vår app var företag ville jag tillåta både "positiv" och "negativ" deltagande. Det finns en risk att uppmuntra "giftig positivitet" med initiativ som dessa, vilket är kontraproduktivt för målet att uppmuntra teamkänsla, och att tillåta någon att delta på sina egna villkor verkade som en viktig aspekt - till exempel kunde du sätta svåra eller oklara utmaningar, vilket gör att du kan "avreagera dig" samtidigt som du fortfarande deltar i den sociala aspekten av appen.

Samtidigt skissade jag kraven för ett minimalt användarflöde. Mitt mål var att maximera möjliga engagemang över så få skärmar som möjligt så att vi kunde utveckla en MVP snabbare, samt tvinga mig att fokusera på en tydlig IxA och UX-kopia.

Jag analyserade 10+ wellness- och gamifieringsappar för att identifiera framgångsmönster och anti-mönster. Appar som granskades inkluderade Habitica (gamifierade vanor), Sweatcoin (steg-till-belöningar), Noom (kaloriberäkning med vänlig ton), Challenge Accepted (sociala utmaningar + topplista), Stridekick (gruppfitness-utmaningar) och Fitness RPG (karaktärsutveckling genom träning).

Viktig insikt 1: Onboarding-friktion dödar adoption

Forskning visar att varje ytterligare onboarding-steg förlorar 20% av användarna. Appar som Sweatcoin och Habitica lyckas eftersom de minimerar den mentala uppstartskostnaden – du är engagerad inom 2-3 tryck. Detta informerade vårt beslut att göra utmaningsbedömning valfri, inte obligatorisk.

Viktig insikt 2: Valparadoxen

Habitica erbjuder omfattande anpassning (svårighetsnivåer, kategorier, filter) men kräver betydande innehållsskapande från användare. Appar med förgenererat innehåll (som Stridekicks kurerade utmaningar) ser högre engagemang. Vår metod: Samma veckovis utmaning för hela teamet, vilket tar bort beslutparalys, samtidigt som social koppling bibehålls.

Viktig insikt 3: Ton är viktigare än funktioner

Noom lyckas inte på grund av överlägsen spårning, utan på grund av sin uppmuntrande, icke-dömande ton. Appar som skuldbelägger icke-deltagande (visar "0 dagars" streaks framträdande) har högre churn. Vår metod: Tillåt neutrala/negativa utmaningsbedömningar för att ge användare handlingskraft utan att tvinga fram giftig positivitet.

Viktig insikt 4: Mörka mönster att undvika

Många wellness-appar använder manipulativa mekanismer: spin-the-wheel-slumpmässighet, pay-to-win-nivåer (Sweatcoins 2x-intäkter), konstgjord brådska. Vi undvek medvetet dessa då vårt mål var sammnhållsning i teamet, inte spelberoende.

Vad vi inte kunde implementera (OutSystems-begränsningar):

• Komplexa progressionssystem (Fitness RPG:s karaktärsutveckling kräver omfattande backend)
• Rika animationer och mikro-interaktioner
• Avancerad gamifiering (prestationer, upplåsningar, topplistor över tid)
• Wearable-integration (Hops Apple Watch-integration)

Vår anpassning: Fokus på sociala mekanismer (teamövergripande utmaningar) över individuell gamifiering. Prioritera enkelhet (en utmaning per vecka) över variation (oändliga utmaningsbibliotek). Möjliggör både "positiv" och "kritisk" deltagande för att undvika att arbetsplats-wellness blir performativ.

Skisser, interaktiva wireframes och flödesscheman kompletterar varandra: Där det ena måste vara rigoröst eller pedagogiskt kan det andra bara notera att man ska "slänga in en cool animation här" utan att bry sig om detaljerna eller ansträngningen att göra det. Detaljerna kommer fram i diskussionerna med PO och dev-teamet.

Även om detta var en proof-of-concept-prototyp utan funktionell backend, genomförde jag informell användbarhetstestning av UI-elementen (gilla/ogilla-knappar, utmaningsskapande, hoppa över utmaning, navigering) i kafémiljöer för att validera IA och interaktionsmönster.

Viktig feedback som formade slutlig design:

• Öka avståndet mellan interaktiva knappar (användare trycker av misstag på fel alternativ)
• Gör aktiva/passiva knapptillstånd mer visuellt distinkta
• Klargör att utmaningsbedömning är valfri, inte obligatorisk

Dessa snabba valideringssessioner säkerställde att kärninteraktionerna var begripliga även utan att gamifieringsmekanikerna fungerade fullt ut.

Kafétest är inte rigorös UX research, men det är värdefull snabb validering när tidslinjer är snäva. Att få 5-10 personer att trycka genom en prototyp i 10-minuters sessioner avslöjade interaktionsfriktion jag inte hade märkt, särskilt kring UI och valfria vs obligatoriska åtgärder.

Det viktigaste fyndet: användare antog att betygsättning av utmaningar var obligatoriskt och kände sig stressade när de inte kunde bestämma sig. Att lägga till "Hoppa över betygsättning" som ett explicit alternativ (snarare än implicit) minskade omedelbart förvirringen.

Utmaningen med tre-tillståndsknappar

Den mest betydande friktionen kom från ett till synes enkelt UI-mönster: knapparna med vilka man bedömde veckans utmaning.

Kravet: Två knappar (tumme upp/tumme ner) som kunde representera tre tillstånd:

• Ingen vald (neutral/ingen betygsättning)
• Tumme upp vald (positiv betygsättning)
• Tumme ner vald (negativ betygsättning)

Varje knapp växlar mellan två visuella tillstånd, men de påverkar också varandra: att välja en, avmarkerar den andra.

Problemet: Min Figma-prototyp visade interaktionen tydligt när man interagerade med den, men utvecklare kunde inte avkoda beteendet från enbart prototypen. De kunde inte se "reglerna" bakom interaktionen.

Lösningen: Flera kommunikationsmetoder

Jag var tvungen att förklara samma interaktion på tre olika sätt innan dev-teamet förstod:

1. Figma-prototyp (visade beteende, inte logik)
2. Handritade knapptillstånd med pilar som visar övergångar
3. State table som listade alla möjliga kombinationer och resulterande tillstånd

Lärdom: Interaktiva prototyper kommunicerar inte alltid avsikten tydligt. Komplex UI-logik behöver explicit dokumentation — tillståndsdiagram, sanningstabell, eller skriftliga specifikationer – särskilt när man arbetar med utvecklare som inte är bekanta med Figmas prototypfunktioner.

Vad jag skulle göra annorlunda: Definiera interaktionsmönster i förväg med utvecklare innan prototyping. Etablera delad terminologi för UI-tillstånd och beteenden. Skapa ett enkelt "interaktionsspec"-dokument för allt mer komplext än standard knapp/input-beteende.