Spearline is a SaaS company who specialise in producing monitoring and testing products in the telecommunication industry. My main focus on the product team was to redesign the platform and work on new feature requests. Being the first UX Designer in Spearline, I had a lot of discovery and research to conduct in the beginning.
This project was the redesign of the dashboards of the Voice Assure product. This product tests the connection and audio quality of business telephone numbers for telecoms departments of various industries such as pharmaceuticals, financials, contact centres and conference communication companies. The results of these tests appear on the dashboards. While the data is powerful, the dashboards are not user friendly, not intuitive and overall they are a very complex application.
The goal of this project was to:
1. Simplify the processes of creating and using a dashboard
2. Design intuitive and user friendly user flows
3. A clean, professional minimalist look and feel
4. More useful to the user
The current dashboards on the Spearline platform were found to be "clunky" to use and not user friendly. The predefined default dashboard was not being used by most users, however the analytics table was found to be very powerful but not a good experience to set up and extract the data.
Using data I collected in the discovery phase, I created several concepts and tested to finally arrive at a simple solution that allowed the user to customise their own dashboard from a library of chart widgets and refined the filters that made the dashboard viewport cleaner, functional and easier to use.
Methods used: Google Analytics, Hotjar recordings and heat maps, interviews, heuristic evaluation, reviewing marketing surveys, user flow diagrams, sketching concepts, user testing, wireframes, prototyping.
Looking at the analytics, the Dashboards are the landing page of the platform, however the charts are not useful to all users. About 60% use only some of the charts displayed, leaving the remainder to use the analytics table alone. While the analytics table was found to be extremely powerful, it was time consuming to set up and not clear where all the functions are.
I also looked at marketing surveys and discovered 13% of users mentioned the Dashboards needed improvements in the user experience.
I sent a questionnaire to the users to find out exactly what they were using the dashboards for and discovered they use it for a few purposes:
1. To get an overview of their performance
2. Monitor their own KPIs
3. Identify issues and trends
When asked about their dream dashboard, some of the users said:
1. Create comparative dashboard to compare data/metrics for any date ranges
2.Widgets for different chart criteria to drag and drop creating personalised dashboards on the default dash.
3. Trend analysis dash - quality drops & persistent issues
4. Maintain Analytics dashboards
5. Less clicks Easier clearing of data that is there
l evaluated the work flow of the dashboards. I asked users what exactly they did on the dashboards, what was their goals, what did they want to achieve?
I also observed users on Hotjar to find out what actions the users took, and what they were trying to achieve on the dashboards.
I made userflows in Moqups
Heatmaps in Hotjar showed me what and how users used the dashboards
Interviewing the users
Interviewing users is a crucial part of discovering their experience of the product and their pain points. I interviewed users of various technical ability with different goals and uses of the platform.
There are also persona groups who will use the platform with certain goals they need to achieve. However some of the same themes came up that overlapped the persona groups and those pain points would be used for requirements in the design phase.
Analysis of themes
The charts on the default dashboard are not useful
Currently the default predefined dashboard displays charts that are not useful to all users. They also do not provide a lot of insight. Most users don't use the default dashboard and rely more on the analytics data table. There are very few trends or anywhere to compare results to the previous week or month. A user has to export the data and find the trends using their own tools on their end. This is also true of the analytics data table, there is alot of raw data and users will either use an API or export the data and create their own insights and charts.
The filters were slow to load and also were fixed to the top of the dashboard, which meant that not all filters were used, but they were still displayed to the user. They took up quite a bit of real estate and looked very cluttered.
Also it was not indicated which filter was in use, there was nothing to tell the user. This caused alot of confusion and users were told to clear filters everytime they would log on and use the dashboards.
Some of the action buttons were hidden or just not conventional. The action button to add columns was not intuitive and used the hamburger menu icon.
A need to show the difference between Reporting and Operational dashboards. Reporting dashboards are set up to report to the user at a schedule they choose, for example daily, weekly or monthly. For consistent results reporting, the dashboard would not be changed. But according to some users, they forgot and mistakenly changed their view. They asked if there was a separate section for the Reporting dashboards or another way to distinguish them from their day to day Operational dashboard.
1. The dashboards will be customisable and be widget based with improved data visualisation in terms of better chart types to display the data.
2. To be able to easily compare data and easily see trends.
3. Be able to utilise appropriate filters and use conventional actions buttons.
4. To have a professional, clean and easy to use dashboard.
I initially sketched ideas and concepts to get a view on the hypothesis. I like to sketch first before I go to Figma. Its fast and I find my creativity flows with a pen and paper. I also use the sketches to get feedback from internal users. I got inspiration from alot of sources. I got free trials from a number of project management tools and BI Tools to find out how widgets are displayed, how they are added and deleted, what functions did they have that would be useful for the Spearline Dashboards. I also was inspired by Dribbble shots, Behance, Medium articles. I sketched various concepts and got feedback from developers and internal users to get early feedback.
I wrote user stories using the statement: As a user...I want to...so that...
As a user I want to see a snapshot of relevant data So that at a glance I can see how our numbers are performing.
As a user I want to quickly compare data to last month/week or between countries So that I know if our numbers are performing better or worse.
As a user I want to choose which data is dispalyed on our dashboard So that I can customise the dashboard to suit our companies specific interests.
As a user I want to save the layout of a custom dashboard So that I can easily revisit the dashboard or share it with others.
As a user I want to see outages in real time on a map So that I can easily monitor countrywide outages.
As a user I want to create reports from the dashboard So that I can share specific information with others.
As a user I want to set a default dashboard So that when I log in I have a consistent landing page.
As a user I want to see obvious indication of problems on the dashboard So that I dont think everything is ok when it isnt.
As a user I want to be able to lock a dashboard So that I can share it with others without fear of them changing the format.
Requirements and Documentation
I co-wrote the Product Requirements Document. This was a large document describing all the features, user flows and actions. All stakeholders including the executive team and the developers had access to this document. The main features and user flows are outlined below:
Features and user flows
1. Widgets - The data and chart types on the widgets and the actions on each widget
2. Dashboard layout - the dashboards were made to be more customisable and flexible. The user would be able to move, delete and add widgets to suit their needs
3. Create a new dashboard user flow- the old dashboards did not have a way to create a new dashboard but rather a user had to copy a dashboard and rename it.
4. Filters - all filters are behind one button and will allow the user to choose whichever filter they want and the user will easily see what filter they selected.
5. Improve functionality of the analytics data table - add and remove columns on data table and improve visibility and functionality.
Wireframing on Figma
This was a very iterative process. I made several concepts of the main features and user flows of the dashboard.
1. Widgets and 2. Dashboard layout
Speaking with the developers we decided on a scope and how many widgets could be displayed on a dashboard.
Data visualisation was an important part of the design of the widgets and what chart types would suit the data set. I studied the reports that were sent to the customers and I got free trials of BI tools (Business Intelligence tools) for inspiration.
I created basic charts on Google Sheets and a blank dashboard and asked users to create their perfect dashboard. A map, bar chart and data table featured in most of the users dream dashboard. This got me thinking that the customisable dashboard was an important feature. And resizing widgets would have to be a pre-requisite so that the user can make the dashboard more useful and useable. This was especially important as the dashboard would be exported to what was displayed on the screen. I ended up creating a small library of widgets. I put these into catagories - Charts, Map, Table and Statistics.
New dashboard with instructions and a drawer on the right with a list of widget categories
3. Create a new dashboard user flow
The old dashboard page didn't have a simple way to create a new dashboard. A user had to make changes on a current dashboard and then save and rename it. I introduced a 'Create a new dashboard' CTA. I went through a few iterations of what the user flow would look like, I created a few concepts including; a wizard with steps and choosing pre-made templates. The PM and developers decided it would be best for an MVP to make the process as simple as possible. So with many rounds of meetings and talks we decided on a drawer with a list of widgets for the user to choose from. Clicking on a widget, it would appear on the empty dashboard. The user had instructions on the empty dashboard also informing them what to do. They could resize and move the widgets to suit them.
New dashboard with instructions and a drawer on the right with a list of widget categories
When a widget is selected it appears on the dashboard, but is greyed out on the list as it can't be chosen twice
With big data and refining data, filters are an important feature of the dashboards, particularly for the data table which could have 70 + column filters, but in the old dashboards only about 12 filters were displayed on the page header, making the header page really cluttered, and also there was a second set of filters on the data table itself. Immediately I put all the filters behind one button. This allowed the user to build out whichever filter they wanted to see. Also with filter tags, the user could clearly see what was being filtered. Something the old dashboards lacked.
Clicking on the filter button will reveal a large menu of filter types
Most filters will have conditions built in, like this one for Country - 'Any of these' or 'None of these'.
When applied a filter tag will be displayed and a counter on each filter to show many filter types are selected.
5. Improve functionality of the analytics data table
One of the big issues with the data table was adding and removing columns. The button used was so hidden and many users would email customer support to ask where it was and how to add columns. I moved the button from the left to the right of the table and changed the icon to a plus. The order of the columns was also another tricky action, so with the team we came up with a much nicer and intuitive flow.
This was a big project and is soon to be released as a Beta version. I and the product team will be continuing user testing, after which, an agile approach will be taken and further releases will follow.
There was a lot of discussion and compromise on what the MVP would be and some great ideas did not make it into MVP and Beta (but this will be in the backlog for future releases) so I learned a lot about what can be achieved that is viable as a product but consider the cost to the development team, while also being the voice of the end user and they will experience the product.