UI shown on multiple devices
Interactive Check-in Wall
App Design

Keep attendance taking, interactive and fun.

We designed and built alongside a remote tech team, an interactive module for users registering on-site and virtually to collectively login and help in a mission to unveil a graphic underneath. Best viewed on a massive LED wall on stage.

For this project, it was first set in motion by a very high-profile client. They reached out to us to come up with something unique and perhaps something that kept users engaged as they logged their attendance on-site. We had to put our thinking caps on and come up with creative ideas using as much of the venue's equipment as possible.

Client

Non-Disclosable

Skills Used

Ideation, Design, Planning, Execution

Tools

Angular JS, Firebase RTDB, AWS

Project Timeline

3 Weeks

How this came about?

The company I consult for, has a working relationship with a very high-profile client, which I am tied to an NDA to not reveal their identities. The clients were a fun bunch to work with, but they had a zero-room for error policy.

Everything had to go right to the plan, with very little to no deviations. In such a working relationship, unless I am coding the platform on my own and I have full understanding of how it was technically implemented, it is always a risk taking on such jobs.

Considering their deadline, we had 2 weeks including ideation, planning, design and execution. After initial contact was made, we got to work on what we were actually going to build.

High-profile clients, come with higher risks.

My assumption is that every business owner wants to deliver only their best work when working with their clients. But, when working in tight deadlines, and needing it to be 100% flawless, it comes with some high level risks that you are undertaking.

Ideation alone takes a long time to be confirmed, only because all involved stakeholders will have different ideas in their minds. To gather the requirements and come down to a general consensus, is where my skill comes in.

We had 2-3 meetings where it was just us throwing every idea at the wall, to get the client to agree working on such a project. At kick off, we never really had an idea how we were going to approach this.

Research & Analysis.

In any physical event, there are a number of components we use. These days, the LED walls seem to be popular, where the backdrop of the stage is usually retrofitted with a panel of LED screens that allows for dynamic content to be displayed for your audience.

We also gave some thought for what is the end goal we were trying to attain? The target audience that were showing up, were also not too tech savvy and highly-private individuals, who would not want to disclose too much information on such platforms.

The idea was simple, we needed to have the audience register their attendance, and be involved as the seats were being filled up, as opposed to just sitting down and waiting for the show to begin.

Interactive elements are great. But, it has to be built for the specific type of people that are going to use it.

Almost sounds like a no brainer does it not? But it is not the easiest task to get serious users, to do something, for fun. Imagine having people turn up to a black-tie event and being asked to partake in a game of truth or dare.

The product was meant to be a one-off thing. No user information is collected, nor is it processed in any shape or form. The client might not ever use that again as it was meant to be the wow-factor for that one event.

We made it clear that this is a product we are building within our eco-system of solutions and is not a proprietary ownership of theirs.

After much discussion, I proposed a very simple game, by covering the whole LED panels, with a Key Visual that they would like to unveil at the arrival of the Guest-of-Honour. We will cover them up with thousands of tiles, and each user’s sign in, triggers x number of tiles to drop, that slowly starts to unveil what is underneath.

When the Guest-of-Honour arrives, his one sign-in would cause all the other tiles to start dropping, in a myriad of colours, and then the Key Visual that shows up, is animated and brought to life.

Design.

Building a mobile or even a web app is pretty straight forward when it comes to making its resolutions adaptable. But, when we are building for a huge LED wall, to show the game in its full glory, was a challenge.

To top that of, the refresh rates had to be considered as well. On our screens, it demoed perfectly well, but when scaled up, somehow, there was some unexpected behaviours.

Designing such systems is almost second-nature to me. Building things is a passion, and doing it for others also brings a joy.

Because design is my primary trait, I can get fully immersed and come up with great mock-ups ready for production in short spans of time. But that is also because I spend sleepless nights at a stretch to ship it in that time.

It had to be simple. It had to have a wow-effect and it had to keep users engaged in some way or another without doing much from their end at all. Keeping privacy in mind, people did not openly trust every site that required any form of personal information.

My first few mock-ups started being sent for reviews. Little did I know that working with such organisations, will require multiple back and forth. Honestly, that was not accounted in the timing to execute.

As soon as the green light came, though it felt like it took forever, I shipped the first few screens out to the devs. All the use cases, edge cases and every known combinations was documented for them to easily follow.

Development.

There was some backend panel necessary to manage things like the speed, the number of tiles dropped per sign in, etc. It need not be mobile optimised, so we got that out of the way first. But as I work with good developers, they actually built a really quick prototype almost immediately to see if the idea was feasible.

Starting with the dashboard also made more sense, considering we can manage the mechanics of the game right off the bat. My next immediate step was to ship out the first screen users see. Remember, least input, but just enough to feel engaged with what is happening on the screen.

Landing page with a dialog opened, requesting for their names only. We assign a coloured tile to you and let you know to watch the big screen to see your contribution to the event by signing in. 2 simple screens which upon dismissal does not require you to do anything more.

Animations can be eye-catching, but can behave vastly different on processors, browsers, etc.

When there are many stakeholders, the moving parameters are aplenty. By allowing such controls to exist, we can actually see different behaviours when using any JS libraries to get some nice animations underway. Most were not able to remain consistent during the QA.

Having done the quick prototype, it afforded me time to find other alternatives to achieve the very effect we were going for. Developers can get firm when it comes to making choices regarding the implementation. But if you let them know why you would like to try other packages, you at least stand a 50% chance they would see where you are coming from.

Being the big clients they were, rehearsals were done 3 consecutive days in advance, and having reviewed the product about a week prior. This was some serious deadline, but we powered through and were able to pull it off at the nick of time.

Ship to customer and their reaction

The rehearsals these clients hold are as real as it gets. Some times even more nerve wrecking, because tempers and emotions are flying high and every mistake seems excruciating. The first run, as we began the game, everything went smoothly as we expected (because of the multiple tests done by the QA).

During the second rehearsal, we were asked to amend some parameters, for some contingency plans. The instructions were coming from a few places, and that made it rather difficult to nail down a specific set of parameters to serve an estimated x number of pax.

Always have your guard up during a demo, it’s the easiest time to catch you with your pants down.

Every product demo no matter how flawlessly it has been implemented, in my opinion, always has potential to behave unexpectedly. Be it a code error, or something as random as a power outage to the computer running it.

The parameters kept shifting, and the more we tweaked, the more we started noticing differences in the expected behaviour. Turns out, each time we re-ran the app on the Chrome browser, it was just piling up on the memory usage.

Even till the actual day of the event, they kept shifting the numbers, trying to eye-ball what is the turn out and deciding from there. In the end, as the GOH arrived slightly earlier than expected, they rushed through the game and cut to a video playback of the game that was simulated.

It kinda hurt to see it play out that way. But, even though it was not on screen for the audience to see, I could actually see it from my end that it worked and played exactly the way I had expected it to. It was such a shame it did not get its 15 minutes of fame.

No items found.

Let's build your next big project together.

Dare to dream? We dare to build.
Hit me up