Overview
Problem
Markel Food Group, a large production company, has a slow maintenance pipeline as broken machine parts must get checked by multiple stakeholders. This downtime is extremely detrimental to the operations of Markel’s customers, who produce perishable goods.
Hunt Statement
How can we strengthen the feedback loop between the product development team, customer relations team, and direct consumers?
Client
Markel Food Group (Personal Project)
Collaborators
Beccy Zhang, Lily Shan, and Caitlin Coyiuto
My Role
Interaction Design, Visual and UI Design, Animation, Research
Duration
3 weeks
Solution Overview
Click play to watch video
Markel Maintenance App
Markel Maintenance App is a mobile service app that allows customers to easily fix their factory machines and communicate with technicians. By making it easier to communicate with the product development and customer service teams this decreases down time, which is extremely detrimental to customers’ businesses. The app also provides analytics on machine health, status, and profits to empower their businesses to speed up production and earn more profits.
By leveraging augmented reality and data collection, factories are able to be more precise with maintaining their machines and are able to detect problems before they happen.
Design Process
Phase One: Discovery
Domain Research
We conducted guerilla research to gain an understanding of the factory production service space as we did not know much about the factory domain. We asked questions like: How are they organized? What are their main goals? What is their marketing like? What are their needs and constraints?
Some Key Points We Found:
Markel is one of the largest baking producers in the US that creates machines for businesses such as Pepperidge Farm
Their CEO defines their unique business plans around “being there every step of the way” for their people and manufacturers
They pride themselves on innovation, customer service, and quality of their machines that create breads, cookies, and pizzas, among others.
Knowing that Markel was open to innovation and customer service , that excited us to approach the next step in making their business run more smoothly.
Phase Two: Stakeholder Evaluation
We then analyzed stakeholders to see what opportunities were out there to improve the value flow among each other.
Stakeholder Map and Value Flow
After analyzing the stakeholders and value flows, we identified possible opportunities for improvement. Looking at how much bureaucracy is involved with the stakeholders to fix, use, and improve the product, we saw there was an opportunity to strengthen the feedback loop between the product development team, customer relations, and direct consumers.
Specifically, there is so much time involved with that feedback loop, that we wanted to focus on minimizing downtime, which is detrimental to operations of Markel’s customers who produce perishable goods.
Opportunity Area
Phase Three: Ideation
Reverse Assumptions
Next we used reverse assumptions to challenge the status quo of machine operators at Markel.
One key assumption that we made was that a technician comes to fix the machines and food producers contact Markel if there is a problem with the machine. The reversal of that is that machines are able to auto detect the problems before it happens. Also, customers are able to fix the machines themselves.
We ran with this idea in the ideation process.
Roses Buds and Thorns
After bringing our initial ideas to our class to get feedback on, we found that everyone agreed that our focus area - of decreasing downtown was a solid idea. They also suggested we should leverage the convenience aspect of mobile (such as scanning) to decrease time even more.
Our team came up with several concepts to help users fix the machines themselves. After discussing, we agreed on the main concept of allowing users to easily fix machines and use data to predict damages and production output for the next work cycle. This decreases the waiting time for a technician to come fix things, and the data allows Markel’s customers to further gain insights on how to increase profits.
Design Principles
Our team then came up with some design principles that the design must have before moving on to the design phase. These were made in mind to cater to our focus area on decreasing downtown in the maintenance pipeline.
Principles:
Self sufficiency: Customers can independently fix machines without Markel
Flexibility: Users can check and use the app in the go or in the factory
Transparency: Users can learn and understand the data to predict breakages and make business insights
Organization: Information on machines should be organized and be consolidated in one place
Phase 4: Design
Storyboard
We then created a storyboard for our concept to streamline the troubleshooting process. The main features included an augmented component that leverages precision to allow users to fix the parts by themselves.
Making the troubleshooting process seamless
To evaluate the problems in the existing troubleshooting process, we created a user journey map to clearly identify why this process takes weeks to complete. In the existing journey, customers and the business have to wait a long time to wait for things to get processed, to get it fixed, and to commute to the locations.
For our newly designed flow for the troubleshooting process, we minimized the back and forth interaction to save more time for the customers. We designed a troubleshooting app where users can fix the machines by themselves, without help from the Markel. This allows them to complete the troubleshooting process in 24 hours, rather than 2 weeks. They would not need to wait for a technician to come look at the problems, however, if customers still cannot figure out the issues, they can call a technician. This short maintenance would be extremely helpful to the customers who produce perishable baking goods.
Wireframes
I then drew a rough wireframe of the process of fixing a machine. After showing this to my group, they gave me some pointers such as the multiple hierarchies with in the machine that I did not account for. So I then iterated the screens again to account for those extra components.
Data Collection
Next, our team thought about what data we could collect to measure UX-related success.
Passive Data:
Looking at how long the app is used on the troubleshooting side of the app can help Markel understand if the instructions are clear enough to follow, and revise the instructions if necessary. A longer
Active Data
Active data collection of machine troubleshooting will point to what machines have constantly had problems and the product development team can use that to focus their energies in improving their own product.
Explicit and Implicit Data:
The machine and its components have a series of metrics that evaluate product or output performance. By monitoring specifics such as air temperature, circulation velocity of the machines, that data can be analyzed to access health of the machine and help predict future breakages or future profits for the customer, allowing customers to understand fully how to optimize the machines.
After thinking through the data collection points, our team flushed out the high-fidelity features of our app.
Features of Final Design
Troubleshooting Guide
Users are able to easily fix the machine with the help of augmented reality to get right back to work and feel empowered. Although the interaction animation is simple, in the future this simple animation could be more complex, as factory workers must be very precise with fixing machines their tools (lever, etc.).
Features:
Users can follow a trouble-shooting guide with clear instructions and animations.
With the help of AR, users use the phone’s camera to validate that steps done are correct.
From our service analysis, we saw that often Markel had to step in and provide help in the smallest of issues, that the workers themselves could fix if they were provided guidance. Therefore, having this guidance through AR can make the customers feel empowered and also decrease wasted time.
Machine Overview
Overviews are provided for each machine. There will be data analytics shown for each component to show clearly why something might break, and the trends to help customers gain insight on their businesses.
Some Examples of Data Analytics Include:
Production outputs
KPIs (e.g. temperature, air velocity monitoring)
Predictions and clear insights of each machine
From our service analysis, we found that customers cared alot about producing high quality goods, so having insights on machine health and quality can help them do that.
Component Notification
Easy detection of broken parts of machines is crucial for the customers to take actions as quick as possible to minimize down time.
Features:
Users get notified when a machine is broken.
Users also see a red blinking warning dot next to machines and components.
There is also a rating for how severe the issue is.
Maintenance Report
Being able to follow up and track maintenance reports eases the customers’ minds in knowing Markel will be there every step of the way.
Features:
Users can track components to know when a new component will be shipped and delivered.
Users and Markel can collect data on the history of breakages and shipments to understand which machines might need replacing soon.
3D and Map Mode
If you are a very large factory, customers may want to use a map or 3D mode to see where they are and to find the components easier to speed up down time.
Features:
Find directions to a malfunctioning machine
Recognize landmarks and find components easily
Hi-Fidelity Wireframe
Prototype
After finishing the Figma design screens, we prototyped everything using Origami. More complex microinteractions (Augmented Reality) was done on After Effects.
How do we implement this?
Let’s consider a use case on making the development of AR: How can we make the machine part in the factory glow when there is something wrong with it? After analyzing my experience making previous AR apps, I tried to think about how I would create one of the use cases in Markel Maintenance.
First, you can use lidar scanning (Polycam is a good tool) to upload an object - in this case it’ll be the specific factory machine. We can then add that specific target on Vuforia as an object and AI technologies will allow the program to identify the factory machine.
Secondly, you will drop the game object on Unity and create the actual effect on the object. For example, using the “emission” effect on unity can create a red glow and you can experiment with various effects on Unity to get the animated glow.
Finally, you can code the “on-glow” effect with C#. The plan for developing this would be for the program to identify the faulty part, and then to “turn on” the effect you created in the previous step on the game object.
Some more AR experiences I’ve made
I love augmented reality and made a couple of experiences using AR when it first came out. I love immersing the viewer in the experience and providing delight to the users in surprising ways.
UI Screens
Design System
Visual Design System and UI done by Me
Reflection and Further Development
This was a great exercise out of my comfort zone to think how a B2B company and factory works. I learned how important utilizing big data is to improve the business and the factory production, when time is extremely sensitive.
To further improve the product, I think having abilities to scan the machines itself (like a QR) to further recognize the machine when on the go can be valuable to further identify the machine and get analysis on the go, especially when there are so many machines
To create a more holistic app, if I had more time, I would like to conduct user research and see what exactly the problems these customers are facing and user test my product.
I would definitely look more into AR interaction design patterns and technical restrictions to refine the AR instructional component more. Right now, the specific example of AR helping with maintenance is simple, and I would like to think about ways to expand and put more complexity into the tasks
I want to design with technical restraints next time. Thinking through the extents of what sensors can do and the extent of how smart the app is to teach you how to fix things is the next step in refining the concept to make the app more realistic.
I want to expand on the severity rating scale and specify what constitutes each rating. I would also like to specify what are the consequences of the having a high severity rating on a machine. Perhaps having a heat map on severity of the machines will allow users to spot what is wrong easily.