One of the first items to tackle for this project (and in my opinion, should be for all projects) were creating the wireframes. To do this, I first needed an understanding of what the applications goals were. I sat with the owner and nailed down the business requirements and functional specifications.
During the initial phase of development we were working with an outsourced team, of which were all remote. Clearly written requirements, specifications, detailed wireframes and a functional prototype were paramount to the success of the application.
The application is made up of sections. Upon login the user would go to his dashboard. From there the user could then go to any parent section of the site in one click along with the ability to go to “create new” reports, gauges, and datasets via their respected builder. In addition, the user settings were an important part of the build. Users needed to have the ability to invite other team members, share reports with each other and not so common actions like update their billing terms.
IT ALL STARTS AT THE DASHBOARD
As is the case with most dashboards, users should be able to get vital information and be able to easily launch tasks from the dashboard. BrightGauge’s dashboard is no different. When I started this project I had a blank slate to design. Based on user and industry research that I conducted I was able to drill in to the data that was most valuable to our users.
Dashboard
Widgetized, customizable, dynamically populated with easy action buttons
Manage Clients
Top level view of all of the MSP’s clients with prominent health score card rating
Client Overview
Dashboard view for each particular client with important data displayed
Notifications
We wanted to make sure the MSP always had a way to back out of an action
Client Gauges
Allows the MSP to only show the gauges they want to show
Account Details
The MSP needed to be able to manage their BrightGauge administratively.
Connectivity Alerts
An easy way for BrightGauge to tell the MSP their connectivity was down
Client Files
This is the internal CMS for all client files, and all files for all clients.
Branding
I wanted the MSP to be able to brand their portal to have their look and feel
Manage Team
Allow the MSP to add/edit/delete team members and set their permissions
ONBOARDING
My typical process upon starting any new project would have been user research. As I mentioned above, there was already a beta version of the tool that met the needs of the application, but there were a lot of pieces that needed refinement. So I began with the users first step, Sign-up & Onboarding.
