A connected B2B application that monitors customer’s overall machine performance and production output.
Notify is a Netzsch connected app that connects directly to their machine gateway and monitors the machine’s health and production output. Customers who purchase Netzsch’s machine can perform remote monitoring anytime, anywhere. There are 2 different apps - Customer App and a Service App. The service app is for Netzsch to manage customer features and machine configurations. Netzsch's desire to scale up the MVP app and improve on the user experience to increase user adoption.
Also see Production Monitoring System UI Redesign.
Project date: May 2021
One customer can own multiple milling machines with different production (Eg. 2 machines mill red paint, while 3 other machines mill white paint depending on the demand). Each machine is then hooked up to a gateway that sends machine data to the app. The customer can then manage and monitor the production output, the machines’ health, and production frequency via the app.
Making navigation intuitive is a must-have for any SaaS application as this greatly impacts the user experience. Here, my first step to improving the app was to resolve navigation issues and rearrange the features base on the information hierarchy. After mapping the initial customer app, I realised that there was an overuse of tabs to divide different states - which seemed unnecessary. It also posed navigation problems when trying to scale-up the app because secondary features were competing for real-estate with primary ones. To solve this, I created a 3-tiered system where one could see the full overview of features based on their relationship with each other for the ease of navigating through the application.
The service app is an internal app for Netzsch’s service engineers to manage feature permissions, customer accounts and configuration of machines and gateways. Within the app, each machine is linked to a gateway, which is owned by a customer. The engineers can remotely manage configuration settings of the machines from the app. As all 3 types of content are interlinked and will show similar information regardless of which type the user chose to view, it is better to group them all together in a single dashboard and provide the user a choice to view by type. This allows the app to scale easily when adding new features such as “support ticket management” or “data-analytics”, making it a feature rich one-stop-shop application for feature management.
Based on the site map, I identified multiple areas of redundancy and decided to consolidate the features into a single set. This reduces confusion and allows the user to focus solely on what’s required: configuration.
In the initial app, content state are separated into 2 different tabs. The creation flow (adding user), it was utilising a full screen with very few entry fields. Using a full screen that locks the user in, can be disorientating for users since it’s a completely different styled page that requires very minimal action.
The proposed screen was essentially taking the as-is screens and improvising it to flow better- Such as combining state types in a single table view that displays all types of information allow user to monitor and have a better overview. Another proposed option was to have a collapsible table row that will expand to reveal more information about the user such as permission types and production line that they are assigned to. This solution only applies if the user information is limited and can be all displayed in a single row.
The other improvement was to make the add-user flow a modal. With minimal entries required, the user needn’t re-route to a whole new page.
Customers were requesting for a feature that allows them to set specific notification parameters to monitor their production batches. I quickly sketched out a simple storyboard to demonstrate how this feature would play out in reality.
Currently, production operators have to stay by the machine and wait to take a sample of a batch to ensure everything is running smoothly. However, this is not very productive. With the notification set with specific parameters in place, the user can go about running other tasks.
In the exploration phase, I hypothesise 3 different feature readiness with different set of sub-features and user stories to go with it. I also conducted customer surveys to gather what would be a value add to them base on the drafted ideas. I then presented these ideas to Netzsch for their input.
I would like to be notified when it is time to take samples in between milling, in order to confirm the batch is done and proceed with the discharge without waiting by the machine.
The MVP feature aims to meet the basic needs alerting the customer for taking quality samples ONLY. It functions as a basic reminder feature for the customer.
I would like to have a an analysis of all batches to give me insights on how to optimise my milling processes and improve consistency in the product quality.
This collective feature aims to go beyond the basic reminder and functions as a targeted historical record keeping for all quality samples for customers to monitor, track and make tweaks all within the notify app.
I would like to have a historical record of past samples or data of each batch to help trace quality issues of the product.
This bonus feature aims to give customers insights and analysis of each quality sample taken and provide a more predictive model that can help improve future milling processes base on environmental contributors/ seasonal/ specific brand ingredients etc.
During a call with both customer success and onsite service engineers who service customers, we gathered direct feedback from end-users by presenting them the list of features and the concept user journey flow. This is to gauge their interests and to get a better all-rounded understanding of their needs. After presenting the 3 ideas, the feedback that we got was that operators needed to set up notification for all sorts. If the product can cater to a more generalised purpose, it would have a broader use case that would be more useful for workers on the ground than only taking quality samples (which doesn’t occur too frequently in comparison to other needs for a notification/ reminder).
Other insights also included:
.svg)
I would like to set custom notifications during a production cycle to help me manage multiple tasks efficiently.
I would like to produce a new product. However, I will need to experiment for a bit in order to obtain the right controls for optimal product quality.
Netzsch has 2 types of machine-IRIS and standard machines. Each machine type has a different configuration requirement.
Features include:
.svg)
Features include:
As I joined the project midway after the launch of the MVP app, I was tasked to help with cleaning up of the design and match the company brand. I evaluated the old screens to make consistent improvements to them- setting UI display rules and case scenarios to help the frontend and backend engineers when they decide to do a full application reskin. Below are some sample screens of the initial MVP along with notes of design improvements that the application could use without too much code overhaul. I also took into consideration of utilisiting the material library that they have implemented to refine those designs accordingly.
I started sampling the company’s website and the UI from the IRIS HMI screens and put together the best possible colour palette that is still recognisable to the original brand.
I played around with colour matching and designed options for both primary and secondary navigation bars.
After a few more explorations and discussion with the Netzsch team, it has been decided to adopt a smiliar look to the IRIS machine’s HMI for relatability. Other areas of exploration are the interaction behaviour of UIs on various screen sizes as well.
As I joined the project midway after the launch of the MVP app, I was tasked to help with cleaning up of the design and match the company brand. I evaluated the old screens to make consistent improvements to them- setting UI display rules and case scenarios to help the frontend and backend engineers when they decide to do a full application reskin. Below are some sample screens of the initial MVP along with notes of design improvements that the application could use without too much code overhaul. I also took into consideration of utilisiting the material library that they have implemented to refine those designs accordingly.
