The making of Red Bull Secret Gig x Robyn

So we made a game for Robyn and Red Bull Music. This is the second post in a series of posts about this. Here our UX Designer Nana talks about designing a competition for the compassionate, and the secret ingredient to a sticky game.

Post nr 1: Making the server side
Post nr 2: This post…
Post nr 3: The design of…

If you ever get the chance to make something for Robyn’s fans, take it.

This year Robyn released her first album in eight years, and the only way to get tickets was to play a game. We were asked to make this high stakes competition while encouraging collaboration and generosity. On top of that we were tasked to force the players to interact face-to-face with strangers and make it enjoyable.

As a Stockholmian that enjoys the comfort behind my screen and noise cancelling head phones I had to wonder, what does that even look like?

Photo: Johanna Sjöstrand

This totally looks like a staged PR-pic, but it’s just a couple of Malmö swappers trying to charm Red Bull into giving them a rare artifact.

Spoilers! Before we get to that, we wanted to share some behind the scenes of making the game. It has been an absolute blast, and we are so grateful we got to make something for Robyn’s wonderful fans. Game mechanics and design can only nudge players so far, what they chose to do with it was the real magic.

So here is a peek into the work that went into bringing this game to life! I can talk about this game for hours, but to keep it short (hah!) let’s focus on three goals I as a game designer had my eyes set on:

  • Reward collaboration and hardcore fans
  • Make the game bigger than the app
  • Make meetups meaningful and memorable

Rewarding collaboration and hardcore fans

Red Bull and Robyn knew they wanted a board with pieces. Each day the players would get a new piece and they would have to meet up with other players IRL to trade copies of their pieces in order to fill their board. There were also rare pieces that could only be unlocked with a code. (If you’ve played the game you might notice we didn’t call it “artifacts” or “swapping” yet)

As a UX Designer for a super secret project that can’t be user tested on a big scale it was my job to try and predict what the players would do with the game mechanics we gave them. It was a tough case to crack considering we had no idea if we would have 500 or 10 000 players.

