Building a widget
Widgets are the combination of a metric and data visualisation. They are the building blocks of customer dashboards and one of the key concepts in Geckoboard. This case study covers the design process taken to create our latest widget building experience.
Widgets make up dashboards designed for TV screens
Building a dashboard to keep your team motivated, informed and your business on track starts with the right metrics. Geckoboard connects to data sources via integrations. Integrations pull data directly from the services API allowing customers to build widgets to create dashboards.
1. We needed high quality integrations with more services
2. We needed the time and effort required to build this integrations to be drastically reduced
1. Our customers need access to the metrics that matter to their business
2. Our customers need depth and flexibility to tell the right story with their data
3. Our customers need useful metrics that are easy to setup
I had tackled similar problems design our Spreadsheets and Datasets widget builders, they are great for handling generic data but trade off a level of complexity. This project posed the challenge of still offering flexibility but with the opportunity to create a simpler experience.
Spreadsheets widget builder
Datasets widget builder
As one of two cross functional teams we had the ambitious goal of building a platform that re-thinks the way we bring data into Geckoboard affording the opportunity to design an experience that better meets our customers needs for discovering, creating and editing metrics.
A small team with a big task ahead we needed to prioritise a service and use cases to focus on part of the experience initially. Based on our learnings so far Zendesk was the service and taking a technical approach to solving the most pressing customer problem; lack of flexibility and configurability and using that to inform a simplified, more guided experience felt like the correct plan. This strategy also meant we could move quickly and reuse, extend and modify some existing components and design patterns. This would enable us to get a early version of the feature in the hands of customers and start to get feedback.
I was able to gain quick insights from our legacy solution. Our own customer support team and product managers already had a lot of feedback and requests from customers this helped to get a braod idea of the issues customers where facing.
Using intercom I could segment exisiting customer into two buckets. Those who'd had success with existing solution and those who'd failed to add a widget. I wanted to learn more about there approach to choosing metrics and thought’s about the experience. These early insights helped steer design exploration and guide the pain points to prioritise.
Designing such a complex and technical feature meant I knew I would benefit from lots of collaboration. So as well a lot of white boarding and sketching sessions I also ran workshops early in the process to get the team thinking about different aspects of the problem and aid my understanding of the technical approach.
I ran a sketching workshop (crazy 8’s) with a focus on quantity not quality of output. I wanted to get divergent ideas for the experience as well as giving others involved the opportunity to get their ideas out of their heads and down on paper and help get on the same page early in the project.
I ran a user journey session with engineers and product manager to explore different routes users could take to completing the desired goal, in this case creating a useful widget. This workshop was incredibly useful and gave me a greater understanding of the approach engineers planned to take in designing the system and gave them an insight into the way a user may interact with the system.
Using sketch and designing in low fidelity I was able to work through lots of design explorations quickly. Getting regular feedback was important so I’d catch up with a product manager or member of the frontend team daily when possible to discuss idea and whiteboard out further concepts or details of the user journey.
Early lo-fi prototypes were created using Atomic to communicate interaction design concepts by running them past user testers recruited from my early Intercom chats I was able to learn quickly which directions were worth pursuing further. This helped me simplify the configuration UI somewhat without trading off flexibility, but it was clear we’d need a simple way for customers create widgets for common metrics.
Example of a lo-fi prototype built using Atomic
I built high fidelity prototypes in HTML, CSS and JS. Over the course of many projects I had built out common UI elements in HTML and CSS which makes designing in code super quick and easy. Deisgning components and creating interfaces in the browser makes iterating over design details and micro-interactions quick and communication with frontend team much simpler. I used Github to handle the workflow and version control and published the prototypes using Github pages to share with the team.
Hi-fi protoypes for testing and implementation using HTML, CSS, JS
Roll out and feedback
We released the feature in milestones allowing us to built user testing and feedback into the cadence of shipping. This method of continous feedback not only helped inform the product but also helped us set success metrics for the project.
First release of the Zendesk integration
We'd broken ground on our most ambitous project yet, the result of the hard work menant we where able to release the next integration in a week. I hired a second designer to join the team and help us work on the next phase of the project focussing on user research, enabling us to explore even more opportunities. We're tracking well against success metrics and preparing the tackle more integrations.
Summary This is a quick run down of a ambitious and fast moving project. Things that have made this project a success:
- Setting up a method for continuous feedback via intercom chats and customer calls
- Rapid prototyping to get quick feedback on design directions, workflows and interaction design
- Opting to “build in the wild” releasing early and often meant meaningful feedback customers from the start
- Setting goals but checking in on assumptions and adjusting as we learnt more
- Having success metrics to measure the quantitative impact of the work we had shipped