FACTORYTALK® EDGE GATEWAY
ROCKWELL AUTOMATION | PRODUCT DEVELOPMENT METHODOLOGY: AGILE & WATERFALL
SUMMARY
ROLE.
UX design lead
Visual design lead
User researcher
Copywriter
OPPORTUNITY.
To support Rockwell Automation’s ”Connected Enterprise” vision, the company is well-positioned to help customers connect plant floor data to the enterprise level.
No current product offering exists that allows IT professionals to easily pull data from plant floor assets, curate the data, and deploy it to enterprise-level applications.
HYPOTHESIS.
Customers are eager for a product (software-only) that makes connecting plant floor data to the IT level. They will happily purchase this product, which will help them reach their IT-OT convergence goals.
AN ADDED CHALLENGE.
Unfortunately, I didn’t become engaged with this product before a prototype had already been developed by an R&D team in Rockwell’s Common Architecture and Technology (CAT) organization. This team’s purpose was to create a proof of concept using their underlying Common Gateway Protocol (CGP) communications technology. The primary sources of input had come from customer boardrooms and less so from users themselves. But it was plain to see that there was a major opportunity with this technology and a solid hypothesis. Eventually, business leaders in Software & Control (my organization), which productizes software technologies, caught wind of the innovation, partnered with the CAT organization, and scrambled a team to champion it as a product, as the CAT organization—while talented—did not have the experience or skills needed to productize the technology.
Another complicating factor: senior leaders wanted a build that was “on the path” to productization within just a few months from a product team becoming engaged, as they desired to demo the branded product to customers and partners at Automation Fair in 2019. Therefore, I was brought in as a UX leader to cobble together the various pieces and parts and construct a vision that would take the best of the existing workflows and technology and make it feel like a harmonized offering from our greater portfolio. Below, is the journey I took to help turn FactoryTalk® Edge Gateway into an industry-leading and award-winning product in a short amount of time.
EXISTING MATERIALS
(What I had to work with)
The team had created basic views, had underlying comms protocol, an established tech stack (built on Google Material), and a hypothesized workflow. Additionally, leaders on the business side had already had several discussions with customers and assumed hypotheses.
The prototype/proof of concept lacked a cohesive, comprehensible workflow that would simplify a user’s tasks. Moreover, the unique-selling-proposition of this product was to make connecting OT data to egress enterprise (or IT) applications feel simple. In it’s initial form, it was certainly not simple, and lacked other visual affordances and styles we were starting to standardize on as part of our design library (built on Google Material).
Additionally, the team hadn’t conducted any research with actual users—mostly gaining feedback from customers who might not have been the appropriate personas.
Finally, the team didn’t have experience with productizing their technology and going through a full software development release cycle and future iteration. This is where I came in…
These are screenshots from the existing prototype. As you can see, much of the UI was highly underdeveloped and the workflows had several gaping holes; in addition to imposing required actions from users that really weren’t necessary after further investigation. Given the team already had running code and a tight deadline, I knew it was going to be challenging to affect change going forward.
I started by having the CAT R&D team responsible for building the prototype walk me through all the workflows. Along the way, I asked questions to probe more deeply into the “why” behind much of a user’s assumed journey with the software. For example, why would a user need to configure a driver for data collection? Why should they be burdened by what a driver is, much less understand how and why they should configure it? I encouraged the team to reconsider the fact that this software was intended to help enterprise-level employees (likely unfamiliar with device-level operations technology) connect to that OT layer and expose plant floor data to IT/enterprise applications and persona. To date, Rockwell simply hadn’t created this type of “middleware,” which was intended to help put us along the path of realizing our “Connected Enterprise” vision.
Additionally, there had already been an abundance of marketing slides created by leaders in the business to show how this product (initially dubbed Linx Information Gateway) would help users pull data from plant floor devices, configure and model that data (as shown in the middle portion of the slide), and deploy that curated data—now more human readable and befitting a target user’s mental model—to an egress application using technologies such as MSSQL, Thingworx, or MQTT. In my mind, this felt like a 1-2-3 stepped approach: get the data, model and curate that data, and deploy it to an enterprise application. This is an imposed sequence that I later introduced directly into the user interface.
UX DESIGN
Deliverables
User flows, sketches, and wireframes.
Requirements
Product must serve as an easy-to-traverse bridge between OT, device-level data and enterprise egress applications—accessible for IT and corporate users. It must helps users acquire and import the data, contextualize it in whatever shape or form they see fit (data modeling) and provide means to which to deploy it for consumption by egress applications such as Azure IoT, SQL, and PTC’s Thingworx (a Rockwell strategic partner application). It should use modern interaction paradigms wherever possible to leverage new Web tech and a generational shift in automation engineers.
Given there was no opportunity to conduct up-front user research, I had to rely on subject matter experts and the CAT team’s deep knowledge of the proposed workflow and the why’s behind the decisions as expressed in the prototype. We had many early whiteboarding sessions in a very short amount of time so they could take me deeper into the workflow; while I could sketch alternative solutions based on my deep product knowledge and understanding of our user personas in adjacent products. Moreover, I was aware that a major program was in the works, nicknamed Project RAIDER (our next integrated design environment). RAIDER would make heavy use of data tables, property panes, and empty states, and I felt that any Software & Control product currently in development should begin to align with RAIDER’s approach as it was set to become Rockwell’s next flagship product, akin to Logix Designer 5000. The above sketch depicts a card showing an available data source. This data would later be shown in a table, which would bring it more inline with our emerging software patterns.
Unfortunately, the overall workflow wasn’t as simple as a 1-2-3 stepped approach. There would be some configuration needed, and no other subset of tasks was more complex than creating a new application and then “running” modeled data on it. The above workflow demonstrates the various decision points and ways in which the system would respond, which helped inform later wireframes and mockups.
As I mentioned, UI cards were not going to be used in many of our emerging, adjacent applications—including Project RAIDER. This product simply didn’t have a good enough reason or series of use cases to make it worth becoming a one-off experience. Thus, note the use of tables for data sources and a property pane to show individual (or aggregate) data source details. Not only was RAIDER moving ahead with these paradigms, but so was FactoryTalk Policy Manager and FactoryTalk Updater. I continued to show stakeholders and the product teams what was happening outside the limited sphere of their product work and described the design debt they would incur by not aligning sooner than later. They became convinced not long after these wireframes were designed.
The above screenshots show how I continued to walk the line between what had already been developed and the types of workflows and interactions on which we were beginning to standardize.
Moreover, given the heavy use of tables and the potentially robust data sets users would be creating within the application, it was critical that we defined and enabled keyboard shortcuts to make users’ tasks more accessible. This was a Web application, and we didn’t get the usual shortcuts for free like we did when we’d been previously heavy on Windows and Win32 applications. As such, I partnered with other UX designers on the team to document the shortcuts shown above.
VISUAL DESIGN
UI mockups, styles and icons, and copy.
(Driven by hypothesis, persona, and UX design)
Imposed steps help to reduce users’ cognitive load; anticipate what’s next
Prepackaged process templates (boiler, generator, etc.) serve as accelerators for users unfamiliar with predictive analytics, machine learning, and model building
Coach marks and text throughout the interface predicated on in situ knowledge onboarding
Drag and drop tag-to-variable interface capitalizes on modern usage paradigms and simplifies otherwise complex process
As I’d described with my work on the FactoryTalk LogixAI product, we’d begun aligning our design library with Google Material—albeit with some industry-oriented modifications. The visual design mockups I produced hereon after would follow the established style guide, which was consistent with the aforementioned adjacent products we were bringing to market.
I mentioned before that I had a vision for creating a 1-2-3 imposed sequence to make a user’s overall workflow feel more approachable. I am a strong believer in building narrative into a UI to foster this approachability, which I’ve also found (through research) builds a user’s confidence, momentum, and reduces their anxiety for what’s next. Given the accelerated timeline of the product, the visual design stage was highly iterative and the development team was soon a highly collaborative and eager partner in shaping this narrative.
Above, you can see how a user would start with empty states and build out their overview as things progress. The narrative worked like a hub and spoke model too, through which a user would initiate a transient workflow for adding or configuring a data source, building a model, or deploying an application. Once complete with any task, they could then find themselves back at the hub—where could hover over the tables in aggregate once they’d been populated with data that was connected and in a running state. This would help “tell the story” of how and where their data was being used.
Because we wanted to support multiple gateways at some point in the future—beyond R1—it was necessary to mock up how this approach might work, to ensure any solution we created could be resilient to this change and not incur design and technical debt.
The above shows an early depiction of how I approached the model-building workflow. As you can see, it looks quite complex—and that’s because it was. A user could not only impose structure on their data (coming from anywhere in their plant), but they’d need to either unbind or bind tags from disparate data sources to specific nodes in their model(s). Moreover, what if they also wanted to configure the tags before they bound them? This specific workflow was ripe for user feedback, and we later had users at Automation Fair in Chicago (2019) thoroughly test this workflow, which led to some future improvements that you’ll see a bit later.
You should be sensing a theme by now: a left-rail navigation, a local navigation list, a table occupying much of the middle canvas, and a property pane. What a user learned through configuring data sources would favor them as they configured gateways (in a multi-gateway scenario) or an application.
After obtaining user feedback at Automation Fair that year, we immediately set to iterating the model-building workflow. Users previously struggled to bind tags given there weren’t obvious affordances for either using drag and drop or leveraging checkboxes with command buttons to make selections and executing binding or unbinding. For the second iteration, we decided it would be best to lean more into selectors and buttons given users could be dealing with massive data sets. We scaled up the checkboxes and made the buttons and icons more responsive to what a user was doing. Finally, we decided that side-by-side lists—reminiscent of traditional Windows workflows—would make users model-building work easier and more intuitive. Later studies validated this solution.
Later, we learned through user research that users didn’t really grasp (immediately) what state their applications were in and what actions they could take to either stop or start data from flowing to them. The above explorations—in addition to other improvements—were handed off to another senior designer in 2020 as I stepped more fully into management.