© OpenStreetMap contributors (

Heatmap timeline of 20 000+ players meeting up 320 000+ times and unlocking 50 000+ artifacts during the game’s three weeks. I was so young and naive.

If it was only a race to collect the most artifacts there would be no incentive to help each other out (except for the kind nature of your heart). So we decided to center the scoring system around four main metrics:

Going into this we knew there was a risk of opportunistic players in big cities joining on the last day. We added achievements and scored them in a way that rewarded dedication and being an early adopter. Having a 14 day streak was worth more than meeting 30 people. In the end, 95% of the top 500 players joined the first week of the game. The top 5 Swedish players all joined within the first 4 hours.

We didn’t let the users know exactly how we scored their progress, we hoped it would encourage players to compare and collaborate. But they had a statusbar that let them know if they were on track for a ticket or star treatment.

It was a close race to the ticket level. In the end the difference between number 450 and 550 was the equivalent of meeting 40 people and sharing 70 artifacts. But there was a nice spread in the top 500. The top player met 923 people, shared 2 200 artifacts and earned 70 060 points. Player number 500 sat on 13 440 points.

Making the game bigger than the app

One way we nudged players to collaborate and reach out to each other was making them think of the game bigger than the app. That meant we didn’t want the app to be too comfortable to stay in.

At first there was talk about missions in the app that would unlock rare artifacts (one I fondly remember was Robyn’s idea to stand quietly in the woods for 10 minutes) but for multiple reasons we decided that the rare artifacts would be unlocked with codes that could appear unexpectedly in the physical or digital world.

Another example of how we did this is how we designed the swap-radar where players could choose who to swap with. If we wanted to make the app comfortable, we might have gone this route:

Early swap-radar sketch.

If nearby players were always visible on a map and the player could zoom in, out and pan around it would be pretty easy to stay in the app and keep an eye on when players were nearby, and how to get to them. Instead, we wanted the players to hit each other up outside the app, so we didn’t want to let them get a too good idea of their surroundings. Here is our journey from wireframes to the finished look:

Making meetups meaningful and memorable

I think the first thought that comes to most people’s minds when they think of a trading system in a game is pretty simple: Player A sees Player B in the game and sends a request to trade. Player B accepts, and they automatically trade pieces. But that just ain’t gonna cut it when we’re trying to force them out from behind their comfortable screens. (Sorry!)

We explored different swapping systems. QR-codes, bluetooth, bumping. But we were falling into the trap of letting technology make the connection for us.

The solution was kind of simple. One player gets a code if they are standing close enough, and the other player has to enter it on their screen.

It’s not a huge task, but I think it had a pretty big effect. When I went undercover and attended my first swap meet it was really nice seeing everyone working together and given a reason to talk to each other, telling each other which symbols to press.

Speaking of symbols. They’ve been on a journey to reach the look and feel they had in the game:

The secret ingredient: The right users for the right game

“Collaboration gets you further in the game! (And in life!)”
– Robyn

All of these choices could have backfired or fallen flat. I’m used to designing products that help the user every step of the way. Usually, UX design is about making things easier, not mythical and difficult to understand. There is no rage like not understanding an app.

And even though there were frustrations and my heart goes out to players that fell through the cracks (I wish we had balanced it better for players in smaller cities for example) I was not prepared for the perfect match the values of the game aligned with the players. They took their kindness and went above and beyond.

Like all the winners who decided to give their +1 ticket to players they never met:

Or the players that shared codes to the rare artifacts to help other out:

This describes the experience very well (in Swedish), giving a shout out to all the kind swappers she met:

Thank you for the opportunity to be a part of this experience, Red Bull Music, Robyn and all of her fans <3

Lessons from making the server side to Red Bull Secret Gig X Robyn

So we made a game for Robyn and Red Bull. This is the first in a series of posts about this. Here we focus on the server side and outline some of the challenges we had.

Post nr 1: This post.
Post nr 2: The making of
Post nr 3: The design of…

While the game itself was a success, we did struggle with something we usually never struggle with – the server side. The nature of the campaign meant that we had huge traffic spikes, which in all honesty we were not prepared for.

Early in the project we decided to write the server side in NodeJS. We’d be hosting this at DigitalOcean, using their load balancer to spread the load round robin among n app servers. Since the campaign period only was ~3 weeks we decided to have a big single database server, running MongoDB.

DigitalOcean performed great. Their API’s and GUI’s for taking snapshots of app servers, and creating new droplets is easy and we could easily take servers in and out of rotation using their tag system. Even when they were doing network maintenance we just noted a tiny bit of latency. Something that could have become an issue was the internal network speed on the network. 1Gbps is not that much, and we we’re dangerously close (~800Mbps…) a few times. We would we have had to shard the database if the campaign had stretched for another week.

We ran our node processes via final-pm, and could run as many processes as we had cores on the appservers. This worked pretty great. All app servers sent their logs to Loggly, so we could follow everything in near real time.

All heavy lifting was offloaded to a couple of worker servers. They were running Agenda and handled achivements, sending push messages and calculate user score. They worked really hard every now and then, which is great, but we started adding some interval between queue jobs to give MongoDB some breathing room.

This is where we had some challenges.
First, we didn’t log slow queries on our production database. As the collections grew, response time went up. As there were no logs of this, we didn’t realize this as fast as we hoped. When enabled, the logs showed us that we were missing a few indexes, and when adding these the query time become much more stable.

Secondly, using an ORM is a very convenient way to make too many heavy queries and not seeing exactly what queries generates locks… after looking at the raw queries we were able to optimise these.

Thirdly, we did not stress test the API with the same kind of requests as the app did. Since the app updated user position every couple of seconds we had a lot of writes going on at the same time, generating locks.

Key learnings:

  • If you use an ORM, make sure you know what queries are being made.
  • Make sure to stress test the API with a script that mimics the actual client scenario.
  • Make the client handle a slowly responding API gracefully.
  • It takes a beta period for testing in order to get things perfect…

As always, it  feels sad taking down the cluster just when it performs at it’s peak. Which is now. Good bye cluster. You were great, at the end at least.

Skriv bättre commit-meddelanden med hjälp av Gittan

Jo, men för ett år sedan skrev vi överlag rätt dåliga commit-meddelanden. “Fix” och “Stuff” var inte helt ovanligt att läsa i historiken. Problemet med sådana meddelanden är att de inte ger nånting; att komma in som ny utvecklare i ett projekt fullt av “Fix” är minst sagt lite knepigt.

För att få alla att kollektivt skärpa sig skrev jag en liten slackbot som, på eftermiddagen varje dag, går igenom dagens aktivitet i våra aktiva projekt. Boten postar sedan ett av de meddelanden som är av perfekt längd till vår #kod-kanal.

Detta har fått oss att skriva mycket bättre commit-meddelanden på väldigt kort tid. Som nån sa: “det hjälper att man har ögonen på sig faktiskt”.

Koden ger inget att dela, vi kör ju CI-plattformen Buddy, och detta i princip bara en liten curlsnurra runt deras API. Att göra detta på GitHub eller BitBucket borde inte vara mer än några rader kod i valfritt språk.


📸 PushSnapper visualiserar utvecklingen av våra webbplatser

Vid utveckling av webbplatser gillar vi att få en visuell historik över sajtens utveckling. Allt från en första vit blank sida till en färdig sajt med logotyp, menu, content och (ibland) andra färger än vitt.

För att få denna historik har vi utvecklat ett eget verktyg vid namn 📸 PushSnapper.

En skärmdump vid varje deploy

Det hela är väldigt enkelt: varje gång en ny version av en sajt pushas ut så tas en skärmdump av sajten. Alla skärmdumpar sparas i en mapp på en server och när som helst kan vi plocka fram valfri skärmdump eller skapa en film av alla skärmdumpar. Det är kul att titta på, det är ett bra sätt att följa en sajts utveckling, och det kan säkerställa att inget oväntat skett på sajten. Så när någon frågor “när och hur och varför blev logotypen dubbelt så stor?!” så kan vi lätt se vilken dag och tidpunkt detta inträffade.

Såhär kan verktyget visa utvecklingen av en sajt. I detta fall har vi skärmdumpat hur sajten ser ut på en mindre skärm, typ en mobil:

Slår man ihop alla bilder ovan till en video blir det ungefär såhär (du måste kanske musa över videon och klicka play):


Så hur tar vi dumparna då?

Jo på Earth People använder vi ofta verktyget Buddy för att deploya kod. Buddy har en fiffig funktion vid namn Pipelines som gör att man kan utföra olika saker i olika steg vid en deploy. Sist bland dessa steg har vi lagt in vårt eget verktyg PushSnapper, en liten enkel node-snurra som i sin tur använder sig av Puppeteer.

Så varje gång en ny version av sajten läggs ut så tas en eller flera skärmdumpar. När man väl aktiverat skärmdumpningen så behöver man inte bry sig om att den sker. Förhoppningsvis glömmer man det och kommer på det sist i projektet när man vill ha en fin animation – eller när något går riktigt snett och man undrar exakt när det hände!

Det finns garanterat flera liknande verktyg – men det här är vårt eget verktyg skapat för våra behov. Och än så länge funkar det 💯.


Hämta hem ISRC-koder och annan matnyttig metadata du inte kan se i Spotify-appen.

Vi är ett antal individer på det här bygget som släppt ifrån oss musik i olika former. Jag själv började trevande med cdr-släpp med hemgjorda omslag, la ut musik i låg bitrate när MySpace-eran nådde zenit, för att gå vidare till “riktiga” cd-skivor, vinyler och de streamingtjänster som vid det här laget känns som de funnits för evigt.

Då det mest hela tiden skett på punknivå så har jag plockat på mig små bitar av oklar kunskap kring musikdistribution. Sådant det finns internationella standarder kring och professionella ägnar sig åt hela dagarna. Min icke-metod har lett till att mina tidigaste släpp gjorts under oklara former, där ingen av de inblandade vetat riktigt vad de hållit på med.

Med den inledningen ska jag komma till saken: Jag ska återutge en av mina första skivor, som från början gavs ut på cdr, och sedan släpptes digitalt. Den gavs ut av två olika skivbolag i nanostorlek, som båda somnat in sedan länge. För att kunna behålla de antal spelningar som skivan samlat på sig på Spotify behöver jag få fatt på de ISRC-koder som hänger ihop med låtarna.

Om jag gjort allt enligt konstens alla regler när det begav sig hade det varit EN kod prydligt kopplad till EN låt. Och allt hade registrerats hos IFPI i deras stora och lättillgängliga databas.

Men skivan släpptes utan koll på läget. Tur då att uppgifter om ISRC-koder finns tillgängliga i Spotifys API. Jag fick hjälp av Peder som byggde en enkel webbtjänst där man genom att klistra in länken till ett Spotify-album får fram all metadata som finns om låten, inklusive ISRC-koderna. Så nu har jag, förutom själva ISRC-koderna, fått reda på att låtarna visst råkat få dubbla uppsättningar av koder. Därför måste jag nu reda ut hur detta ska städas upp. En massa felstavad metadata är det också. Suck. Kan inte allt bara funka.


Gör en Spotifyplaylist från vilken sida som helst på hela Internet

En kanske gillar en del program på Sveriges Radio och en del musikbloggar. Dessa har massor med fina låtar listade, en och en, på sina websidor. Fantastiska playlists, förutom att de inte är just playlists utan bara låtlänkar. En vill inte sitta och klicka play låt efter låt utan ha detta i playlists istället.

Märkligt att det fortfarande saknades en enkel tjänst för detta. Så jag gjorde en snabb liten sajt som hjälper iallafall mig i min vardag. Använd om den passar ditt liv också.

Alla låtarnas interna Spotifylänkar presenteras, rakt upp och ner, i ett litet textfält. En illa dokumenterad feature i Spotifys desktopapp är att dessa kan pejstas rakt in i en playlist. Sjukt ju.

Inte så märkvärdigt, men känns bra att ha täppt igen det här glappet på Internet.

Hur man gör en användbar flamingo-badring till Roblox

Sommarpyssel för dig och din unge.

Det låter kanske kul men det är ett litet helvete. Fast jo, också kul.

Roblox är en spelplattform med en egen utvecklingsmiljö för publicering av egna spel. Det har funnits sedan 2006 men på senaste tiden har det ökat snabbt i popularitet och är enormt stort i den yngre målgruppen med 65 miljoner aktiva spelare varje månad.


  1. Modellera flamingon och exportera den som en .fbx-fil.
  2. Gör texturen och spara den i formatet png.
  3. Importera flamingo.fbx till Roblox Studio.
  4. Ladda upp texturen på som en decal och para ihop den med modellen.
  5. Scripta och tjafsa runt med positioner och fysikvärden i Roblox Studio.

Till dom första två stegen använder jag Blender och lite Photoshop men det går ju bra med valfri 3D-programvara och eventuell bildbehandlingsprogram.

3D-modellering i Blender
👆 Här gör jag själva 3D-modellen i Blender.

Roblox har en gräns på 5000 polygoner per mesh. Detta är ju en rätt simpel form men håll modellen så enkel som möjligt.
Gör man modellen 3 enheter stor i Blender och sätter scale till 0.01 när man exporterar som fbx så blir det en rimlig storlek när man tar in den i Roblox Studio.

👆 Texturen skissade jag upp med Texture Paint i Blender och snyggade till i Photoshop.

Det här kan man ju göra på lite olika sätt. Jag valde att snitta upp min pippi på det här viset. Hur man markerar sömmar och ritar textur i Blender tycker jag den här videon förklarar bra.

Spara ut den som en png och ladda upp den under Create > Decals på Då får du ett ID-nummer i urlen som du behöver klistra in som TextureId i Roblox Studio. Den måste inte vara modererad av Roblox för att använda i Studio. Dom är dock rätt snabba på att godkänna uppladdat material.

Att få in detta i Roblox Studio:

  • Öppna  Roblox Studio (ladda ner här).
  • Högerklicka på den gråa plattan på själva stagen och välj Insert Object > Meshpart
  • I properties-panelen – ändra klossens MeshId till din fbx-fil. Nu syns din flamingo!
  • Ändra material till Glass.
  • Kopiera in id-numret från decal-urlen i värdet till TextureId för att klä din mesh.

import to roblox

Om du testar spelet nu (F5 eller playknappen) så kan du inte greppa flamingon. I Roblox behöver man ett skapa ett objekt som heter Handle och placera det där karaktären ska greppa objektet. Man gör de två objekten till children av objektet Tool som finns beskrivet här. Tool är alltså till för redskap eller vapen egentligen. Jag följde den här beskrivningen för att få det att typ funka.

Genom att överdimensionera flamingon, placera handtaget på sniskan så att det ser ut som att man typ sitter på den istället för att hålla i den samt ändra fysikvärdena lyckades jag få den att agera som en användbar badring.

flamingo floatie


Roblox Studio är en lite frustrerande miljö och det är väldigt mycket testande fram och tillbaka. Men fan alltså, det är roligt och leder till nästan lika många skratt som sammanbrott. 10 av 10.

Hej då.


Typsnitt med flera lager?

Typsnitt med flera lager – layered fonts. Vad hände med det egentligen?  Det var ett par år sedan jag labbade med det sist. Och tekniken har ju funnits i flera år innan det. Det har funkat väldigt tillfredsställande att jobba med det i Glyphs men andra programvaror har fortfarande begränsad support. Glyphs är iofs en programvara för att skapa och editera fonter så kanske inte så konstigt att det funkat där. Men nu känns det som att det börjar bubbla lite kring detta.
Det finns lite olika tekniker för att få det att fungera i en browser. Jag är inte bäst på att förklara det. Men enkelt beskrivet delar man upp lagren till separata fonter och lägger ovanpå varandra. Hur man gör detta utan att kladda ner sin markup finns det flera artiklar om redan. Det finns en del välgjorda typsnitt färdiga att använda men så här gjorde jag mitt eget. Se det mer som inspiration än en tutorial.

👆Nu var jag ute efter en handtextad känsla så jag började med att skriva alla bokstäver med en fet Faber Castell Brush pen och kalkerade av dom i Illustrator. Jag är så van med Illustrator att jag hellre styr upp ankarpunkterna där och kopierar över till Glyphs.

👆Övriga lager, i det här fallet highlights och skugga+outlines designade jag direkt datan genom att utgå från baslagret. Totalt 3 lager alltså.

👆 Här är alla tre lager importerade i Glyphs. Väldigt tillfredsställande när man kan testa sina bokstäver med tangentbordet.

Men ok!

Vad ska man med detta till då. Halvbra fråga. Fel använt skulle ju detta få internet att bli riktigt jävla fult. Men i rätt doser och kombinationer i rätt sammanhang är det fan fint alltså. I det kontextet hoppas jag på att få se mer av detta.

Detta var enkelt beskrivet. Att skapa ett typsnitt med bara ett lager är rätt tidskrävande och sällan försvarbart ekonomiskt för separata projekt. Men ändå. Det finns ju färdiga som sagt och det kanske inte alltid behövs ett helt typsnitt. Jaja.

👇 Den här är ju förresten baserad på en variant av exemplet ovan men med lite andra lager.

Hej då.

Blipp Blopp för barn

Förra året gjorde vi ett kul sidoprojekt som inte nämnts här: Blipp Blopp för barn – som blev grammisnominerad som “Bästa barnalbum”!

Barn behöver roligare kultur, och vad är roligare än pruttande syntar, fula röstljud och robotdans. Blipp Blopp för barn är en elektronisk barnskiva släppt på vinyl och digitalt, Earth People har agerat skivbolag. Andreas gjorde omslagsballonger i 3d och grafisk design, EP-arna Tvärvägen och Beem har gjort varsin låt, och vi har engagerat en rad grymma elektroniska musiker som Daniel Savio, Lisa & Kroffe, Andreas Tilliander och även rapparen Rikard “Skizz” Bizzi – under hans alias Monolåg.

Skivan släpptes i April 2017. Vinylskivan säljs på olika skiv- och barnaffärer i Stockholm, samt per post. Den finns också på Spotify och liknande tjänster – Länk till skivan på Spotify.

Alla medverkande:
Daniel Savio, Lisa & Kroffe, Andreas Tilliander, Beem, Tvärvägen, Franka, Råd Kjetil Senza Testa, The Bird Who Fell to Earth (Carolina Guillén), Trauma Trauma (Frans Carlqvist) och Monolåg (Rikard Bizzi).

Tippa Fotbolls-VM i en chatbot

Nu drar Fotbolls-VM 2018 igång och vår bot i Facebook Messenger för 1×2-tippning som vi gjorde till Euro 2016 får nytt liv. Chat-plattformen passar definitivt inte allt, men här glänser den faktiskt som en liten diamant. Enkelheten att komma igång, utan att ladda ned något eller skapa ett konto, få en liten ping varje matchdag och snabbt tippa dagens matcher – perfekt.

När andra 1×2-tips ofta går ut på att fylla i alla 64 (!) matcher på ett bräde, utan att veta hur lagen känns, så blir detta lättsamt, härligt och engagerande under hela eventet. De på kontoret som inte ens är så intresserade av fotboll börjar titta på matcher och peppa igång på hur det gått för lagen.

Det går att skapa ligor där ens vänner tävlar mot varandra, och – het ny funktion för i år: kasta emojis på varandra i highscorelistan.

Testa nu medan VM pågår: