Virtual Devices Experience

Problem

The user experience was suffering from technical debt stemming from how physical devices were modeled in the software. Conversely, how physical devices were modeled in the software was limiting the user's ability to manage fleets of devices.

User Stories

As an app builder, I want to be able to define app events that relate to what's happening at my station. I want to be able to say "do this when this breakbeam gets crossed" as opposed to using the language of GPIO pins.

As an app builder, I want to be able to define app actions using the reality of output devices at my station. I want to be able to "show error indicator on the andon" instead of thinking about the hardware involved in this process.

As an app builder, I want my apps to be separate from the physical configuration at my station so that I can use the same app at a different station, even if the same station is wired differently.

As an app builder, I want to use two devices of the same driver connected to the same gateway/player.

After understanding the perspective of our internal stakeholders, I needed unbiased data sources. While our team and subject matter experts were very knowledgeable, they probably had their own gaps, personal frustrations, and motivating incentives towards certain kinds of problem-framing. To design something for the user, I would need to do a baseline review of the best practices in this space to compare and systematically understand internal stakeholder sentiment in a more deep and critical manner. The baseline review would also make sure I wasn't re-inventing the wheel.

Baseline Design Research

I noticed several things about the books that existed in this area: 1) there weren't many, 2) they tended towards the theoretical in tone, 3) the more design-oriented ones were geared towards the consumer space, 4) they were more about systems design than experience design.

This told me (and was confirmed in the readings) that this space is uncharted in terms of design and that there are not a lot of commonly followed experience patterns. Due to its newness, users were also more likely to make mistakes because they were not used to setting up IoT devices -- existing mental scaffolding or familiarity with the technology was not there to help guide them. Users would have to be educated as part of the process.

This baseline research would help me pick up the language and technical background to speak to stakeholders, but I would need to work closely with our subject matter experts to understand what the actual profiles of our users were in the industrial setting and ideally, talk to users themselves about their preferences.

Design Principles

‍

Place-Making

The capability to help users reduce disorientation, build a sense of place, increase legibility, and way-finding across digital, physical, and cross-channel environments.
‍

Consistency

Suits the purposes, contexts, and people it is designed for (internal consistency), and to maintain the same logic across different media, environments, and times in which it acts (external consistency).
‍

Resilience

Shapes and adapts itself to specific users, needs, and seeking strategies.
‍

Reduction

Manages large information sets and minimizes stress and frustration associated with choosing from and ever-growing set of information sources, services, and goods.
‍

Correlation

Suggests relevant connections among pieces of information, services, and goods, to help users achieve explicit goals or stimulate latent needs.

I was reading continuously throughout the project to check my assumptions and keep abreast of the domain, but one of the primary things I needed to pull were a set of guiding design principles for the team and product. While a company with a larger design budget could afford to spend time developing this specifically to their product, I was in the position of doing as little damage as possible while enabling the feature we needed to deliver. We could iterate on these design principles as we moved along and collected more domain and user feedback.

Design Principles

Design principles are useful beyond the design team. For complex projects requiring high collaboration, they also help other stakeholders generate ideas and start designing themselves. It's a myth that designers are the only ones designing; everyone in the organization designs. Everyone's activity, roles, and responsibilities, end up impacting the user's experience, from sales to support. For all that activity to be a multiplier for the user though, the designer needs to be able to effectively frame the design participation and orchestrate activity across the organization. This is the operative mode of evangelization.

Finding the right level of abstraction for design principles can be difficult, but a rule I go by is to describe it at a level that enables teams to make decisions around product experience. This means that design principles need to be updated as the product hits saturation or as a new design challenge is discovered in the process. Decisions, assumptions, and results around design debates need to be tracked and evaluated over time much like product features. Design principles should evolve as markets do.

Various device patterns were discovered during internal interviews, speaking to the working habits of the team as well as the complexity of devices. To work through these cases, I selected a set of devices to workshop as I worked through the user flows. The chosen devices represented our most common and complex use cases existing at various stages of development within the platform. At the same time, the project had to be strategic about the things we needed to fix now to incrementally deliver the project use cases versus things that we could fix later or decisions that needed to be put off because we were unsure what the appropriate direction might be.

