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