Issue Management
Closing the loop on issue capture, tracking and resolution
The Company
Poka is a connected worker platform built specifically for manufacturers, and trusted by major players such as Kraft, Nestlé, L'Oréal, Bosch, Johnson & Johnson and TetraPak.
The Context
September 2020. Poka launched a game-changing feature : Forms & Checklists. Such documents are widely used in factory settings for all sorts of purposes, and going paperless was bound to make it easier to capture consistent data on work execution and identify deviations.
The feature gained instant traction : in the first 6 months alone, over 100 000 forms were completed, and some clients have reported time savings of up to 20%.
The Problems
While the sheer number of completions was great, filled out forms became rapidly lost. The resolution loop was a bit stunted : issues would be identified and logged into Poka by operators or managers during form completion, but they often had to be handed over to mechanics for execution. And the means of relaying and tracking that information remained the same - work order softwares, white boards, 2-way radios, emails, Excel sheets, etc.
The Objectives
Closing the loop on issue capture, handover, resolution and feedback so that all the relevant informations remained inside Poka.
My Role
I was the sole designer in charge of the Ux and visual design of this project. It was developed on iPadOS, Android and Web apps.
Starting Point · One Big Question
As we got started, an important thing came into focus : work order management softwares are prevalent in most factories, they were robust, efficient and typically, mechanics relied heavily on them for jobs to be done.
So early in the process, we had to take one crucial decision : should we try to compete with these existing systems in order to migrate mechanics to Poka, thus engaging new users?
Or, should we integrate with other systems and focus on creating value for managers instead, so that we increase engagement in existing users?
Discovery Phase
The first objective of the discovery phase was to truly understand the issue resolution loop. For that purpose, we had a few questions to address :
What types of forms generate the most issues, and which ones would best fit our objectives?
What are the current tools and processes in place? What works with them and what doesn't?
To answer these questions, Gaëtan - the PM - and I designed a survey that was sent to our Beta Testers group of 39 people, composed mainly of plant & line managers, HR and CI people.
Based on the results and interest from our group, we then conducted interviews remotely with Mars Poland, Danone Netherlands and Bosch USA. We also analyzed our product backlog and feature requests boards.
Survey + Interview Results
The survey graphs revealed trends from which we were able to extract interesting data.
Line start-up, handovers, Gemba walks and CIL forms were the most issue-prone by far.
The volume of issues found everyday was astonishing : between 25 and 50 on average, sometimes way more - up to 150.
Most clients used white boards effectively for visibility on ongoing issues, but they also had to manually enter all this data into Excel sheets every day for tracking and audit purposes, and emails were still wide-spread.
It also confirmed the importance of work order softwares, and during interviews, managers did show reticence to changing tools.
Affinity Mapping
We gathered insights on post-its in Miro, and proceeded to regroup the themes that were similar. It helped shed some lights on the main pain points :
We already had a notification option on form templates, but users complained that it wasn't simple to set up nor precise enough for their needs.
Even though we were seeing some creative hacks on using Poka to promote visibility on issues, it required a lot of effort to make it work.
Mechanics were typically our toughest crowd, and it didn't seem like we could easily changed that. This reinforced the idea that competing with existing system would be very risky.
Moving Forward
At this point we had painted a pretty clear picture of the current resolution loop and what were the gaps that we could address with Poka. I dived into design exploration with these HMWs in mind :
How might we close the gap between operating and maintenance teams, and avoid the endless duplication of data?
How might we close the gap between floor and office workers, and allow better tracking and data extraction?
Exploring Threads
We already had a ready to use module in the factory feed section of the app, threads, which were actually side-discussions between any numbers of users. It was entirely plug & play, it was pretty simple and we had a few clients who had already worked out sucessfull integrations with others systems like SAP through Microsoft Power Automate and Zapier.
The trigger could be set on tags, so that when a certain tag is used, the information contained in the comment would be sent to a third party, and then back to Poka if/when events were triggered back.
It allowed direct communication with mechanics and integrations with work order system, and it was a low-cost, flexible solution. However, it didn't really solve the second part of our problem : how could we translate the content of threads into future actionable insight? And it could hardly evolve into something that would replace white boards for visibility. We needed something more scalable.
Exploring Tasks
We also already had a task module attached to the factory feed, but it was old, underused and full of dirty legacy code, so revamping it would be costly to begin with, and easily subject to scope creep.
But it was pretty much the definition of what we needed to accomplish : by providing a ticketing option into Poka, fields could be easily transposed into a third-party and back. It could even replace work order systems altogether if some smaller clients were willing to make the move.
Dashboards were definitely not an option that we considerer for the MVP, but the possibilities for task management were endless, and we could even begin with a low-key task section.
Triggers & Notifications
Another aspect that I had to think of was the timing and location of the trigger. Notifications were sent on form completions, and linked to the form as whole, but what about threads or tasks? Would they have to be submitted in real-time, while the form in still being completed and thus not visible to the assignee? Or could that wait until form submission?
How many issues could be found in a single form? Pretty much anywhere from 0 to dozens, so how would they cohabitate? How can we make it simple for the assignee to easily understand how a task is linked to a certain problematic field or area?
Also, it didn't make sense for a trigger to be related to some type of fields like e-signature or dates, or some general forms like emergency procedure in case of fire, so we had to carefully think of the admin configuration of form templates so that it made sense in every case.
Visibility & Tracking
As far as visibility was concerned, it was made clear by our clients that they needed and overview of the problematic areas. So there needed to be an indicator of ongoing issues at least on the production line level, as well as the equipment level.
I also toyed with the idea of having an indicator of ongoing workload on the profile of mechanics, but it was scoped out for the first iteration. But the idea of having the list of tasks at hand in every colleague's profile rapidly became more than a nice-to-have.
Final Solution
Here is a glimpse of what the final iteration looked like on the iOS app - designed for iPad but fully responsive for iPhone.
Results & Takeaways
Tasks in forms were released in October 2021. In the mean time, two other teams had launched two other important add-ons as well, Scheduling and Conditional Logic, so altogether, a lot of value was added to the MVP of Forms that year.
So, it might not be entirely imputable to our work on Tasks, but we saw some really interesting improvements.
The number of filled out forms skyrocketed to reach 1M+ by January 2022.
Over 12 000 tasks were created in the first 3 months, and about 70% of them were marked as Done, so most had some sort of follow-up on them.
We sent a follow-up survey after the Christmas holidays, and found out that about 20% of our clients were using the feature as a standalone, and 35% were using some sort of integration to connect Poka to their work order tools. It did often necessitate some intervention on the CS side to set it up properly, but they learned quickly and we got mostly positive feedback.
Moving on, we started exploring more statuses as it was heavily requested. We also started working on a Kanban board view of issues.