A platform connecting service engineers, vendors and clients to provide a seamless solution to request and offer maintenance services, while tracking productive hours
Setting the stage
Siemens focuses on key sectors like Digital Industries, Smart Infrastructure, Mobility, and Healthcare. It provides automation and digital solutions for manufacturing, builds smart buildings and energy systems, delivers efficient transport solutions through Siemens Mobility, and offers advanced medical imaging and diagnostic tools in healthcare.
This project is part of an 8-year-old legacy system developed for internal service engineers. Industrial Service Exchange serves as a central platform that connects service engineers with manufacturing facilities to streamline service request handling, improve service delivery, and optimize timesheet and productivity tracking.
Company
Siemens, Singapore
Industry
Digital Services
Timeline
June 2022 - May 2023
Software Development Life Cycle
Agile Methodology
Role
User Experience Designer
I led the UX and product design efforts from the initial redesign exploration to final implementation. This included understanding the inherited legacy product, conducting user research, ideating, designing, and prototyping. Throughout the process, I collaborated closely with project managers and partnered with engineers to ensure a smooth and effective redesign.
Team
01 Project Lead
01 Lead User Experience Designer
01 Project Manager
01 Software Architect
02 Web Developers
02 App Developers (Android / iOS)
MY DESIGN APPROACH
PROJECT
CHALLENGES
What is the problem?
The main challenge was to design a seamless and efficient workflow tailored for service engineers — the app's primary users. These engineers rely on the app daily to manage critical tasks such as accepting service requests, logging productive hours for accurate billing, and scheduling regular maintenance visits. The goal was to simplify these interactions to reduce friction, minimize errors, and support their on-the-go work environment.
What are we solving?
Faced initial resistance from internal service engineers due to additional workflows layered on top of their existing tasks, leading to frustration and reduced efficiency.
Received frequent feedback highlighting poor accessibility and usability issues, especially in field conditions.
Leveraging this opportunity to modernize the legacy app by converting it into a Progressive Web App (PWA), enabling seamless access via web browsers without relying on a dedicated mobile app. Ultimately, removing the phone application.
Improve the evidence capture and sign-off process to enhance transparency and accountability for both service engineers and factory management.
New steps added complexity to engineers’ existing daily tasks
Resisted changes due to disruptions in work efficiency
Poor usability in field conditions slowed down task execution.
Resisted changes due to disruptions in work efficiency
DESIGN PROCESS PLANNING
RESEARCH RESULTS & FINDINGS
Conducted an in-depth analysis of the existing application’s workflow and interface to identify inefficiencies, usability issues, and poor UX patterns—focusing on key features and user pain points for improvement.
Inefficient use of screen space, resulting in visual clutter or missing critical information at a glance.
Unnecessarily complex workflows for key user tasks.
Disjointed user flows that disrupt task completion.
Inconsistent UX patterns across different sections of the app.
Many Band-aid solutions used causing redesign efforts to be increased.
Conducted a group interview with 16 service engineers to validate initial assumptions from the workflow analysis and gather deeper feedback on their experience using the app and its integration into their daily tasks.
"Service reporting feels like double work. Some clients require multiple signatures, which can take weeks or even months to complete."
"Timesheet entry feels like duplicated work and adds unnecessary effort."
"There is no accessible service history for each company -including who performed the service and what was recorded."
"Limited access or phone restrictions in factories preventing engineers from using the app on-site."
INSIGHTS
Current workflow misaligns with on-the-ground realities.
Inadequate offline support limits real-world use.
Users find that the app fails to reduce cognitive load.
What are the user's needs?
Industrial Service Exchange platform serves a diverse range of users across multiple roles. Core users include Service Engineers, Service Requesters, and Ticket Managers.
As the platform evolves, there's ongoing discussion around expanding its scope into a service carousel - where external vendors can advertise and offer their services. Therefore, our persona definitions must remain flexible and inclusive, also accounting for External Service Providers and their employees to ensure a seamless and scalable user experience.
Service Engineer
Primary maintenance service provider, acting as lead or support in a service request.
Ticket Manager
The ticket manager monitors and assign support tickets created by service requesters and will be the middle man between requester and provider.
Service Requester
They are basically clients of Siemens that needs maintenance or repair services for their machines in the factory.
External Vendors
The External Vendors are service providers that are not from siemens. They will be using the platform to advertise their services, which requesters can seek service from them.
DESIGN GOALS
The research and reviews helped me define the areas of focus for the platform refresh.
PROCESS
Design Methods Approach
I adopted the Lean UX methodology for this project, as it was best suited to the current development environment. Lean UX allowed me to move quickly by making assumptions, testing lightweight prototypes, and iterating rapidly - despite limited access to end users and tight sprint timelines.
Design Constraints
Skipped Low-Fidelity Wireframes. Most wireframes are move directly into high-fidelity design apart from initial proposal due to tight deadlines.
Limited Time for Iteration. Short sprint cycles required fast turnaround and quick visual clarity.
Stakeholder Preference for Visuals. Stakeholders preferred polish high-fidelity screens for clearer communication and faster feedback.
Ongoing Legacy Development. The legacy system was still being actively developed during the redesign process, creating overlap in design and production.
Limited Access to Users. Service engineers were often unavailable for user interviews or testing. making early-stage validation difficult.
DEFINITION OF FEATURES
Given the large number of existing features in the legacy product, I collaborated with the project lead and manger to categorize them using the MoSCoW method (Must-have, Should- have, Could-have). This helped us focus on solving the most critical user pain points first while ensuring that essential functionality was addressed early in the redesign process.
Platform Environments
Service Provider Environment
Service Requester Environment
Ticket Manager Environment
Since Service Engineers are the primary users and faced the most friction with the existing product, we prioritized redesigning the Service Provider environment first. The Service Requester environment shares a similar structure with slight workflow differences, allowing us to reuse and adapt features from the provider design - streamlining the overall design and development process.
Must Have
Service Request Acceptance Process
Service Request Progress Process
Productive Time Tracker
Service Request Completion Approval
Media
Should Have
Timesheet logging
In-app notification
Historical records
Account settings
Comment section
Could Have
Dark mode
Feedback System
Won't Have
Marketplace carousel for external venders
Multi-language support
USER FLOW
I developed a new set of user flows to streamline existing feature processes and to strategically map out future flows for upcoming features, ensuring consistency and scalability in the overall user experience.
LOW-FIDELITY WIREFRAMES
Done for the initial proposal, starting with a dashboard for ticket and service ticket progress checking.
INITIAL DESIGN REVIEW
After completing the initial low fidelity wireframes, I tried to get access to the primary users of the app. However as they are unavailable, I did the design review with the lead and project manager to go through my initial design intentions and to get their feedback. Below are the findings acquired:
Project lead pointed out all the design restrictions within the application.
Currently dashboard should not be prioritized due to the time restrictions.
There should be a list where users can get an overview of all the tickets.
Start on high-fidelity immediately due to time restrictions.
SELECTED LAYOUT
A 30 -70 split layout was chosen to optimize readability and space efficiency
After the initial design and layout were selected, I advocated for progressing through a mid-fidelity workflow. This allowed me to further explore and iterate on smaller UI elements that still require refinement. It also gave me the opportunity to define finer interaction and visual details before moving into a final design review, ensuring alignment and quality before high-fidelity execution.
DESIGN GUIDE
LEGACY DESIGN VS CURRENT
FEATURE - SERVICE PROVIDER JOB LISTING [ACCEPTANCE]
The listing page provides a comprehensive overview of each service ticket assigned to the lead engineer. It consolidates key information such as the overview, service timeline, attached media, service history, and comments - offering clear and organized view of the service process from start to finish.
NESTED FEATURE - TABS
Overview: Displays key information about the service request at a glance, giving users a quick summary of the ticket details.
Timeline: Tracks the progression of the service request, showing both past and current stages for clear visibility of service status.
Media: Stores all supporting media - document, images, and videos - submitted by the requester for reference and documentation.
History: Archives all past service reports for the factory or plantation, providing engineers with references to similar issues for faster troubleshooting and context.
Comment: Facilitates communication between the requester and provider, ensuring transparency and accountability while helping prevent discrepancies.
REQUEST ACCEPTANCE WORKFLOW
Entire process for request acceptance based on the user flow that was created
SERVICE TICKET CARD
With an overview tab displaying all the information regarding the job information, I can remove them from the card itself and place in more useful information that the engineers can use.
Tabs indicators: Used to display the type of service request and engineer role, and can also function as filters for easier navigation and task management.
Engineer Avatars: Display profile pictures to indicate the number of engineers involved in the service request at a glace.
Urgency Level: Indicates the priority of each ticket, helping engineers identify and address high-priority request first.
Requester Company
Date Created
FEATURE - SERVICE PROVIDER JOB LISTING [IN PROGRESS]
This section displays all tickets that have been accepted by the service engineer but are still open. Since some cases require multiple visits or extended work periods, this serves as a centralized space where engineers can easily return and resume progress on incomplete service requests. This page will still gives all the information that was previously provided
NESTED FEATURE
Task List: Used by service engineers to log tasks performed and track time spent, ensuring greater accuracy and accountability in service reporting.
Summary Report: Allow engineers to input final service details and generate a report for the requester to review and approve. This step is critical, as it directly impacts billing and monetary transactions.
NESTED FEATURE - TASK LIST
This feature is the key part of the service engineer's workflow, allowing then to track the time spent on each service request accurately. Engineers are required to start the timer when they begin on-site work.
Problem Solved: Previously, users had to manually press separate "Start" and "Pause" and "Stop" buttons like a video player, which caused confusion - particularly because the button state did not update visually, leading to uncertainty about whether the timer is was running.
Fix: Simplified the interaction by introducing a single toggle button that switches between "Start" and "Stop" states, providing immediate visual feedback and reducing user error.
Additional functionalities: Lead engineers can now assign support engineers to the task - an essential enhancement for requests requiring collaboration, ensuring transparency in time tracking and responsibility.
The Task List also acts as a gatekeeper in the workflow - all open tasks must be completed before a service engineer can proceed to the final step of the service request, ensuring that no steps are skipped before submission.
"Create Summary Report" is disabled when there are on-going tasks
EDITING OF TASK & ASSIGNING ENGINEERS
Task editing and support engineer assignment workflow based on user flow
NESTED FEATURE - SUMMARY REPORT
A crucial part of finalizing the request, this is a structured 4-step process that service engineers must complete in order to submit the summary report for approval.
Man Hours Review
Summary Report
Report Review
Authentication
MAN HOURS REVIEW
Review the man-hours recorded in the Task List. Engineers can make limited edits to ensure accuracy before submission
SUMMARY REPORT
Engineers document key details of the service provided - problem observed, resolution steps, parts used, and attach any relevant media.
REPORT REVIEW
A final review step that consolidates all previous inputs, allowing the engineer to double-check for errors before proceeding.
AUTHENTICATION
A final review step that consolidates all previous inputs, allowing the engineer to double-check for errors before proceeding.
MANUAL TIME ENTRY & EXPORT
Used by engineers to log man-hours that couldn't be recorded via the Task List. This feature also allows them to export recorded hours for timesheet submission - streamlining a process that was previously done manually.
COMMENT SECTION
Facilitates communication between the requester and provider, ensuring transparency and accountability while helping prevent discrepancies.
ACCOUNT SETTINGS
A standard settings page that includes a schedule overview, allowing engineers to easily check their upcoming assignments and availability.
FEATURE - SERVICE REQUESTER [REQUEST CREATION]
This section of the app is accessible only to requesters. It organizes all service tickets into three categories - Pending, In Progress, and Closed - providing a clear overview of the request status and history.
NESTED FEATURE - TABS
Since the service provider and requester environments share similar features, we were able to reuse components from the service engineer interface - removing elements that are not relevant or accessible to the requester.
Overview: Displays key information about the service request at a glance, giving users a quick summary of the ticket details.
Timeline: Tracks the progression of the service request, showing both past and current stages for clear visibility of service status.
Media: Stores all supporting media - document, images, and videos - submitted by the requester for reference and documentation.
History: Archives all past service reports for the factory or plantation, providing engineers with references to similar issues for faster troubleshooting and context.
Comment: Facilitates communication between the requester and provider, ensuring transparency and accountability while helping prevent discrepancies.
REQUEST CREATION
Process for requester to create and send in their maintenance request.
REQUESTER APPROVAL PROCESS
One of the key differences in the requester environment is the relocation of the completion approval process. Originally part of the service provider flow, this step was moved to the requester side based on the following insights:
Delayed approval on-site: Engineers reported that approvals were often delayed due to the requester's unavailability during or after the service visit.
Feedback bias concerns: Since part of the approval involves providing feedbacks on the engineer's performance, having the requester fill this out in the engineer's presence could lead to biased or uncomfortable responses.
Improved flexibility: Allowing requesters to approve the job and submit feedback remotely enhances convenience, reduces pressure, and improves the overall experience for both parties.
KEY TAKEWAYS
Reflection on the project outcomes
This redesign project involved modernizing a complex 8-year-old legacy system. I conducted a UX audit, proposed usability improvements, and collaborated with stakeholders to align on design goals. Although the project was ultimately halted due to high-level business decisions, the redesign solution was well-received - especially by the engineers, who were enthusiastic about the improvements after testing.
Designing for legacy systems require balance between innovation and constraint. I learned how to modernize a product while respecting long-standing workflows and technical limitations.
Stakeholder alignment is just as critical as good design. I realized that even strong design solutions can stall if leadership priorities shift or long-term fatigue exists.
User-centered thinking must navigate business realities. Despite completing the redesign, I saw firsthand how organizational decisions can override user-focused outcomes.
Documentation and communication are vital. I ensured all research, insights, and design rationales were well documented to preserve value in case the project resumes.
Resilience and adaptability matter. Working on a paused project taught me to stay outcome-focused while being flexible when things are out of my control.
