In 2017, Sioux Group wanted to launch a new product at the market. We wanted to construct an educational gamified platform, where companies could teach their employees the skills they want them to have with an immersive and gamified experience.

Some screens of the User Interface

The challenge

Our goal for the project was to create a framework that could be used by many companies from different business. It would have to be usable by all people: from those working at the telemarketing to directors with bigger influence.

From our starting point, we already had some projects working that way, but with no defined patterns. This used to cause a re-work every time a project with the same goals started.

Knowing this, our primary goals were:

  1. Create a modular platform that could be easily customizable, according to the client.
  2. Easy-to-use and intuitive enough even to the most beginner digital user.
  3. Finish the main structure in one week.
Me running a usability test with a paper prototype on a grocery store

My role

I was part of a team of four: stakeholder, project manager, developer and ux designer (me). We worked on a "war room" for one week in order to finish the tasks quickly.

When the idea of a war room came out, we had no idea of how could we work together to have the best result in just one week. Actually, we didn't even know what we could deliver with this deadline.

Because of this, on the first day I suggested a few things to the team:

  1. It was impossible for us to deliver more than wireframes of the key interactions.
  2. We should run a quick usability test to validate our ideas.
  3. Probably the best way to do these things was running a design sprint.

The process

As we needed to have a solid wireframe of almost an entire platform at the end of the week, I had to shorten our sprint for just three days, so I could work on adjusting the wireframes on Thursday and Friday. The good news was that the project manager agreed with all of my ideas about the process. Process defined, we should start working.

day 1: understand and diverge. day 2: decide and prototype. day 3: validate. days 4 and 5: construct.
Ok, maybe Google wouldn't be proud about this. But it fitted our needs.

Day 1

We used the first day to understand all the scope. On this day, besides the people who would work on the war room, there were some other stakeholders, too. We did this because on the ideation part of the process it was very important that everybody understood the mainly possible features that we could use.

As there were already some projects using the platform we wanted to create (but each one with its particularity), we collected all the information we had to put the things together. Our job was to create a framework that could be used for every client, so we needed to know all the features to define which ones we should include at the MVP. After choosing those features, we wrote down into post-its some project assumptions that were important for us to consider. Those assumptions we glued to the wall, because they were our guide on the rest of the project.

Actually, on our "diverge" step, we didn't draw anything at all. Mainly because of lack of time, but also because we discussed those features all day long and everything was fresh on our minds.

At the end of the day, I created a simplified information architecture, that I used the next day with the team to define which tasks we were going to validate after constructing the prototype.

One paper with project assumptions written down on post-its glued. Beside this paper, there is another one with a simplified user flow on it.
Project assumptions and information architecture glued on our wall.

Day 2

We started the second day with one thing in mind: at the end of the day, we needed to have a paper prototype for us to test on day 3. To achieve this, the early morning was our final moment to decide which features we would add or remove from the ones we chose the day before. Beside this, we defined which flows we wanted to validate, with that information architecture that I made on day 1.

Features and flows to validate defined, the job went direct to me. On the rest of the day I was basically drawing, erasing and showing those draws to the team. As we had already defined which flows we wanted to test, I didn't had to draw every single screen of the app, but only the important ones to the prototype.

Some screens drawed on paper
Sometimes paper and pencil are the best tools for fast sketches :)

To make the prototype, I used Marvel. I chose this software because I could only take some pictures of my drawings and make relationships between them to create a navigable prototype. As I had said, I created the prototype just with the flows I wanted to test.

Paper prototype made to the usability testing

Day 3

Finally, we had a prototype to validate with people. And it was the main task of day 3. Basically, as our product was aimed to everybody, we decided to test it with different sorts of people. We did some internal tests first, with people on different positions at the company. Then, we went to some stores on the streets around to make a guerrilla usability testing with salespeople. The tests were made by me and my manager. I conducted the tests and he was helping me with the recording.

When lunchtime arrived, we had done the six tests we wanted to do. All of them were quick ones (we didn't want to disturb people at office hours). The rest of the day I spent resolving technical problems (the file recordings were huge to upload) and compiling the results.

Man during a usability testing session, with a smartphone on his hand. On the screen, there is the platform's prototype.
One of the participants using our prototype

To compile the results, I wrote down the tasks into one spreadsheet and classified them according to the way the participants have done it. There were three possible classifications: success, done with difficult and failure. Beside the result, I wrote the action the user had on that task.

Image of the spreadsheet with the results blurred
Sorry for the blur, but I can't show you the results. Let your imagination work a little bit.

Day 4/day 5

Following the schedule, we would use the last two days to do the platform's wireframe, considering the insights we had during the week. On the first day, I realized it would be impossible to do all the screens, so, we put together all the stakeholders with us to decide the main screens to priorize on that pack.

I made this one with Adobe XD

Time for visual

On the next week, I could focus on the interface. The main point there was to assure that the platform could be easily customizable to each client, just changing colors, fonts and content.

As the structure was already defined, we could spent more time thinking only about the visual aspects.

As there were lots of rules about what could be customizable according to the client, we decided to create a styleguide to help developers and clients to understand what they could change to their companies.

Screens being explained on the styleguide
A document explaining all the details is important, sometimes

Leassons learned

As life is not that easy, I learned many things that haven't gone so well on this project. Probably the main one was that things will not work the way you planned, especially if it is the first time you're doing that thing. And it's ok, if you realize that there were some mistakes on the road.

Being alert about the technical part is another good lesson. During the first usability test, the smartphone that we were using to record ran out of battery. We had to continue without the recording, which caused some doubts after, when I was compiling the results.


I think that the coolest part of the project was that we started the week without any expectation about what we could deliver or how we could deliver something and we ended up with an amazing experience and a validated wireframe that made it possible to create a great interface after.

That only could be done because we decided to create things quickly, before being sure of something. Prototype to test it first, and then improve it faster. The result can be surprisingly positive.

Learn more at ludospro.com.br.

Other projects

illustration of the Farol Santander building

Farol Santander

Recreating the history.

illustration of some Santander Academics Game's screens

Academicxs II

Taking students abroad.