REDBULL SECRET GIG X ROBYN DESIGN – The strange and wonderful path that took us to the final look and feel

So we made a game for Robyn and Red Bull Music. This is the third post in a series of posts about this. Here our Designer Viktor talks about adding artwork to the app.

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

 

Step 1: Interpretation of a Mood Board

So, first things first, we did not have much to go on when the design process started. Or let me rephrase that, we had A LOT to go on, but it was a 30 page long mood board for the stage design of Robyns tour, which was also put together by a whole range of different people. I took some parts of it (the left half of the image below, which turned out to be the wrong half) that felt like they would merge together quite well and got to work on creating a look that could support the simple UI elements and the overall secretive feeling we wanted the app to convey.

(not the actual moodboard)

 

Step 2: Designing the first look of the app

This is the first game board version, this is just a personal process but I like the idea of making the first draft of something as much as it can be and then scale down/remove stuff rather than the opposite way of adding stuff as you go along. The trade board was originally supposed to act like a radar so you could turn your phone and easily find people to swap with. Turns out (golfclap) almost no phones have the ability to do this in a good way, their favorite thing in the world is to to mindlessly spin around and point out west as north and so on. In retrospect this would neither have been needed since the players where awesome at organizing swap-meets!


A very early version of the achievement tab, it is always folded down over the current view so I wanted to experiment with a cut-out effect since video would be playing in the background.

 

Step 3: Design technology

I don’t know if this a broadly used terminology but in my experience it’s well worth spending a couple of hours on. Let me explain: one big challenge in this project was that we needed to test a lot of technical stuff as well as performance at the same time. What this means is that we had to have graphics from the get go that would change as little as possible. ‘Change as little as possible’ meant that we decided to render the app in 3 layers (simplified) one big animated background, one layer for ui elements, such as buttons, positions, well almost everything and last but not least, achievements as the third layer.
We also decided that we would use transparent pngs for all elements except text and backgrounds (video and or animated gifs) and that the transparent bounding boxes of the pngs would act as margins for layout purposes. This enabled us to update the entire look of the app without rewriting code each time. I set up all the assets as linked PSDs and arranged them in a couple of master files, one for each view in the app. So when feedback arrived I did not even had to work in any of the master files, I could update each asset on an individual basis and only really open master files for when the overall design was to be reviewed. I could also just replace files and they would almost automatically arrive in the app and update the whole look.

This might sound as small details but it enabled me to detach myself from developer deadlines and it made sure that the developers would not have to fear design feedback or changes, and we knew that we would have to make a lot of versions of the graphics since Robyn was working on artwork for both the first single, the album and the set design at the same time as we where building the app. All in all it made design a less stressful experience for all of us involved.

 

Step 4: Updated moodboard from Robyn

Robyns team got closer and closer to finished album artwork and the stage design so we finally had something to align the app against. So the first step was to tone down the crazy colors and achieve a more subtle feeling.

First draft of the game board was too much full on Miami 80s and the achievement notification REALLY went full on 80s! The third view of the game board is where we locked almost all elements and more or less only played with the colors up to the final version.

 

Step 5: Final colors for the album and a custom made Font

We got the final color scheme in the form of  5, 2 part color combinations and I thought: “wow those are some bold color combinations for an app, let’s do this, 100% throttle” and the result was, well let’s say it looked bold…

Game board & Achievements in extreme colors.

 

Step 6: The symbols

The symbols had a rather organic evolution, they started out in an asian calligraphy world, loosely tied to the name of Robyns label, Konichiwa, they however never felt right. They then went into something best described as computer OS icons, then to retro game, then to impossible stone shapes. When they where shown to Robyn she came up with a list of artifacts she felt would represent her and the album. In that moment they also changed name from pieces to artifacts. So in order of birth, here they are:

Evolution of the trade & unlock symbols.

First selection of artifacts to the final codes!

 

Step 7: Killing your darlings because of performance 🙁

Initially each and every single view of the app was supposed to have an animated background. We wanted to have this because the UI itself has little or no animation or visual feedback (you click a button on the home screen and go to another screen) and it would be the most effective way to bring the app to life and give it a sense of flow and dynamic. We hung on to the idea a long time but in the end it was too much of a risk performance wise to have anything interfere with the swap view. If the experience of swapping was slow the whole core and integrity of the app would be in jeopardy and we really, really wanted people to share artifacts with each other!

 

Step 8: The final product!

Step 9: Be really happy that you got to be a part of this!

Thank you Red Bull and Robyn for making this really fun and rewarding, I’ll repeat what the previous post about this project concluded: If you ever get the chance to make something for Robyn’s fans, take it.

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 (openstreetmap.org)

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
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.

NodeJS
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.

Workers
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.

MongoDB
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.