Redesigning Cloud App – A UX-Driven Industrial Configurator
Cloud App Configurator is a powerful tool for engineers to customize industrial solutions, but its complexity led to usability challenges such as difficult navigation, unclear workflows, and lack of real-time guidance.
Through a user-centered redesign, we transformed the experience by:
-
Streamlining complex configurations with a guided, step-by-step approach.
-
Enhancing navigation and information hierarchy for faster decision-making.
-
Integrating real-time previews and AI-driven recommendations to optimize selections.
The new design improved efficiency, accuracy, and user confidence, making industrial configuration in the cloud more intuitive and seamless
What is an Industrial Configurator ?
Industrial Configurator allows mass deployment of configuration files to apps installed in multiple different Devices. This app is installed in the Management system and enables easy configuration of apps running on Devices on the factory shop floor.
Why this Redesign ?
We received comments from our customers on usability issues on the existing implementation of this application but we could manage to fix few things temporarily with old design system as the template is not scalable. Now that decision is taken to migrate all apps to a new design system, I thought this would be the right time to address the issues and propose a new design aligning with new design system.
When I was going through the user journey of the current version of the application I stumbled upon various aspects. As a user I had to do tasks like device selections multiple times on every operation, many instances I may select the same devices for multiple operations also so this made me put more effort into searching, sorting and selection of devices on every operation and every session. Out of a long list of available devices, selection of devices sometimes frustrated me as most of my time went into it.
Even after the deployment was performed, I had to go to individual operation types to look for specific device status. Had to switch back and forth multiple times to know about the status of individual devices. Even to know the status of devices I had to spend equal amounts of time as device selection. I even faced trouble navigating through the operation tabs to check which device failed in what operation.
When the deployment fails for any device, I wish to quickly know the reason for the failure but with existing applications I can only know the deployment status but not the reason for the failure. Also the design is outdated with old templates.
Goals and Motivation for the Redesign
1. To deliver personalized experience with intuitive user experience
2. Streamline the user journey and propose a seamless experience so that the user is comfortable accessing our application
App Analysis
Since I already had access to the application I spent some decent amount of time playing around with it as I wanted to understand the functionalities, architecture and navigation.
Through the analysis I was able to identify some clear usability issues and pain points. I listed all of them to validate after User research.
Note : Due to company policies I am not allowed to provide any of the application information on an external platform. So I made a draft sketch to give a brief visual understanding of the existing implementation of application
Understanding the users through User Interviews
Conducting User Interviews
I started my user research by conducting interviews with 7 users, which vary from domain to domain. As I don't have direct access to talk to direct users. Had to consider my sample from the Deployment team, Operations team, PPM’s ( who get the direct feedback from customers ) and Product owners and Architects.
I conducted Microsoft Team interviews with PPM and Deployment colleagues ( as they are from Germany and Austria ) and conducted Face to face interviews with PO’s and Architects. All the users that I have interviewed are male ranging from 28 - 42 years old and female ranging from 32 - 38 years old.
Some key insights from the interview
* All the participants said that few actions are too repetitive when wanting to deploy 3 operations.
* Most of the participants said that there will be multiple stages involved in a successful deployment and there is no provision to view in what step the deployment failed.
* Most of the participants said that they are annoyed in switching multiple tabs to refer to the status of a device against each operation.
* When performing deployment for the 2nd time it is hard to distinguish between the devices that went into initial deployment and for latest deployment.
* Few users feel that the user journey is complicated every time they have to go through the entire process even for deployment of one device.
* Very few users even said that device health information is missing on the UI
The Next was to understand the existing users
Usability Testing
After the user interview, I have asked the same 7 participants to test the application. So I got the local build from the team and shared the link to the participants and asked them to perform the tasks below ( I wanted to do a test with the participants who are familiar with the app ). Entire testing took place both virtual and in person.
Some of the tasks that i gave them during the testing were :
-
Open the application and select 3 devices with 1 operation and proceed with deployment and close
-
Revisit the application to quickly check out the status of 3 device status along with the operation details which were selected in previous session
-
Select multiple operations with 1 device and deploy
-
Asked to upload more than 1 flow or file in operation
Defining the Problem
After analyzing and understanding the pain points through user research, I defined the following pain points that most users had trouble with.
Pain points common to most of the users -
Pain point 1 - Cumbersome process in selection of devices
Multiple users clearly expressed that they would prefer having a common device selection across all operations but it's up to users to prefer either 1 or more than 1 operation for the selected devices. It also learnt that users either can select operation first and then make a device selection or vice versa.
“One common device selection for any operation makes our journey easy”
Pain point 2 - Confusing and cluttered UI
Most of the users complained that the current UI is confusing and cluttered with too much information displayed as part of the device table. It is creating additional cognitive load on a user with the amount of details that the app is currently providing. Too many icons and spacing made it over polluted. Also called out that the UI is so outdated and boring.
“Even to do a simple deployment i had consume irrelevant details”
Pain point 3 - Poor access to view device details after deployment
Almost everybody showed their frustration to have a quick reference to device details after deployment, expectation is to have an entire overview of any device on a single click so that it’s helpful for a user to understand the happenings of that particular device in the latest deployment.
“The moment i click deploy, i felt like i was lost in the journey”
Pain point 4 - Unclear notifications
Users expressed that there many statuses with no labels seen against every device after the deployment. Not happy to rely completely on tool tips to know the nature of the indicator. Also no clear details to know whether the status that they see on screen belongs to current deployment or previous deployment
“Too many indicators on a page losing its relevance”
Needs of the users
Need 1 - Easy and Modern UI with advanced features
Participants expressed that they would like to see the application with modern templates and features
Need 2 - Only show what we need
Users wanted to see or were interested to see only what they actually needed. Isolating information based on user need.
Ideation and Prototyping
Affinity Mapping
Next I compiled all the feedback, insights and pain points listed above and grouped similar ones. This helped me to brainstorm and develop potential ideas and gave a clearer view of what was important to users while keeping in mind the business goals and objectives
Below is the example of a flow when a admin tries creating a workflow by adding 2 Reviewers in Parallel and 1 in Series and later deletes two Reviewers and configures 1 Approver.
Low Fidelity Mockups
For low fidelity mockups I carefully went through the application. After making some observations, I sketched out all possible layout options and outcomes using a tool called Balsamiq. This allowed me to prototype the solutions for the main screens before committing to high fidelity designs
Out of all the layouts that I have tried to address above issues. Below is the one that was freeze and found most suitable.
UX Suggestions and Redesign
1. Addressing “Device detail screen before deploy”
Proposed solution
Device list in left navigation - Providing the easy navigation to view the details of each individual device on a click was my top priority. There I have dedicated the rest of the screen space only to display the overview details on selected devices.
Search and Sort - Assistive features like search, sort helps users to reach the required device in less than 1 or 2 clicks. This helps in either way, to select a device also to view device details. Users can either search with device name, type or status.
Deploy status indicator - Once after the deployment I wanted the user to not get lost in the journey, my motive was not to make the user switch between multiple tabs to know the status of deployment for every device. So provided all the indicators on the left navigation, the user can simply scroll and view the status of devices in one view. In case if there is any failure then instantly the user can click on the device and know more in detail.
2. Addressing - “Configure Operations screen”
Proposed solution
Isolation - Adopted isolation in this scenario, there are different types of operation types and each operator has its own input criteria. One may have just a simple list and others may have a browse feature to import. Allocated dedicated view for operations, in case if we wanted to support more operations in future we can make use of the view. Entire template is designed and planned in such a way that tomorrow if we wanted to add more operations, more devices also template can easily handle it.
Proposed solution
Supporting multiple files - Current implementation for File and Flow operation have just a browse but during the interview process one of the deployment colleagues shared this point about supporting multiple file uploads in future, and received a reply that is in pipeline in next 6-8 months. So introduced drag and drop files feature so that users can easily select all the required files at once and drop on the marked area. This feature helps users to upload more files with almost the same efforts.
3. Addressing - Device detail screen and displaying status after deploy
Proposed solution
F Pattern - Most of our applications follow the “F” pattern which means the user focuses on reading the content from left to right in a pattern called “F”. The current template is designed in such a way considering the F pattern. Once the user clicks on any device the focus point would move from left to right, the first thing the user would scan after a click is “Deployment status” followed by “Device health” rest follows in the pattern
Deployment status tracker - This is again one assistive feature provided to the user. Once the user notices deployment failed “Red” indicator on the left navigation list then user clicks on the device to know more about the reason for failure. Deployment status tracker helps users to know where exactly the issue was, which means the specific stage of deployment along with error code.
Operation details - This is again assistive information for a user, providing operation details captured only from the latest deployment across all three operations and displayed in the device view. In case further if i wanted to display any further device information i can easily make changes in the detail template and fit into it.
Addressing - Deploy logs
Proposed solution
Deploy logs - Once after the deployment, in case the user wants to check the details about the previous deployment there has to be a way. Introduced Deploy logs view, this will help users in further deployments. Deploy logs also reduces the cognitive load to a user. No remembering or repetition of all the operations and device selections that the user had made in the previous deployment.
Deploy ID - Had to speak to the team architect to check whether we have Deploy ID as a part of our database. Luckily we have but we were not able to make use of it in any way. Deploy ID and timestamp helps user as reference points to have a quick check on past deployments.
5. Addressing - Personalisation
“Quick Access” is the real “Game Changer”
Proposed solution
Introduction of “Quick access” in the landing page helps users to quickly refer to the most recent 3 deployments with a link to navigate to its details. Users can click and view the details and modify the device selections and operations and click on deploy. This reduces a lot of time, effort and load for a user.
During user interviews there were discussions on a point once after the deployment, the user may come back to add 1 or more devices or forgets adding a device or operation in the previous deployment in such cases currently the user is going through the entire process from the beginning. I value users' time and wanted to avoid this repetition.
This section also helps user to have a quick visit to the most recently viewed device along with the operation type.
Proposed solution
Deployment record - This is the view that I created to benefit the users based on the previous selections. I wanted to make use of the efforts that users had put on in the previous deployments. So when the user is here, the selections of devices and operations can be retained against the above said deploy id. Users can modify selections ( select, deselect or replace files in operation ) and click on deploy. This will be recorded as a fresh deployment and stored in the DB without hampering the existing deployment details. Idea is to append on top of the existing deployment but not to replace.
Userflows with latest version
New User
Above is the journey for the first time user, as the user can make quick selections of devices then configure operations ( that would be applicable for all selected devices ) and then authenticate and proceed to deploy.
Once the deploy is completed, user can refer the device details on the detailed view
Repeated User
Above is the journey for the repeated user, as the user can bypass the existing flow by referring to the deploy timestamp along with the status and view details. Users can modify the selections from the existing deploy and redeploy again. New deploy id will be generated based on the latest batch of selections and it will append from the existing deploy but not replace the existing deploy selections. This would majorly help users and save a lot of time for those who would like to do minor tweaks on past deployments
Validation Testing
To validate the prototype I surveyed 6 people with my prototype. I gave them just 4 questions on each of the features to test the redesign performance and usability.
I conducted the test in person, 5 of them have already used the app before and 1 is very new to the app who had no prior knowledge about it.
Successes
🙂 🙂 🙂 🙂 🙂 🙂 6/6 users were able to navigate through devices
🙂 🙂 🙂 🙂 🙂 🙂 6/6 users were able to quickly view the device status
🙂 🙂 🙂 🙂 🙂 5/6 users were able to configure operations
🙂 🙂 🙂 🙂 🙂 🙂 6/6 users were able to deploy with the help of Quick access
Failures
☹️ ☹️ ☹️ 3/6 users needed help to authentic device from device detail
What was the main challenge in this project ?
The secondary research, since i have no direct contact with real time users i always have to put our internal employees like deployment colleagues and PPMs into user shoes. I somehow feel that there must be some gap in the communication between users and internal colleagues or maybe my analyzing power in understanding their perspectives. Would have been fantastic to hear the pain points directly from the users.
Usecase on Device Authentication is bit debatable topic here, currently user is providing any random credentials in the backend on a specific device. Team is working to streamline the authentication process accordingly design may get impacted in future.
That’s all from my end.
Thank you for reading !