Cloud Help Desk (Desktop, android, iOS)
[Project Goal] Understand what IT pros (existing and future users) need in a help desk tool and rebuild it to address these needs better, in a way that maintains or allows for more display ad revenue.
[Responsibilities] Leading and executing user research, system conceptualization, all UX, and all UI.
[Collaborated with] End-users, developers, product managers, and stakeholders.
[Result] Desktop, android app, iOS app, and mobile web versions are live. 89.3% adoption rate across active users on the new design as of May 2022.
Summary
Help Desk is one of the primary free products that drive display ad revenue at Spiceworks. Tens of thousands of IT pros use it daily to service the needs of millions of end users at schools, non-profits, law firms, and more. I worked as the sole and lead full-stack designer (research, system design, UX, UI) to completely rebuild the help desk ticketing product across desktops, tablets, and mobile (android & iOS) so that it would better address the concerns and needs of existing as well as new users. Our hope is that we would increase the number of daily active users and thereby increase display ad revenue in the years to come.
My Role
Conducted contextual inquiries on how users currently go about their day-to-day activities in any sort of “task” or “ticket” system
Explored other competitor help desks or “help-desk-like” productivity tools to see how they solved various problems
Built and did usability tests with multiple prototypes built in Principle, Sketch/Invision, and Figma
Communicated with and worked with stakeholders to make sure all business requirements around monetization were being kept
Regularly met with product managers to prioritize which features were highest priority to build based on user research
Worked in an agile environment iterating on, creating design assets, and figuring out feasible implementations for features alongside developers on a weekly basis, while keeping track of ongoing user feedback occurring after each release (which occurred as frequently as every other day)
Collaborated with stakeholders, product managers, and devs throughout the implementation process to make sure the final product met the needs of the user and the business goals of the company
Results
The system was released in increments over 2020 until 2022, and has been adopted by 89.3% of active users as of May 2022. Existing users raved about the responsiveness of our team to their complaints or requests, though they were reluctant to adjust to the changes at first. New users appreciated the new design for utilizing modern design principles, ease of learning curve, and its flexibility across different devices and screen sizes.
The Challenge
Spiceworks relies on display ad revenue to conduct business, and a good portion is generated by its help desk products (Somewhere between a quarter and a half). These help desk products (desktop, iOS, and android) have been around for between 7-15 years collectively, and have not received major updates to the UX or UI during that time.
The challenge for me was to understand in what ways the product could be rebuilt and redesigned to better address user pain points and day-to-day activities, and come up with a completely new help desk product that would work maintain or increase ad revenue, as well as be a better tool for IT pros across all the common device and display dimensions.
The Discovery Period
Before I was even assigned this outcome, I and another designer had already been running contextual inquiries to try to understand how IT pros manage their tasks and projects on a regular basis. By the time working on this project rolled around, I estimate that I had done contextual inquiries with 15 people doing their day-to-day jobs involving “help-desk-like” tools.
A fellow designer and I talking through major findings from a contextual inquiry recording. We don’t always have the luxury of going this in-depth at our company since we all are working with different deadlines across multiple agile squads. But for me, this is the kind of work I can spend hours doing. Analyzing people, understanding why they do the things they do, and trying to help them get where they want to go.
What we learned from research
Some of the major findings we discovered from Contextual Inquiries and interviews were the following:
Users were reusing whatever products they had been using to manage end-user tasks to manage their own work “to-dos”. As one of our users said “The help desk is all the stuff I have to get done”. The way this behavior displayed itsself is users would create tickets for themselves to remind themselves what to do.
Users were using help desk to track team or personal long-term projects. Tickets were used as documentation to track the details of their project and upcoming or completed tasks. This would mean that some tickets would be open for months and be filled with much more information than the average ticket. We thought it might even be possible to use these project tickets as indication that an IT pro might be in market to research or buy technology, based on the contents of these tickets. (Something we unfortunately didn’t have the opportunity to explore further at the time.)
Even though the help desk was something we categorized as an “IT specific service desk tool”, non-IT pros were using it too. Tasks that required multiple departments (like onboarding a new user requires HR) or tasks that are not quite handled by IT but may also involved “end-user requests” (such as the building maintenance departments) were also ending up in help desk tools.
Even for the IT pros that are not assigned SLAs (service level agreements where they are required to respond to a ticket within X hours or days for example), many of them had personal ones or team-level goals which made tracking performance stats interesting to almost all the IT pros we encountered. It seemed to be a point of pride or something a good number of users were curious about. How many tickets did I close? How fast did I close them this week? Was I the slowest one this week in closing my tickets?
Mobile app or browser experiences was mostly for jotting down notes, viewing updates on tickets as they came in, getting notifications, and taking photos. Mobile help desk and growl/phone notifications were especially helpful when IT pros were “on the job” (ex. building a new computer, helping someone at their desk, traveling to and from office sites). That meant that the mobile experience could have fewer features.
BEFORE REDESIGN: This was the old android app version of the help desk with test data. It seemed to satisfy the user’s basic needs asides from the UI feeling a little outdated.
BEFORE REDESIGN: This is the help desk (before the rebuild and redesign) with test data. We observed users using other help desks tools as well. I can’t share screenshots since they contain sensitive data.
Some of the major findings we discovered from watching IT pros using different “help-desk-like” products were:
Users were sometimes rotating their monitors to better use our help desk product because we had stacked the ticket list on top of the ticket details.
People were scrolling up and down, up and down, for almost every ticket they looked at because of the layout.
When users scrolled down, the top ad was no longer visible and some users would take advantage of that to deliberately hide the top ad.
Users liked having the ability to click on something in a table on the same page as their ticket, but on smaller screen sizes it was better usage of space to have tickets load on a separate page.
Users relied on search heavily to reference old tickets to solve new ones, or to look for tickets they had worked on the previous day. The search in our help desk at that time was not granular enough and search results didn’t display where search terms were showing up in tickets.
Users are constantly interrupted by slack/text/etc. messages coming in, users calling in or walking by, emails, etc. So it was common for them to leave the help desk or tickets they were working on open so they could remember what they were working on if they get pulled away.
Iterating on prototypes
When it became apparent that rebuilding the ticketing interface of help desk would be a priority, I started designing prototypes with the following business constraints, research findings, and opportunities in mind:
Modular and responsive, so that the design could be reused and rearranged with minimal tech changes for multiple screen-sizes and for mobile (we were working with a smaller engineering team)
Better ad visibility (which is better for the bottom line)
Flexible enough to exist in the current tools ecosystem and help desk (since other portions of help desk would not be updated until later)
Allow IT pros to be more efficient with the most common tasks they do: switching between tickets, opening tickets being worked on in new tabs, replying to tickets, updating ticket details, checking whatever new updates occurred on tickets they are responsible for, etc.
Anticipate the most common pieces of information IT pros would need to make a quick decision on which ticket to work on, what is needed to be done, and to pick up where they left off when they get interrupted.
Below are just a few screenshots from prototypes of various layouts I played with.
During this time, I did several usability studies to see how users would respond to these very drastic changes. Just a few of the changes we made based on the findings were:
make the response area as easy to access as possible (rather than multiple clicks)
if split-screen is implemented, increase the amount of the table showing or allow users to adjust the width of columns, the side-panel, etc.
use more visual indicators other than color to differentiate between comment types (due to colorblindness in users)
remove bumble-bee striping to account for over and clickable states
Iterating in agile
The vast majority of work involved in iterating and “providing” incremental value though happened in agile sprints. I would say this was probably the most difficult, and rewarding part of the process since it required so much collaboration and communication between teammates and stakeholders. Added onto it was the pressure of scrutiny from very emotionally involved users. We got to see in real time in our blog posts how users were reacting to the changes we were making on a weekly, sometimes daily basis.
Dealing with the constant barrage of user feedback: We received both critical and positive feedback, and here are few examples. I had to learn some soft skills to deal with increased internal and external scrutiny of our releases. Knowing when to defend the design, point people to numbers, or to take critical feedback well was a difficult, but good learning experience.
Iterating in agile in Figma: During this project, we transitioned from the tools Invision/Sketch to Figma, so I had to figure out a completely new process for staying organized with stories within Jira. I started experimenting with stories on each page organized by backlog order (shown on the left side), mockups with flow lines, creating separate pages for stories, rearranging them on the left when they were completed by the engineering team, creating reusable components and component libraries with existing and “future” versions, etc. A good learning experience was figuring out how to show the team the context of the feature they are building so that they could take it into consideration, while making it clear what had to go out for the sprint.
During this time, our team had many discussions that occurred around prioritizing stories, debating on what users “actually needed” versus what they requested, keeping stakeholders in the loop, and more. I also learned more about how to balance between creating a culture where everyone feels safe enough to give UI/UX suggestions and putting my foot down when there were stalemates or lots of wasted time “churning”.
Latest designs
This section would normally be the “final design", but since we’re still iterating on it in 2022 and onwards, this is just what it is as of June 2022. Currently, 89.3% of all active users are using these new styles on desktop, and 100% on android and iOS. If you want to see desktop live, you can create a free account here. Below, are some screenshots to show the variations in the layouts that we ended up with and some screenshots from Android. I’ve also included a video showing the live demo of desktop.
Retrospective (so far)
There were several things that looking back, I would have changed in my design if I was given more time to iterate on my design even further.
Address the feedback of power users, but don’t let them dictate the priorities (look at the numbers).
Both internally and externally, there was a lot of conflict and emotions around the feedback we were getting from our most invested user base. I underestimated how much people within the company and within our team would react to the feedback. Some people wanted to directly include the features they requested. Other people wanted to know why we had made the decision to go with a vertical split instead of a horizontal split. It actually took a lot of time and energy on my part to look at the data and defend design decisions, while acknowledging that the feelings of our invested users were valid. The points I ended up with were:
Existing users are used to a horizontal-split because that is what the old product provided, not because it was overall a better UX. New users won’t start out with that expectation.
It was safer to begin with a vertical-split in the MVP because the largest population of users were on screen widths of 1920px. That means real estate is more limited vertically, meaning a vertical split would work on the majority population.
Just because we don’t have a feature in, doesn’t mean that we can’t add it. That’s the whole advantage and point of agile vs. waterfall… we can react to findings quickly and pivot quickly. I had designed the product to be modular so we could add features like split-screen easily. It wasn’t a failure on our part, it was actually an indicator of success that we could so quickly react to feedback.
Adding horizontal split-screen doesn’t necessarily improve retention or attract new users. But it may be worth doing just as a show of good faith to end users.
Looking back, I should have communicated these design rationales earlier, because there were a lot of frustration internally and externally that could have been addressed. I still don’t know if I communicated these well or not…
Keep teammates more in the loop with what UX designers are doing and why, and advocate for myself more.
As the sole designer on the product, the lone female on the team, and one of three UX designers in the entire company… it’s very common for people to have no idea what you do, what value you bring, or how to even work with you within a team. I used to just adjust to the work styles of people or each dev or PM that I ended up with, without complaining. But I started burning out after awhile working on this since we were iterating so much and constantly releasing new updates. So I started bringing up what I was doing and why before people asked, and also brought up things that I thought needed changing, like having more visibility into a feature’s progress over a course of a sprint, less emphasis on what internal and external folks suggested as the right UI/UX, and having more realistic deadlines when it came to getting user feedback, etc. And surprisingly, people were very receptive to those changes.