Improving the usability and design of a customer service platform

Introduction and research

Background

As part of my current position as a customer service representative, I make use of the platform OTRS to manage and answer customer queries (aka “tickets”).

After having gained experience with this platform, I have noticed several pain points and limitations. In this project, I attempted to provide solutions for several pain points and a re-design of its current user interface. 

OTRS in its current form

Competitive audit

For purposes of both research and inspiration, it was important to begin the project by conducting a competitive audit. I was interested to know how other customer service management (CSM) tools provide an experience for their users and what design/UI decisions they make to further enhance this.

To survey the space sufficiently, I researched three direct competitors: Zendesk, FreshDesk and Helpshift (the latter I also have professional experience using).

I was interested in getting insights into the following main areas:

  1. Ticket management: How are tickets created, assigned, and tracked?



  2. User interface: Is the interface user-friendly and intuitive?

  3. Automation: What automation features are available?

  4. Multi-channel support: How are different communication channels integrated?

  5. Analytics: What reporting and analytics features are provided?

  6. Customization: How customizable is the platform?

Freshdesk's user interface for answering customer tickets

Direct competitors

My research showed that Zendesk, Helpshift, and Freshdesk each offer distinct strengths in the CSM tool space.

Zendesk stands out with its sleek design, multi-channel support, and robust customization with potential to integrate with tools such as Jira and Slack. Freshdesk, closely aligned with Zendesk, emphasizes dashboard functionality and customizable workflows, offering a reliable and streamlined solution.

Helpshift’s offering slightly differs in that it excels in mobile app support, making it ideal for businesses focused on in-app customer service. While more specialized, it leads the way for in-app messaging and notifications to customers.

To sum things up, Zendesk offers the most versatility across industries, Helpshift is the best choice for mobile-first companies or products, and Freshdesk provides a well-rounded, cost-effective option without sacrificing essential features. Each platform brings valuable benefits to the table and all were valuable in giving me ideas for how to provide solutions for OTRS’s current pain points. 

Zendesk's ticket answering screen provides a professional and sleek experience.

OTRS

OTRS originally stood for “Open-Source Ticket Request System” and has been on the CSM market for over 20 years. Personally, I have been using OTRS for over three years, specifically to answer customer messages that come to us via the company website. Tickets typically address technical, financial, or fairness issues and are generated via customer messages, phone messages and webforms.

OTRS’s ticket management process is quite clunky, requiring users to retrieve customer info from external tools and slowing down ticket response times. Its UI feels outdated and lacks a cohesive dashboard, making the whole experience feel like an email inbox rather than a modern CSM. While OTRS does provide multi-channel support through emails and phone calls, it falls short in customization—there’s little flexibility and no integration with key tools like Jira, Confluence or Slack.

By centralizing features, integrating third-party apps and improving access to customer data, it could drastically boost its efficiency and provide a smoother experience for its users.

The current ticket view for OTRS
OTRS offers a very limited amount of statistica analysis with no sense of "centralized" dashboard-design that competitors make use of.

Opportunities & challenges

Surveying the CSM landscape provided an understanding of potential opportunities and challenges for this project. These included:

  1. Opportunity #1 (Improved Integration):

    OTRS requires users to navigate to another intranet database platform in order to search a customer’s history and to execute various functions. To allow a user to do some or all of these tasks in one place would greatly improve their efficiency.

  2. Opportunity #2 (UI overhaul):

    OTRS is significantly lacking in the UI department if it wants to be considered a tool on par with competitors in the space. To introduce a user-friendly dashboard that creates a personal hub for the user would be a strong start.

  3. Opportunity #3 (Streamline the UX):

    A pain point for users is when they need to carry out various actions in OTRS and they find it to be clunky and slow. For this reason, it is important to consider how to make things smoother and faster in a re-design.

  4. Challenge #1 (Feasibility):

    Some of the ways to address customer pain points would potentially have implications for the core architecture of OTRS. This may mean that some plans are too technically ambitious to develop.

  5. Challenge #2 (Cluttered interface):

    When designing a dashboard layout, it’s important that information available to users is useful but at the same time not overwhelming .

