Creating a B2B centralised dashboard.
Background
The problem
At the moment, the app has so much information that people feel overwhelmed. Users can’t identify how they are doing across their domains. We got this data CS team, the product team, and speaking with the customers ourselves.
Main pain points
For getting any data, people need to wander around the app, click in different pages. If is the beginning of their journey, this is not easy.
At the moment, getting to share key info and progress needs some manual work. Automatise it would be a huge win.
For enterprise customers (with 1000+ domains) is difficult to have an overview.
The solution
Create an ‘at a glance’ dashboard where customers can see key items and overall status in one place. And then from there see where they need to go next.
Challenge:
Helping users to clearly see where they are and where they need to go.
The version needs to be an MVP, so Dev team can build it in one sprint.
Sector:
Cyber Security, Saas, Tech
Role:
Product design from research to conception.
It took around 4 weeks to be done and signed off.
The design process
Understanding the problem
For understanding better customer needs, I used different methods of research.
Interviewing through calls with CS.
Speaking with different customers, we saw favourite features, where they spend their time, things they missed… and what they would like to achieve within their company by having a dashboard.
Looking at the current data.
For tracking the data, we identified top events for the cohorts we were interested in. For doing this we used Mixpanel.
Creating user stories & hypothesis.
Once we have the numbers and the data, we won’t only create user stories. Also we’ll add reasons and ideate solutions. And we will set a baseline and define how success looks like.
Once we identify common needs and most popular pages, we will align them with the business needs. After we will prioritise features for a first MVP of the dashboard.
Ideation
In this phase, I set up some brainstorming sessions and invited the head of Product, some designers, and a member of CS and sales for their input. So we could gather as many ideas as possible.
After mapping out what could work in the dashboard, I drew some quick variants.
Wireframing
When doing the wireframes I like to cover interactions and as many edges cases as possible. So we can discuss with Dev team in an early stage and move quicker when we arrive to implementation.
In the first wireframes I covered:
1. How the dashboard looks like when the company has 1/Several/1000+ domains.
2. See progress through time.
3. What happens if the customer is in trial, and doesn't have any information to compare with just yet.
4. Highlighting critical information.
5. No new data after a period of time.
6. Empty status.
Validation
I discussed the sketches with Product, Dev, and stakeholders. We did a design review and commented on what worked and what needed to change. As you see, we love to put post-its all around.
This feedback helped shape the next iteration of the product.
Prototyping
Once the core structure is defined prototype is easy. I build reusing the components of our design library. If we don't have some new items, we will create them and add them for future design. In this case, prototyping has been made by using Sketch + InVision.
