Geckoboard Hack Week


For the first ever Geckoboard "Hack Week" we wanted to imagine a new way for our customers to interact with their TV dashboards.


Geckoboard customers are more successful when they choose to view dashboards on a TV screen, usually wall mounted in the office. Big screens are a great way to communicate, they mean your data is always visible and the data isn’t lost in the noise of email, slack etc. They are also non-interactive, which means that i'd often similar requests around the office.

“I quickly want to check a different dashboard”

“I need to share a dashboard with my team”

“Have you seen the MRR this month? It’s on the company dashboard”

For the first ever Geckoboard "Hack Week" we wanted to imagine a new way to interact with our TV dashboards.

clicker system

Hack week pitches

TV's use remotes, why can't Geckoboard?

I put together a proposal and formed a team of 3 engineers and myself. We kicked off the project with a quick design exercise. We used a “How might we” session to uncover concepts to potentially build. We sketched ideas for user journey’s, UI concepts and the technical approach. We had one week to build a product to demo to the rest of the company! Let's go!

clicker team at work


We agreed some experience goals early in the project, these would help keep us on track and focussed.

1. Behaves like a remote. The user's attention should be on the big screen when selecting dashboards, not the phone

2. Feels like a remote. Performance needs to feel responsive and latency free

3. Make use of gestural interactions

4. Be secure. The app should require a user to login - security is important to us and our customers


We understood how we used dashboards and TV screens but needed data to see how customer usage. After some digging we learnt a majority of customers have more dashboards than TV screens to display them on. Great! This means our tool could really help beyond our own use case.

User journey

I mapped out the user journey for the app. We’re dealing with interaction between to 2 different devices so we needed to make sure we understood the different states each device needed to handle and how they sync up. I wanted the app to feel super simple, so mapping out the entire app helped reveal where complexity could be reduced.

clicker system

Mapped out model for the product


I began designing and prototyping the app while the rest of the team worked on a technical proof of concept. Prototyping in parallel with engineers was a great way to discover constraints and opportunities as a team.

clicker app screens

Design exploration and prototyping using Sketch and Principle


After lots of learning through the prototyping I moved the designs to a higher fidelity and began working on the interaction design using Principle. I choose this tool as I was familiar with it and wanted to prototype the gestures and make the interactions feel right on the device. I new testing the app of a mobile device was going to be the only way to get a real sense of how well the design was working, Principle has a simple mirroring tool that allows for this. The rest of the team where making amazing progress on the backend and had moved from prototype to working with the real Geckoboard application.

Clicker prototype


I ran some hallway tests on the prototype iterating over the flow and tweaking gestures and making sure the login was useable. Based on feedback I added some lightweight onboarding to summarise the key benefits, this didn't make it into the demo as time was ticking away!

Demo of the final working version


In a week we managed to design and build a mobile web app to change a dashboard being displayed on a TV turning your mobile into a remote control. We presented the project on the Friday demoing the product and telling the story of it’s creation. Clicker won the hack week against some other incredible projects from the rest of the teams. We’re hoping to continue working on the project during our bi-weekly innovation time and to use it internally.