Copia Automation brings modern developer tools to the industrial space. Its first product, Source Control, offered the industry’s first Git-based change management solution for programmable logic controllers (PLCs). It allowed engineers and technicians to easily view and collaborate on their code in a web browser.
That said, users of Source Control still needed a way to see and manage the industrial code that was deployed to the plant floor. My role in this project was to facilitate the end-to-end product design for Copia's solution, DeviceLink. By collaborating with internal stakeholders and facilitating feedback from external beta testers, I led the design of an automated backup solution for PLCs, robots, and other devices.
End-to-end product design User research UI work
5 × engineers 1 × product manager
Studying Users and Their Behavioral Patterns
To start, we knew it was crucial to connect with active Source Control users to understand the strengths and weaknesses of our initial product. So, for about 6 weeks, we surveyed 13 active users across 12 locomotive accounts, selecting interviewees based on factors like contract value and subscription type.
For each interview, I used a scoring system to track feedback and requests in a master spreadsheet. This data would later play a crucial role in shaping the DeviceLink roadmap within our issue tracker.
Beyond just serving as a conduit to user feedback, the interview process also provided valuable insights into our users’ day-to-day duties on the industrial plant floor. This enabled us to identify and categorize specific user types that we needed to cater to — which, as we quickly discovered, went far beyond simple demographics like “systems integrators” or “automation engineers.”
Altogether, we identified three key user types:
- Providers: who focus on establishing standards and bringing structure to their teams
- Enforcers: who ensure work is accomplished and projects are completed according to these standards
- Consumers: who rely on the established frameworks to contribute code and maintain factory operations
Creating this taxonomy not only allowed us to put users at the center of our development process, but it also provided us with a means to validate that we had product market fit once DeviceLink reached GA.
Understanding Specific User Needs
After identifying the user types we were targeting, our focus shifted towards analyzing the feedback we received and extracting our users' primary pain points.
We came to realize that most Providers and Enforcers — which commonly imply controls engineers and systems integrators — lose track of changes made to programs once a machine is deployed to the factory floor. Engineers are preoccupied with hardware and machine maintenance and just don’t have time to maintain software or minimize code vulnerabilities.
DeviceLink needed to help solve this problem by providing a software solution that could automatically back up control programs to a centralized location while also providing up-to-date visibility, change traceability, and code security. Even more, it needed to make it easy for Enforcers and Providers to set standards, and for Consumers to practice good quality control. And most importantly, the product had to be simple to configure and use so that engineers could focus less on learning new software and more on understanding what code changed and why.
Establishing a Product Architecture
After these external conversations with active Source Control users, as well as numerous internal white-boarding sessions, we developed a setup experience that could work for DeviceLink. Providers or Enforcers would need to first create a site — a factory or larger area within a plant floor — and then configure the following assets under that site:
- Project: A pointer to a specific automation project
- Device: A hardware device that a project is backed up from (PLC, robot controller, etc)
- Agent: A lightweight bit of software that performs backup requests
- Job: A scheduled operation that performs a backup and comparison of the project to what's on the Copia server
With this scheme, organizations could have multiple sites without needing to pay for several instances of DeviceLink. This was an important product requirement for some of our larger enterprise customers who had several dozens of sites to manage.
Creating a Design System
We had to build DeviceLink efficiently – and fast. To ensure successful development, I established a scalable design system and workflow between the Design and Engineering teams, which involved creating mockups in Figma and sharing them with engineers through Zeplin. This method allowed for asynchronous review and feedback, keeping us agile and minimizing design and engineering cycles.
Developing an Intuitive Interface
To provide a memorable first impression for DeviceLink users, we made sure that launching into the product was seamless. We decided to integrate DeviceLink into the Copia dashboard and intertwine it with the pre-existing Source Control experience. This way, Providers and Enforcers had a cursory overview of their site activity, and Consumers had the freedom to manage their site assets and view the status of their job run history before even entering into DeviceLink.
Clicking on a site would navigate a user into the DeviceLink product, where they could dive into their automation activity in more detail.
Controls engineers are pressed for time and they just want to see their information clearly. We visualized all projects, devices, and agents for a given site as cards, with most fields based on MUI components. This enabled Copia's developers to implement designs quickly, and DeviceLink's users to sift through and edit metadata efficiently.
In tandem with the agent cards, I designed a simple electron app that would run in the system tray of the local machine on the manufacturing network. This small app is crucial for Providers and Enforcers who are in charge of managing agent setup, and is especially relevant to Consumers who have to monitor the status of the local machine and the Copia server during project backups.
Finally, jobs are the core feature of DeviceLink, as they enable advanced scheduling capabilities that are vital to the product's functionality. Scheduled jobs can be set to run at one of three intervals:
- Daily: Job runs every day at a given time
- Specific day(s) each week: Job runs on requested days at a given time
- Custom cron schedule: Job runs on a complex cadence informed by cron syntax
Elevating the PLC Programming Experience
DeviceLink received highly favorable reviews from a wide range of customers and we watched it become an integral part of workflows across several automation sectors, including automotive, manufacturing, and food and beverage.
“Regardless of how much equipment we're managing and how many sites that equipment is spread across, DeviceLink shows us all the live control code in one place. We always have up-to-date restore points in case of failures and are proactively alerted to unauthorized changes."
Through our metrics and continued engagement with active users, we were able to identify the following gains that resulted from DeviceLink:
- Saved Time: By accelerating code reviews and backup processes, senior engineers were able to reclaim up to 8 hours per week
- Increased Quality: Automated PRs allowed controls engineers to review code more thoroughly
- Minimized Downtime: Any inevitable disasters on the plant floor could be traced to specific code changes, thanks to rung-level highlighting provided by DeviceLink
Between the launch of DeviceLink and my eventual departure from Copia, I continued to gather and analyze user requests, design mockups, incorporate developer feedback, and push the product experience towards higher quality standards.