No items found.
Linkedin
Trane Technologies is a global leader in providing climate solutions to buildings, homes and transportation by manufacturing a wide range of HVAC units and temperature control systems for trucks, residential and commercial purposes. In 2019, Trane undertook a complex ERP (Enterprise Resource Planning) implementation project called ‘Worksight’ to integrate and redesign interfaces of many functions across the business such as finance, sales, and manufacturing. Case Management Solution is a B2B (Business to Business) web application within Worksight which will be used by sales offices to orchestrate the return of various products sold to the customer.
Replace a legacy application by designing an end to end solution for processing customer returns for all HVAC units, parts, and accessories. Integrate two separate interfaces used by the 'Submitters' and 'Approvers' in a single comprehensive UI to provide a seamless user experience as well as increase productivity of plants and sales offices.
Worksight is a massive ERP (Enterprise Resource Planning) program which houses many sub-applications like Finance, Commissions, and Reporting. These applications all come together to process sales orders for Trane. Case Management Solution is another application within the Worksight program that allows users in Trane Sales Offices and Manufacturing Plants to process the return of a product requested by the external customer. My job was to redesign this 10 year old legacy application to meet business and user needs in an Agile project. Since I worked on redesigning the Billing application of the Worksight program, I had some understanding of the business and users I was interacting with. However, I knew each application within Worksight was used by a separate business team and had unique business processes. To get a better understanding, I decided to conduct multiple workshops with business owners, architecture teams, sales persons, and sales office managers. These workshops were initially scheduled to be done in-person, however, due to the pandemic we were forced to go all virtual. The purpose of these workshops was twofold - to understand the complexity and scope of the legacy application, and to fully immerse ourselves in users’ day-to-day life to identify their requirements.
During the workshops, my team (Architects, Engineers, Business Analysts, and Scrum Master) conducted multiple interviews with a diverse group of users in different manufacturing plants across the United States. We divided users in two groups:
Submitters: Sales people who initiate the return of a product by submitting a case.
Approvers: Members of a dedicated team to review and process the submitted case.
We observed the steps taken by these two user groups to process product returns through screenshare. Furthermore, I also interviewed them to gain insight into both their experiences and needs. Here are a few of the questions and prompts:
1. Walk us through how you submit a case to return a product.
2. Tell us about the types of products that are mostly returned.
3. What information do you need to successfully process a return?
4. Tell us more about your team members and their roles.
5. What do you struggle with in your day-to-day work life?
6. In an ideal world, how do you picture the processing of these cases?
7. What improvements do you suggest in the legacy system?
Through workshops and user interviews, I found that the people I thought were submitting these complex forms were actually not the real users of the system. Due to the considerable time it took to fill out the forms in the legacy application, some sales people were actually passing on these tasks to interns and plant assistants! Sales people preferred to simply review the case before submission. This insight informed me that I needed a third persona to fully represent the three different user groups of the system. Along with Submitters and Approvers, I added another persona called Pseudo-Submitters. Below is an example of the persona I created for an Approver:
I observed three major themes that were root causes of various pain points described by the users during interviews. These insights clearly outlined gaps in the current system and also presented opportunities for improving the legacy business process.
Manual Data Entry
Users have to manually type all the information to submit and approve a case. This leads to avoidable errors, waste of time, and rework.
Poor Communication
There was no robust process for back-and-forth between Approvers and Submitters. Users had to request information for a case through MS Teams and Outlook. They also had to manually keep a record of this exchange in a general notes section within a case.
Lack of Visibility in Information
Both Submitters and Approvers did not have the necessary data and documents they needed at their fingertips. They would need to hunt for the data which was located in various systems.
After researching user needs, it was important to conduct a full audit of the entire legacy application and business process. The purpose of this audit was to understand exactly where the complexity originates in the legacy application. A 10 year old application provided a unique challenge for me since I found that the users have created many workaround solutions to meet their requirements. To better analyze the process, I got access to the legacy application and attempted to process some cases. Through these exercises, I soon realized that much of the complexity in the legacy process was actually required. The legacy application processed returns of any size - from HVAC units that were as big as a car, to parts and accessories that would fit in your pocket. Due to this, it incorporated many features and multiple screens to accommodate all types of returns. My job was to not remove the complexity from the process, but to manage it so that it isn’t complicated for the end user to handle. Through my research, I was able to identify three layers of complexities.
Integrative Complexity - The legacy system was supported by a complex back end architecture. Multiple apps stored in different databases came together to support the legacy business process which resulted in long wait times and a terrible user experience.
Informational Complexity - In the legacy application, each project had multiple sales orders. Each sales order had multiple shipments, and each shipment had specific order lines. Users had to comb through this large data volume to identify exactly the order line they needed to process a return.
Environmental Complexity - Since this was a multi-day process, users had countless distractions and interruptions in processing a case. The breaks in the workflow resulted in users forgetting previous steps and crucial data.
To outline user needs and opportunities for innovation, I synthesized my findings by creating user journey maps. I created three journey maps for user groups with different goals for each group. These maps helped provide a holistic view of the entire case lifecycle and uncover moments of both frustration and delight for the user.
To help me prioritize opportunities in the user journey, I also created a list of project goals with the help of business owners and system users. These served as a foundation for determining the necessary features to include in the application. Below is the user journey map for the Submitter.
After compiling research findings from workshops, interviews, user journey maps, and the legacy system audit, I decided to go through multiple brainstorming sessions to come up with functionalities and features to address the user needs. One of the benefits of working in an ERP implementation project is that I had jurisdiction over retiring apps and databases, therefore having the ability to transform the legacy business process completely. I went through multiple sessions of 'How Might We' activities and identified many changes that would manage the integrative complexity of the legacy process, thus retiring many supporting applications. This resulted in significantly simplifying the product return process and also helped the business save maintenance costs. These changes were taken back to business owners and sales office users from time to time for approvals from all the stakeholders.
Introduce a Step-By-Step Guided User Experience
Rationale: Submitting and approving a case was a multi-day process. Due to this users would sometimes forget the last action they took on a case. Keeping this in mind, I introduced an approach where the system would ask the users a series of questions, and users would pick an answer from the options presented. This way, the new application guided the user to submit a case based on their needs. I divided all data entries into different sections and autosaved the case, allowing users to close it at any time. The next time they logged in, they were presented the same screen where they last left off the application.
Supporting Research: User Interviews, Remote Field Study
Autofill Information
Rationale: Submitting and processing a case required manual data entry of the information in the legacy system. Users would have to hunt for this information in many different applications. To mitigate this, we integrated databases from most of these applications which helped us to autopopulate the information like sales order lines, product serial numbers, and associated fees. At the end, we were able to autopopulate almost 80% of the data entries within the new application which not only saved time, but also reduced errors by both Submitter and Approver.
Supporting Research: Legacy System Audit
Introduce Comments, Followup and Auto-Email Features
Rationale: During workshops, I often heard users complaining about lack of communication between Approvers and Submitters. To resolve this, I introduced a
'Comments and Followup' feature which will be seen by both user groups on each case. This feature provides users the ability to add comments, followups, and a followup date. Users can also choose to tag people in comments/followups and the system will automatically notify the tagged person via email. That way users do not have to record their exchange on the case and manually send a separate email.
Supporting Research: Workshop Findings, User Journey Map
Introduce Rework Option
Rationale: Previously a case could only have three statuses - approved, pending, and rejected. If an Approver needs to request additional information or correct any mistakes made by the Submitter, they marked the case pending and manually requested the information or made corrections themselves. We introduced a new status called ‘Rework’. Marking a case in this status sent a case back to the Submitter to make edits or upload any additional documents requested by the Approver.
Supporting Research: Legacy System Audit
Financial Impact Dashboard
Rationale: During our research, a common complaint amongst Approvers was a lack of information of financial impact for a product return. We included a ‘Case Summary’ tab which displays a dashboard with information on financial impact for the customer, sales office, and the overall business before a case is approved. This provides a substantial change in data visibility in the new application.
Supporting Research: User Interviews, Interviews with Finance Team
After defining a high level vision of the design, I started fleshing out the steps users will take in the new application by creating a User Flow diagram. I also decided to carefully study user flow diagrams of the legacy application to make sure I did not missed any required steps to successfully process the return of a product. Reviewing the legacy flows also highlighted the complexity of the application and visualized where in the new user flow this complexity would be removed. This approach not only helped me with the design of specific pages, but also helped to sell the new design to business leaders and stakeholders.
Taking into account all of the research I gathered, I began my favorite step in the ideating process - sketching paper wireframes! To do this, I first listed out all the components I needed on the page and quickly sketched as many ideas as possible on paper. I find that nothing is able to replace classic tools like markers and paper when it comes to transferring ideas from my brain to a visual layout.
After I completed the visual layouts on paper, I started to add more details by turning them into a low fidelity prototype using Axure. I’ve had a lot of success working with Axure for B2B applications - it allows for a high level of interaction, which is valuable for usability testing. Low fidelity wireframes helped me establish the core aspects of my design before applying any styles. I tried to incorporate use of accordions, success messages, panels, and design patterns already used in other parts of the Worksight ERP application. Familiarity with interactions would allow my users to focus their cognitive load on the content of the application rather than the application itself.
After I finished my low fidelity prototype, I started working on a research plan to determine goals, scenarios, and a script to conduct usability testing. We were sure to include both experienced and novice users for the usability testing across multiple plants to get as much feedback as possible from a wide variety of perspectives. We conducted multiple rounds of usability testing on the main user flow to see if Submitters were successfully able to submit a case, and Approvers were able to process it. Usability testing instilled a confidence within me about my design and also identified many improvements. Below are some elements from the usability study plan.
Goal
To test the usability and interactivity of the proposed Case Management Solution and test if the users are able to complete core tasks successfully.
Research Questions
1. Are the users able to complete the main tasks of the application?
2. What are the steps where users get stuck or need guidance?
3. Are Signifiers used in the application apparent enough for discoverability of various features within the solution?
4. What pieces of information users have not utilized to complete the process?
5. What is the overall satisfaction of the users?
KPIs
1. Time on Task - How many minutes do users take to finish various scenarios?
2. User Error rate - How many times does the user ask for assistance or get stuck?
3. Satisfaction rate - How many users have rated interaction with the proposed solution over 7/10 points?
Discoveries
1. I removed few data pieces from the legacy UI in our proposed solution for visual simplicity. Users asked to view this data while completing tasks.
2. Users attempted to manually count the number of cases pending for their team to gauge the amount of work remaining for the session.
3. Over 30% users struggled to find cases specifically assigned to them.
4. Almost all users utilized comments and tag function to record actions performed on a case.
Actions
1. Include supplementary information in an accordion for users to access.
2. Investigate ability of including a dashboard with statistics like number of pending cases, followups, etc.
3. Add ability to filter using a link button rather than a manual filter. Include an information icon to guide the user on using a filter.
4. Replicate comments section on landing page in addition to the case details screen.
To conceptualize the Case Management Solution at a visual level, I utilized the existing branding and style guide for Trane. This created a cohesive look and feel of the application and also reduced time for working on visual design significantly. I applied the 60-30-10 rule and reserved bold colors for call to action elements. Below is an example of the Trane Style Guide I helped create in Spring 2020.
Note: The images below are provided for reference purposes only to prevent the disclosure of sensitive insider company information and user interface details to the public.
Case Management Solution is currently in development. Working on a B2B application was immensely challenging and rewarding for me. Below is a brief summary of some of my learnings from this project.
Research
Systematic research was critical to bring this project into fruition. I spent countless hours studying the legacy application and analyzing its various components. This effort helped me realize the user assumptions and mental models which proved helpful during the ideation stage.
Collaboration
I had advantage of working with various Business Owners, Engineers, Architects, and Business Analysts in this project from the very beginning. Ultimately, each person played a vital role in this project. Getting business feedback and feasibility of designs right away helped save valuable time.
Agile Methodology
This entire project followed an Agile process. Working in specific sprints helped me prioritize and deliver key features of the project in a very short duration. I also learned how the design thinking process can be tweaked to fit the Agile methodology.
