Ecommerce Dashboard
Our product dashboard was outdated, complex, and impossible to navigate on mobile. My team and I built a new dashboard to provide a modern, simplified, mobile-friendly experience.
Overview | Design | Process | Screenshots
Overview | Design | Process | Screenshots
Overview
For enterprise clients, Eventgroove offers a private label version of its software so that organizations can present a fully branded experience to their own customers. The back-end management of these private label sites has always been handled by the Eventgroove team. The client would contact our team whenever they required any additions/changes. With a growing client base, this was becoming difficult to manage, and frustrating for some customers who didn’t want to wait for changes to be made. So, we decided to build a simplified version of our back-end software that could be client-facing.
Team
Product designer (myself), Developer
Design
As with all Eventgroove projects, we needed to work quickly, with a small team (myself and one developer). We agreed on a UI framework so we could bypass the prototype phase and the developer could build directly from my mockups and streamline our workflow. The internal dashboard we use is pretty utilitarian, and we figured anything would be a huge improvement design-wise over our current solution.
Process
I compiled a list of features, and created a diagram to visualize the current flow of creating, editing, and modifying a private label site. I then identified which features should be available for clients, and which features should be only available to the Eventgroove team, or applied automatically. Then, I provided mockups on how we should organize these features in the UI for clients. The developer and I continued to collaborate and iterate on the design as he was building.
When the basic dashboard was built, we did a series of demos for existing clients and other members of our team. We took their feedback, and created a list of ‘phase 2’ features, including urgency, time required, and estimated impact (how many customers would benefit from the feature). We then prioritized this list with our CEO and continued adding the features that we felt were required to launch.
Overview
For enterprise clients, Eventgroove offers a private label version of its software so that organizations can present a fully branded experience to their own customers. The back-end management of these private label sites has always been handled by the Eventgroove team. The client would contact our team whenever they required any additions/changes. With a growing client base, this was becoming difficult to manage, and frustrating for some customers who didn’t want to wait for changes to be made. So, we decided to build a simplified version of our back-end software that could be client-facing.
Team
Product designer (myself), Developer
Design
As with all Eventgroove projects, we needed to work quickly, with a small team (myself and one developer). We agreed on a UI framework so we could bypass the prototype phase and the developer could build directly from my mockups and streamline our workflow. The internal dashboard we use is pretty utilitarian, and we figured anything would be a huge improvement design-wise over our current solution.
Process
I compiled a list of features, and created a diagram to visualize the current flow of creating, editing, and modifying a private label site. I then identified which features should be available for clients, and which features should be only available to the Eventgroove team, or applied automatically. Then, I provided mockups on how we should organize these features in the UI for clients. The developer and I continued to collaborate and iterate on the design as he was building.
When the basic dashboard was built, we did a series of demos for existing clients and other members of our team. We took their feedback, and created a list of ‘phase 2’ features, including urgency, time required, and estimated impact (how many customers would benefit from the feature). We then prioritized this list with our CEO and continued adding the features that we felt were required to launch.
Screenshots
Here are some screenshots of the new dashboard. The first image in each section shows the old version of the page.
Home
We added an analytics overview, as well as some help resources to the homepage. When users initially log in, there is also a help video to guide them through their experience.
Storefronts
We simplified the storefronts page. Each storefront now has its own card, containing storefront settings, as well as links to other commonly used tools.
Products
Our assumption was that users’ primary focus was to purchase tickets. Especially if the user arrived from a social media channel, or some other online source, they likely have some basic information about the event already. So, we wanted to remove the clutter and point users toward their primary action right away.
Pages
Our assumption was that users’ primary focus was to purchase tickets. Especially if the user arrived from a social media channel, or some other online source, they likely have some basic information about the event already. So, we wanted to remove the clutter and point users toward their primary action right away.
Page Editing
Our assumption was that users’ primary focus was to purchase tickets. Especially if the user arrived from a social media channel, or some other online source, they likely have some basic information about the event already. So, we wanted to remove the clutter and point users toward their primary action right away.
Categories
Our assumption was that users’ primary focus was to purchase tickets. Especially if the user arrived from a social media channel, or some other online source, they likely have some basic information about the event already. So, we wanted to remove the clutter and point users toward their primary action right away.
Analytics
Our assumption was that users’ primary focus was to purchase tickets. Especially if the user arrived from a social media channel, or some other online source, they likely have some basic information about the event already. So, we wanted to remove the clutter and point users toward their primary action right away.
Account
Our assumption was that users’ primary focus was to purchase tickets. Especially if the user arrived from a social media channel, or some other online source, they likely have some basic information about the event already. So, we wanted to remove the clutter and point users toward their primary action right away.
Users
Our assumption was that users’ primary focus was to purchase tickets. Especially if the user arrived from a social media channel, or some other online source, they likely have some basic information about the event already. So, we wanted to remove the clutter and point users toward their primary action right away.
Takeaways
- Because we have a small team, we don’t often get the opportunity to go back and iterate on existing features. This was the first time we had the opportunity to re-build an existing product from scratch. While it can still use a lot of improvement, I can say it is a huge upgrade from the previous version. We still have the old dashboard for internal use (there are still more advanced features that haven’t been built into the new dashboard yet). But, I still use the new dashboard whenever I can because it is so much more lightweight and intuitive.
- Since we launched the new dashboard, 100% of new private label sites have been created using this tool. This represents 30% of all private label sites in our system. It has been a huge weight lifted off of our team internally, and organizations are now empowered to make their own changes, and gather their own reporting.
Want to see a demo?
I created a demo video for this product. You can watch it here.
