2019 – 2020

Virtual Device Experience

An experience for hooking up physical stations to the digital world.

Tulip Interfaces Edge Computing & Machine VisionProduct Designer

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.

Goal

Enable a process engineer to set-up and manage the devices required at a station through an interface.

A worker in a DECKEL MAHO shirt at a shop-floor station, facing a pegboard of tools and posted instructions.

Decision Alignment

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

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.

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.

UX Audit

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.

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.

The device set-up task flow, from a process engineer publishing an app on desktop to an operator setting up devices on a tablet, beside the annotated Set-Up Devices screen.

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.

UX Design

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.

A state diagram of an unenumerated USB device through connection, identification and set-up, beside the device component in each state.

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.

State Design

I worked closely with the 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.

ManufacturingIndustrial IoT