While on this team, I mainly focused on building user interfaces for IT customers to manage their business devices, known as a Device Management Platform(DMP). Below are notable projects that I led from requirements to developer handoff.
Client
Major Telecommunications Retailer
Role
UX/UI Designer
Time
3 Months
Team
Steph, Rae
Disclaimer: Screens have been altered to maintain confidentiality.
User Story
How might we allow user to organize their company devices so that they can apply settings in bulk instead of individually?
Considerations
User needs
We considered how user might want to group their devices and where they were most likely to do this. We wanted to ensure that the placement fit with the mental model users had of the platform.
Business needs
We considered how the grouping functionality would be best leveraged for the business. So, we considered what other future functionality might be added on to the grouping function, and that we should design with that in mind.
Current state
Device inventory page
The best place for grouping devices would be on the device inventory page, where all device actions are kept. So, this is where we looked to add in grouping functionality.
Grouping devices
Ideation
We explored how the grouping function would surface on the device inventory page, as well as what the user flows would look like from different entry points.
We did a ton of explorations around the best way to allow users to group devices easily but also where they would expect it. Future features could also benefit from the added functionality since we would have a blueprint to work from. Most of the ideation done consisted of short design snippets that proved or disapproved a direction as valuable and feasible.
Potential solution
Action dropdown
One of the more flushed out solutions, this would allow users to select devices, choose an action in the dropdown menu and then the action would be applied to the devices chosen. In this instance a group modal dialog appears for selecting a group to add devices into.
Pros
Allows for future actions to be easily added.
All the actions are visible at once, instead oftruncated.
Cons
Terminology may be foreign to newer users (Action, app, etc).
User Flow
1. Action dropdown
Page
Device Inventory Page
Description
User selects the device(s) that they would like to apply an action to.
2. Choose action
Page
Device Inventory Page
Description
After selecting their device(s) the user chooses an action from a dropdown.
3. Apply action
Page
Device Inventory Page
Description
The user must then click on the “Apply” button in order for an action to be applied.
4. Action modal
Page
Action Modal
Description
For the grouping action, a modal appears that allows a user to select a group to put their devices into.
Prototype
Grouping devices
Solution
In the end we would have to come up with a new device grouping flow, so we decided to have all grouping functionality contained within a progression based user flow.
Through the iterations we figured out that it would be better to separate the grouping function from the device inventory page so users get the sense that they are in an area of device management and not browsing. I took inspiration from other areas of the site to lower the development lift from this new flow creation. In the end, we had a flow that allowed users to select their device(s), place them in groups and save them for mass actions at a later time.
User Flow
1. Grouping button
Page
Device Inventory Page
Description
Users click on the “move to a group” button in the action ribbon to begin the grouping process.
2. Select accounts
Page
Grouping - Select accounts
Description
Users can search for devices, and select the device(s) they would like to group.
*Not all search and table functionality is shown in prototype.
3. Select group
Page
Grouping - Select group
Description
Users can choose what group to move their devices into, they are also able to create a group.
4. Review
Page
Grouping - Review
Description
Lastly users can review the accounts and the group that they will be moved into before confirming and finfishing the grouping flow.
Prototype
Reflection
Build it and see how it works.
I learned that sometimes it’s easier to build a quick prototype and prove out a idea or concept than it is to discuss the ins and outs. Not only does it allow everyone to see what an experience looks like, it also reveals design and development blindspots. In the future I will built out hotly debated ideas, to quick that quick validation.
User Story
How might we allow a user to quickly get a sense of how many accounts are enrolled so that they can manage those accounts?
Considerations
User needs
We considered how the addition of multiple programs would affect the account setups for our users and how that would permeate throughout the system and surface in different scenarios.
Business needs
We considered how the addition of multiple programs would affect the business and how it could aid in the business goal of driving users to enroll. Higher enrollments lead to longer management contracts and revenue.
Current state
Dashboard
The account dashboard is the place most users visit when they are looking to work on managing accounts at scale. So, this is where the displaying of devices in programs is crucial.
One program
With only one program worth of accounts the client was using a pie graph to give a visual breakdown of accounts. When adding addition programs goes live, it would becomes difficult to display how many accounts are in one program versus two, as well as how many of those accounts just aren’t enrolled.
Multiple programs
Ideation
When the function is rolled out users will want to know how many accounts are in one program, two programs or not enrolled at all.
Through the ideation process we discovered after multiple programs is live, it’s irrelevant if a account is enrolled or not. The real value would come from giving users a quick sense of how many of their accounts are enrolled in one program versus two.
Potential solution 1
Account utilization
The account dashboard is the place where most users would be if they are looking to work on managing accounts at large. And so this is where the displaying of accounts in programs is crucial.
Pros
Easy to understand
Illustrates a sense of urgency with color + symbol
Does the math fo users
Cons
Lacks detail breakdown
90% utilization
50% utilization
Potential solution 2
Account utilization + Mobile enrollment breakdown
This approach would have displayed the utilization number of enrolled accounts with a status color. We also thought about adding a second visual for the account breakdown for better account visibility and keeping a CTA to enroll accounts.
Pros
Illustrates a breakdown of accounts
Coloring of percentage pairs with status colors. Green equals good and red-orange equals warning.
Cons
Total number of accounts is omitted, users have to do math.
More visuals, means that the user would take longer to process the information shown
Multiple programs
Solution
We went with a simpler approach that didn’t change much of the original UI but allowed for users to understand the account breakdowns at a glance.
Through all the iterations we uncovered what we thought would work and what wouldn’t. We were able to weigh the technical cost and business cost versus the user needs and potential increase in conversions. We settled on maintaining the current pie chart, updating the colors and the key. The UI remains familiar and the change in user needs is accounted for, we also gave the user extra functionality to quickly edit their accounts with two CTAs.
Before
After
Reflection
Simpler may be better.
I learned that although I have ideas that could change the way a user gets their information and I may think it may be helpful. I also need to consider the potential lift in revenue versus the business costs of building that functionality. In this situation it became apparent that we shouldn't start from scratch. Instead reuse components and tweak them to help keep technical costs low so that potential gains aren't lost.
.png){kind=icon}