Staff survey

To provide more qualitative data and insight, I conducted a survey that I sent out to other customer service members on my team that have a working proficiency of OTRS.

Their answers showed that they find OTRS to be generally inefficient, with it often being described as clunky and time-consuming for certain tasks. While answering tickets feels intuitive, other functions—like switching templates and searching for tickets—are notably slow.

It was emphasized that OTRS could be more efficient, particularly due to the lack of bulk actions and filtering capabilities. It was also suggested that integrating it with AdminTool (the customer database) would greatly improve a user’s experience by reducing the need for multiple platforms. Overall, there was broad agreement that integrating AdminTool would streamline workflows.

Building Empathy

User Personas

After conducting a competitive audit and analyzing the results from the survey about OTRS from my colleagues, I started to conceptualize the main pain points of using the platform. To aid me, I created two personas to formalize this:

User flows

I then created two userflows to illustrate the user journey for the following tasks:

  1. Answering a customer ticket in OTRS

  2. Requesting restricted information on a customer with a history of fraud to answer a ticket

My motivation for the former was that it is the most common workflow on OTRS, while the latter expresses a specific pain point whereby junior customer service members cannot easily complete more complicated tickets without the help from senior CS members (with more access to information), to provide them with the necessary customer information.

User flow for a user’s journey of answering a customer ticket in OTRS
User flow for a user's journey when requesting information on a customer with a history of fraud in OTRS

User map

I then built a user map, to identify a user’s thoughts, feelings and possible pain points throughout their user journey when using OTRS.

Defining the problem statements

Considering the user journeys of our two personas compiled with my research, I came up with two problem statements that I would focus on for the rest of the project:

  1. Problem Statement 1:

    “Customer Service Representatives find it difficult to answer multiple queries from one customer due to the lack of bulk-oriented functions in OTRS.”

  2. Problem Statement 2:

    “Junior customer service representatives find it frustrating that certain information restricted for more senior CS members prevents them from answering tickets, slowing down their workflow and efficiency”

Wireframes

After mapping out the user’s journey, I began the ideation phase. I first started sketching out concepts on my whiteboard to get a sense of space and dimension for my design.

Once I was happy with my sketches, I then moved over to Figma to make low-fidelity wireframes to map out the fundamentals of the new design.

Digital wireframes of the main screens in FIgma

Prototype

