By creating an efficient, effective portal for dealers, UnaliWear hopes to increase their independence in onboarding "wearers" to whom they sell the Kanega Watch. The efficacy of this portal will help UnaliWear manage watch data uniformly and aid UnaliWear support technicians in finding quicker solutions.
The current dealer portal involves a workflow that is inefficient, redundant, and lacks usability. It currently takes over an hour to assign a watch to a wearer and the process is not intuitive.
Create a dealer portal with a simple, streamlined workflow so that dealers can effectively and efficiently minimize their workload. This creates less dependency on UnaliWear, allowing them to focus on innovating new features for the Kanega Watch.
As a part of the scrum method, each member of our team thought of different users and what they need to accomplish by using the dealer portal. We focused on customer support technicians and sales technicians, and based on their desires created an affinity map. We then wrote a sentence summarizing each affinity, which helped us in developing a taxonomy and moving towards card sorting. Each team member then dot-voted on the user stories they thought were most important, and we prioritized them in Trello based on the votes.
Because the watch is currently still in beta, there were not any dealers using the current portal whom we could interview. Luckily, we were able to interview two employees of UnaliWear who are very familiar with the current portal and its pain points. This interview, along with our project brief, helped us further in developing features and categories for the dealer portal.
Chintan and I created two proto-personas as potential users of the dealer portal. One is a support technician and the other is a sales technician. Because this portal can be used by dealers and also those helping troubleshoot watch issues, we felt that these personas exemplified people who would use the portal.
Once we determined the necessary features for the dealer portal (wearer setup, wearer onboarding, issue backlog management, watch status), we needed to organize them taxonomically. Together, we organized them into categories which we named “Wearers”, “Watches”, and “Support”.
Erin and I then separately spent some time sketching different ideas for page layouts. As a team, we reconvened and jumped to the whiteboard, where we collectively decided how the home dashboard layout should be organized.
I sketched low fidelity screens that could be used in a paper prototype, which was one of UnaliWear’s requested deliverables. We had an insightful meeting with the UnaliWear team, in which they suggested a few minor changes, but ultimately they were pleased with our progress thus far.
Our first round of user testing was done with a paper prototype. We had seen other videos of interactive paper prototypes, and thoroughly enjoyed creating our own.
Chintan created this amazing site map and process flow, which solidified our hierarchy and taxonomy and was a great reference for building our clickable prototype.
Erin and I created mid fidelity wireframes in Sketch based on our drawings from the design studio and those I’d done for the paper prototype.
Our next round of testing was done after we created a clickable prototype in InVision. Users succeeded in completing most tasks, and we took note of the tasks that were difficult to improve in our next iteration.
Our second iteration of the prototype included changes from our first tests and was based on feedback from another meeting with the UnaliWear team. These changes made the prototype more easy to navigate and even more efficient. By having an open line of communication with the UnaliWear team, we were able to rapdily iterate. Our designs and ideation process helped to illuminate issues with the onboarding process that the team had not previously considered.
This is a video of our clickable prototype, which allows the user to add a new wearer and input their information, assign a watch to them, view their profile, edit items directly on the page, search for a wearer, onboard the wearer, and temporarily disable monitoring.
Another deliverable for this project was a high resolution mockup. Our brief provided us with a basic style guide, including typefaces and color schemes consistent with the existing UnaliWear website. Another desirable design element was to implement Google’s material design concept. Erin and I experimented with different aspects of the style guide until we reached a solid mockup.
During our meetings, the UnaliWear team thought it would be good to have some data visualizations on the watches dashboard. This way a dealer can see the status of assigned watches, battery health, watches being monitored, and overall status of watches in the field.
Ultimately, we created a portal for dealers that drastically streamlines the process of assigning watches to their respective wearers. We did this by reducing the amount of steps it takes to add wearer information, assign a watch, enable and disable monitoring and onboarding.
This project was a great success. The UnaliWear team was pleased with the work we were able to accomplish in three weeks, and hopefully will be implementing our design ideas as they continue to move toward selling the Kanega Watch to dealers.
Given more time on this project, I would like to explore material design more in depth, and be able to create more process flows with the features we’ve put in place. There are quite a few more workflows that could be developed, like inventory monitoring, active watch monitoring and backlog management.