Astrato is a business intelligence solution that helps Data Analysts model data and design live data dashboards. The company’s goal is to put visualization first, helping users create fully customizable dashboard designs in a quick and easy way without requiring coding skills.
My role & the team
I am the lead Senior Product Designer working together with the Workbook Editor team and am responsible for the dashboard creation area. This includes 5 Developers, 2 Quality Assurance specialists, and 1 Product Manager.
Other designers would also be involved into discussions since some of the features could touch their design area.
The problem
Existing tools require users to know how to code to create interactive flows within their dashboards. This does not align with the company’s goal of creating simple solutions for all users in the BI industry. From the user's perspective, many BI-related users do not have the time to learn languages such as SQL. With this in mind, we started by defining a How Might We statement:
HMW create a no-code experience solution that allows users without coding skills to create complex dashboards with smart interactivity and logic.
Initial research
A great reference we found in our research was Scratch, an online platform that uses building blocks to teach children coding logic. From a design and business point of view, implementing something like this could be beneficial and definitely solve the problem. After an initial conversation between the Product Manager and me, one of the developers started working on a POC. In the meantime, the Product Manager and I continued to define the user needs and initial features.
The actions a user can perform can be divided into two different categories: Analytic actions and Interactive actions. Analytic actions are used to perform visual changes to the data representation, while Interactive actions modify the sheet or navigation. However, they are not mutually exclusive, as they can be performed in a sequence.
The Interactive actions should be defined as their own entity so that they can be used and reused in all parts of the application, not tied to a specific object. This would make it possible to enhance the experience anywhere in a workbook.
The second step was to reach out to BI developers we had in-house to get some input on what could be the basic features. The main features mentioned were:
-
Button
-
Navigating between sheets
-
Logic
-
Show/hide objects
-
Onboarding
From there, the Product Manager and I created some user stories and defined possible flows.
Usability tests with in-house users using a High-fidelity prototype
From the brainstorming sessions made with the PM and developers, I was able to answer business and technical questions. After that, I designed a high fidelity prototype and defined rough categories of the possible actions to test our initial MVP.
Again we reached out to our internal BI developers because at that point we didn't have many customers (a more detailed test was done with real users using our development environment a few months later).
Two different tasks were asked. To help with development and documentation, we put them into user stories:
"As a dashboard creator, I want viewers to be able to click on a button to navigate to another sheet."
"As a dashboard creator, I want viewers to be able to hide and show an object."
All users managed to finish the first task easily with some minor observations.
Block shapes can be sometimes confusing. Some users were not sure if the action would work since their last block didn't look like a final one.
All users found the starting point but some were confused with the 2 ways of doing it.
None of the users managed to finish the second task.
Users were confused with the fact that they would have to use variables for such a simple and common task. Most were looking for the words "hide" and "show" in the blocks list.
I documented and presented the main takeaways to the development and design team.
First interaction
After that initial test, we decided to go for what was working and tweak a little bit what wasn't. So the initial release date was set.
To help developers and QA, I wrote a detailed documentation explaining block formats, behaviors, and other necessary components to help with the process.
After a few sprints and a lot of solved bugs, we released the first version of the Actions feature. Now it was time to test the feature with real users.
Usability tests with real users in a development environment
5 users performed the usability test, they had 2 tasks, similar to the one tested in the first stage. They all understood the concept and what we are trying to achieve with the Actions feature. However, again we saw a problem when using variables for simple actions such as hide/show objects even with the small UI improvements.
General insights were collected and shared with both the development and design team:
From that we identified some opportunities. Some were easy fixes others need more thinking since it could affect other teams and/or technical difficulties.
Quick wins
Small improvements we could do based on the received feedback.
Bigger topics
Larger improvements we could do based on the received feedback.
Quick view of the UI
Not all the ideas ended up in the design and not all designs will end up in the final version, but below there is a rough idea of how the feature should behave and look like.
Final thoughts
This is still an ongoing project that I have the pleasure to be part of it.
Currently, we are focusing on the logic category as it is one of the most requested actions from our users. Introducing a new concept to a well-defined feature in the business intelligence (BI) world has not been an easy task. Nevertheless, we have received positive feedback from users who previously had to outsource the creation of actions in their data dashboards, and that has been gratifying.