Once I was happy with my digital wireframes, I began experimenting with colour, font and elements of a new design system. I was largely inspired by the aesthetics of competitors like Helpshift and ZenDesk who work with a simple colour palette to create a sense of professionalism. For this reason, I chose a dark blue (#003366) to be the accent colour that I would use to create a sense of brand identity and to balance that with white, black, greys and a light blue (#E6F2FF). 

The design system
Adapting wireframes into mock ups

For this prototype, I created three user flows:

  1. Refund a customer and send them an email

  2. Make multiple refunds and send a bulk email

  3. Submit an information request to higher management to answer a complex ticket

I devised a set of instructions with a series of feedback questions which I sent out to volunteer colleagues who are or have worked in the customer service team. It was important to focus on this group because they are in a position to provide insights into how the prototype addresses certain
shortcomings of the current OTRS model. For good measure, I also asked several colleagues who do not work within customer service, to see how they manage to use the prototype without prior knowledge of customer service ticket platforms. 

Prototype of my mock up frames

Usability study

Here are the areas for where the prototype addresses OTRS’ shortcomings:

  • Overall UI improvement: The colour scheme and overall UI feels more in line with CSM competitors and improves on some of the UI pitfalls of the current OTRS design.

  • Platform Integration: The integration of Slack and Jira was considered helpful for users with their daily workflows as they often use these platforms.

  • Integration of AdminTool: Being able to perform certain operations without having to leave the screen improved overall work efficiency and answering speed..

  • The “dynamic” approach: the ability to tag a ticket with a specific label that would then allow special operations to appear (for example, the bulk send option for “#multiple tickets” or the information request button for “#double account”) were praised for their innovation that allows users to have a more dynamic approach with OTRS.

Here are the areas for improvement:

  • Improve visibility for action buttons: Move icons like “Star” and “Add Note” closer to the answer field to make them easier to spot during ticket response actions.

  • Adjust widget sizes: Enlarge the AdminTool widget to improve readability especially as users will need to make frequent use of this widget. By the same token, make the Customer History widget smaller as this is less important.

  • Improve template search feature: Move the template search field closer to the answer box as it is currently not intuitive.

  • UI element relocation: Consider swapping the boxes on the left (Ticket Status and Customer History) with those on the right (Game info) to adhere to the UX principle of proximity.

The ticket answering screen before and after the usability feedback modifications

Conclusion and final thoughts

Accessibility considerations

Aside from the black text on a white background, the two main colour combinations featured in the design were black (#000000) on light blue (#E6F2FF) and white (#FFFFFF) on dark blue (#002147). Both combinations
passed the accessibility test on WebAIM with the former receiving a ratio score of 18.5:1 and the latter a score of 16.04:1.

In addition, I made sure that the vast majority of buttons not only displayed text but also an icon to signify the function of each button for users who may prefer or rely on visual cues instead of text.

As explained above, I made sure to adhere to as many UX principles as possible to offload the burden from users to improve their working efficiency. As for UI, I kept to a very limited but consistent colour scheme only making use of several colours and only using a single font (Roboto) throughout the design.

Areas for improvement

Reflecting on the project, I believe there are several areas that still require further improvement:

  1. Input from an engineer:

    In order to address certain shortcomings of OTRS, some of my solutions made technical assumptions (e.g. the feasibility of integrating AdminTool into the OTRS interface). A valuable next step would be to discuss and review with an engineer or architect to see how feasible my design decisions would be in their implementation and what further technical constraints to be aware of.

  2. Further iterations and usability tests:

    It’s always worth conducting several more rounds of usability studies to re-iterate to an optimized model of the prototype.

  3. Input from management:

    Communicating with company stakeholders and management about the budget and resource for improving OTRS as opposed to simply adopting one of its competitors such as ZenDesk in terms of cost and business strategy would be valuable input.

  4. Test other user flows:

    Team members higher up in Customer Service need to utilize OTRS in other ways (e.g. staff management/ticket distribution/overall statistics and data). Focusing on several user flows that address more management-oriented workflows would be a worthwhile way of developing the prototype further.

A user navigating the new OTRS prototype

Conclusion

I greatly enjoyed making this project as it relates directly to my experience as a customer service representative at GameDuell. This allowed me to evaluate my actual pain points with the platform and to provide a solution that would benefit me and the rest of my team in our daily tasks. In addition, working within a real world context allowed me to develop a better appreciation for dealing with certain constraints that informed and impacted my designs. Through this project, my understanding of UX principles and ability to make a professional-looking design system have also improved.


To assess whether my prototype has gone about answering my research questions, I’ll revisit the two problem statements I proposed during this study:

Problem Statement 1: “Customer Service Representatives find it difficult to answer multiple queries from one customer due to the lack of bulk-oriented functions in OTRS.”

Has my prototype solved this? I believe yes, the ability to bulk send ticket responses allows users to take care of multiple tickets simultaneously thereby increasing their workflow speed.

Problem Statement 2: “Junior customer service representatives find it frustrating that certain information restricted for more senior CS members prevents them from answering tickets, slowing down their workflow and efficiency”

Has my prototype solved this?

Yes, users are able to formally request information at the click of a button that will alert senior members (working with the stipulation that this is technically feasible) to get the information they need in a streamlined manner. Of course there is still some wait time involved but at least there is now a system in place to facilitate this knowledge transfer.

To conclude, this project allowed me to draw on my real world job experiences to create a critical case study of OTRS as a CSM platform. The next steps I would like to consider include mobile adaptation, a critical assessment of the technical feasibility of the project and to consider user flows that are more concerned with management-oriented job tasks.

In addition to qualitative feedback, devising ways of obtaining quantitative feedback (e.g. ticket answering speed times/getting users to provide a score for each user flow) would help to optimize the model and my research further.