Device Use Cases & UX Audit

By testing with a set of devices, we could make sure we had coverage over the edge cases and met technical requirements. For each device, a create, view, edit, and delete flow would need to be developed that would maintain similarity as much as possible so that users did not have to learn multiple patterns for the same action. Any differences would then be accounted for by progressively disclosing information for device experiences that are more complex. To understand the scope of impact across the platform, I did a content audit to understand where the entry points into each flow currently exists.

This is some text inside of a div block.

Learning 1

Looking at the UX audit and seeing how it mapped to our desired experience phases, it was clear that there was no logic to where certain features were implemented. What was most problematic was the split between connecting and configuring the device.

With devices abstracted and modeled, their configurations could now be saved, shared, and applied across multiple physical devices. A major net new user flow that resulted from this new architecture was device set-up, where a user hooked up their physical device into the Tulip state machine by assigning it to a device configuration. This flow would take place on a tablet and be done by an operator at a physical station on the shop floor. The list of devices previously set up by a process engineer while they set-up an app would be shown here to inform the operator of which devices were needed at the station.

Task Flows & Skilled Labor

Designing task flows for enterprise products in digitizing domains is complex, not just because the workflows are entrenched in legacy standards but because the user personas are frequently in flux. Digitization is not just a technical upgrade but a socio-cultural transition, and we often have to train our users to fit the product. This requires making decisions on what is worth training them on, what is worth creating a product feature for, and how the two interact with each other to create a comprehensive experience and compelling future of a domain. Decisions need to be made around the durability of skills and the labor needs of digitizing businesses.

Compared to consumer products, the goal is not always to do something in the "easiest" way by simplifying flows and funneling users towards a single call-to-action. Enterprise design requires balancing immediate improvements in simplicity with reliability and comprehensibility, and considering broader improvements in workforce development and training.

In many ways, this feature resulted out of hearing our clients talk about the persistent skilled labor shortage in the manufacturing space. Our clients often had trouble finding people with the technical skills necessary to operate the smart factory of the future, especially when facilities could often be located in more remote areas away from urban centers. This meant that, if we are to be a first-class product in the domain, we had to account for labor availability as a design opportunity, and realize that as we designed the product we are also designing job requirements for the future.

The device abstraction not only allowed the controlled sharing of configurations and associated data management, it also allowed our clients to more effectively use their workforce. The technically-trained process engineers that are more difficult to hire can interact with the device abstractions while the more classically-trained operators or floor leads can set-up physical devices without having to know the technical underpinnings since they've already been configured ahead of time. Our clients could recruit process engineers that prefer to live in denser locations while distributing the fruits of their labor across more remote locations.

The bulk of the design work was working closely with my lead R&D engineer to understand the possible states that would be introduced as part of this new system and designing those secondary flows thoroughly for the user. In industrial IoT where there is large machinery at play, the amount of time working through edge cases is critical. Our CTO often talked of the guillotine effect to remind us that these dinky buttons can actually be controls for potentially dangerous machines.

Secondary Task Flows & State Management

State management is extremely important in enterprise software. These little tiny indicators are often the only piece of information that a user has into the mechanics of the system. Designing states properly can help a user learn how to use the software by showing them how it processes information. It also provides an entry point into error management, helping users troubleshoot efficiently when things go wrong.

Since devices are complex, for this one object there are three states that are necessary to show the user: 1) the device connection, 2) the device identification, and 3) the overall device set-up completion. Utilizing a combination of text, color, and icons, I designed one device component to express all three states. I did not want there to be three separate state indicators for one object because there was a pattern and hierarchy to how the system automatically pulled state and how the user would need to set-up their device. By visually treating each state differently, the order and structure of the task could be expressed to the user. Packaged as one component, the structure and hierarchy within the concept model we developed for the system architecture would also be maintained without the introduction of floating ancillary concepts.