Improved learner-support at Upraised by tuning into learners' needs and introducing a go-to help center, making support more streamlined and reducing internal operational inefficiencies
At Upraised, the 16-week intensive online program was hindered by complex support channels and unclear information access. Learners, unsure of whom to contact for specific issues, faced significant challenges. This not only caused confusion but also led to operational inefficiencies, affecting both team performance and students’ learning experience. This was a result of fast paced 16-week journey in which each learner is connected with ~18 different people at the very least.
The central issue was the inefficient handling of student inquiries due to poorly streamlined support channels. This led to excessive redundant conversations, overburdening various internal teams, like Program and Learning Content, and causing delays, which in turn resulted in misinformation and student dissatisfaction. This was further problematic since learners were exposed to a whole bunch of people during their entire learning experience, which made them reach out to multiple members of internal teams in the hopes of getting a faster reply.
To understand the gaps in our support channels, we conducted a thorough analysis of learner inquiries. The Program team meticulously logged over 130 calls with learners over 2-3 weeks, detailing the nature of each query. The idea was to understand in detail, the different types of queries that learners discussed and seek external help for, based on the nature of these ~500 queries, we had planned to explore solutions.
Over 500 queries were categorized into 6 major types, suggesting specific areas where support could be centralized on the platform and alongside this, we went back to the sheet and checked if these queries can be solved via the dashboard or needs a call, and for all the queries which were solvable by the dashboard, we made a list of things which is an improvement to the current flows / information architectures.
We realized that updating existing flows and information architecture of various features across the product would consume a lot of time from design as well as engineering, which would mean sidelining some of the things from the existing product roadmap. To avoid this, we decided to come up with a rudimentary solution which was quick and easy to implement and would reduce the number of calls and improve the efficiency plus give a reliable solution/answer to the students in the quickest amount of time. And later make some space for fixing some of the more severe queries in their sources of origin as a part of iteration of existing features across the product.
We decided to give a place for students to go through some of the commonly asked questions and then a way to streamline all the different type of help/support that is available to them directly via the dashboard. This seemed simple, but reaching to this stage included researching on existing support systems by other tech products, ranging from ed-tech competitors to industry leaders like Zapier and Google. But all of this made us question—how do we present or disclose all of this information and what sort of interaction patterns would be best considering everything we have so far:
In designing the Global Help Center, my focus was on optimizing user interaction to ensure information was easily accessible and support channels were intuitive. So here’s all of the key decisions one by one:
The team decided to make this global access in the nav bar/header of the product since we would be enabling this to all users at all levels throughout the product. There were still three main ways we could surface the global help center for the users. This could be done with:
I decided to choose the side drawer approach due to the fact that it kept the learners in the same context as their doubts/queries and did not directly remove them from that environment. While on the backend, the engineers would still maintain this as a separate webpage and just embed everything in a web-view so we could have specific links that we could send the learners in case of specific doubts if they still reached out to us.
As shown below, there were a few directions that I explored while narrowing down on information architecture of the various categories with some variation in navigation between the 6 different categories. After looking at the pros and cons of each, I decided to finalize on one of them. Let’s get on a call to discuss the way I went through the pros and cons of each one of these initial wireframes before choosing the final layout and flow.
This was probably one of the most interesting decisions that I took personally. We had to choose between having the 6 categories showing up every time a learner clicked on help vs having FAQs showing up directly.
We decided to go with FAQs showing up based on the current screen through which the learner has accessed support. That meant showing program related queries on program dashboard, showing learning related queries if learners access it from learn tab, showing placement related queries if learners access it from jobs tab, etc. Explore this in the prototype attached in one of the sections below.
To streamline communication, we implemented an email-based contact system, coupled with clear response time estimates. This decision was crucial in making support more efficient and predictable for learners.
But as things happen in product teams, there was a small scope creep, and at the last minute, we decided to provide learners with 2 different methods of reaching out to the respective person - via Slack and via Calendy depending on the person they are reaching out to.
Explore the prototype to see how these elements come together. Note that most of the content has been changed , and designs use the Upraised's Rising Design System.
As of me writing this, I was unable to track any tangible data due to me moving on from the company, but given that the goal of this project was to improve the experience for the learners by giving them correct, precise and timely response to their queries and reduce the inefficient 1-1 calls that the internal teams had to get on.
After conversing with my former colleagues, I believe we nailed the problem related to timely response/expectation setting and reducing inefficient 1-1 calls completely as well as lay the foundations of what could potentially grow into the standalone help center as the platform evolves and starts to grow across multiple course and programs with different student journeys, while making it easy for the team to manage and respond to all queries effectively.
I'm available for a conversation to see if we're a good match. Use the link below for scheduling one or shoot me an email—I'm fast with replies, unless I'm out hiking or watching FC Barcelona play
