I designed work support cart touchscreens and overhead TV screens as part of a centralized issue reporting platform.
⚠️ Note Before Reading
Product Requirements
Each device we designed for had its own use case.
🛒 Work Support Cart (This Project)
📺 In-Cell Overhead Screen (This Project)
📱 Mobile App
💻 Desktop
Work Support Cart
Overhead TVs
My designs coming to life!
What's the problem?
The problems with the current workflow are as follows:
😡 Manual and Tedious
😡 Reliance on WhatsApp
😡 Unclear Communications
😡 Lack of Countermeasures
Who are our target users?
For the work support cart and overhead TVs, our main target user group was Production Technicians working on the production floor. They either assemble the EVs or controlling production cells, who have to report issues from the production line.
Let's interview users…
From interviewing the Production Technicians, we got to understand their key motivations and pain points.
Technicians
Motivations
Want to quickly and efficiently report issues to relevant PICs without disrupting the production flow.
Want to view real-time updates on the status of reported issues.
Want to minimize cell downtime caused by delays in assistance.
Pain Points
Manual logging methods interrupt work and waste time; overwhelming and messy WhatsApp chats.
Lack of clarity about PICs leads to delays in resolving issues.
…and gather additional data
Throughout multiple workshops during the first two Agile sprints, our team gathered data of 100+ escalation processes from our users. Each issue was assigned a name, code, category and PIC.
Visualizing user flows
I mapped out a simple user flow of a user reporting an issue with the cart.
Sketching wireframes!
Afterwards, I drew up a quick wireframe sketch to show my design mentor.
Mocking up hi-fidelity screens
Using components from the existing design library, I was able to quickly make high-fidelity designs of the different work support cart touchscreens during one Agile sprint. I handed over the designs to the front-end engineer to deploy on ThingWorx.
Scoping the product
From the first user interviews and existing desktop open issue dashboard, I drew up an initial list of information fields that the overhead TV screens should contain. Throughout rounds of consulting with project managers and users, this list got shortened as lower-priority fields were removed.
Iterating and getting feedback
Below are the key iterations I made for an open issue card, the basis of the open issue dashboard, before arriving at the final design. After each iteration, I reviewed with the product team and took note of additional changes to be made.
Arriving at a hi-fidelity design
I finally designed the open issues dashboard for the in-screen overhead TV screens which were deployed on PTC ThingWorx.
What did our users think?
In order to familiarize our users with the new work support cart and overhead TV interfaces, we ran multiple dry runs and workshops where we installed the created PTC ThingWorx sites on the devices. User feedback was largely positive regarding the interface design and user experience.
😊 Positive Feedback
Users felt the cart interface was intuitive and that the buttons were big enough for the touchscreen.
🤖 Technical Issues
Users reported a lag between issue reporting and showing up on the open issues board. (Tech issue)
🗯️ Suggestion
Users suggested that they should be able to leave comments on reported issues from the work support cart.
In response to that last user feedback, I redesigned the confirmation modal of the work support cart to allow users to add optional comments before double-confirming the report.
After this improvement, users reported that they were more satisfied with the user experience for the work support cart touchscreens.
Parting takeaways
This project was an exciting venture into designing for alternative device types: work support cart touchscreens and overhead TVs. I found it interesting to consider the affordances and use cases of different device types. Of course, it was super satisfying to watch my designs be deployed!
🫵🏻 Designing touchscreen monitors
I learned that touchscreen systems may require larger fonts and buttons to accommodate specific use cases, such as technicians wearing their work gloves while reporting issues
👯♀️ Working cross-functionally
Since the engineer deploying my designs was in our team, I did not prepare formal hand-offs as I would to an external dev team. We could collaborate in a more relaxed way!