GoPxL

The product was designed for expert users working in industrial measurement and inspection contexts. These users were not learning concepts for the first time — they were applying specialized knowledge under time pressure, with low tolerance for friction, ambiguity, or hidden system behavior.

At the same time, the system itself was inherently complex:

• Tools were interdependent rather than isolated
• Configuration choices had downstream effects that were not always obvious
• Workflows grew longer and more dynamic as customer use cases evolved

This combination created a design tension that couldn’t be solved through surface-level usability improvements:

• Simplifying too aggressively risked obscuring critical system behavior
• Exposing everything risked overwhelming users and increasing error
• Relying on documentation or training alone was insufficient for day-to-day work

The core challenge was not onboarding casual users — it was enabling experts to work efficiently, confidently, and correctly as system complexity increased over time

The Starting Point: Constraints & Legacy Reality

GoPxL did not start from a blank slate. It emerged alongside an existing configuration model and set of tools that were already in active use through Gocator, LMI’s previous generation of measurement and configuration software.

That legacy experience worked acceptably for simple or narrowly scoped setups, but it showed clear strain as real-world usage evolved. As workflows grew longer, more interdependent, and more dynamic, several limitations became increasingly visible:

• Configuration relied on rigid, list-based structures that were difficult to reason about at scale
• Tools were added and reordered through slow, linear interactions
• Important actions and states (such as renaming or contextual meaning) were effectively invisible
• There was little in-product support to help users understand how pieces fit together

These constraints were not merely usability issues — they were structural mismatches between how the system behaved and how expert users actually worked.

At the same time, there were significant non-negotiable realities:

• Existing mental models and workflows had to be respected
• The system needed to remain reliable and predictable for expert users
• Any new approach had to coexist with engineering constraints and delivery timelines

This starting point framed the work ahead. The challenge was not to “clean up” an interface, but to rethink how complex configuration and automation workflows could be represented without breaking trust, destabilizing established practices, or introducing new sources of error.

My Role, Scope, & Accountability

I served as the Principal and sole UX Designer for GoPxL, with end-to-end responsibility for the product’s user experience from early concept through the v1.2 release.

My role extended beyond feature-level design. I was accountable for the coherence, scalability, and long-term health of the UX across a growing platform, working closely with product, engineering, QA, and internal expert users (application engineers).

My responsibilities included

• Defining the overall workflow architecture and interaction models
• Designing and governing a design system aligned with underlying engineering architecture
• Translating complex, system-driven behavior into usable, predictable interfaces
• Validating designs through expert review, user feedback, and iterative testing
• Supporting implementation accuracy through detailed specifications and ongoing collaboration
• Maintaining UX quality through QA cycles and release readiness, not just design handoff

While GoPxL was developed by a multidisciplinary team, I was the primary point of ownership for UX decisions, tradeoffs, and evolution over time. This required balancing ideal design outcomes with technical constraints, delivery risk, and long-term platform goals.

The Core Design Challenge

The core challenge behind GoPxL was not simply introducing a new interface, but redefining how complex system behavior could be authored, understood, and maintained by expert users over time.

That level of control already existed in prior tools, but it was expressed through rigid, textual, list-based configuration with little visibility into how tools related to one another. Users could configure behavior, but they were largely forced to reason about the system mentally — without clear feedback about what a tool consumed, what it produced, or how those pieces were connected.

At the same time, removing too much structure was not an option. These workflows were:

• Highly interdependent
• Sensitive to configuration errors
• Expected to scale in length and complexity as use cases evolved

The design challenge became a balancing act:

• Power without opacity
  Enable expert-level configuration while making system structure, inputs, outputs, and dependencies visible and understandable.
• Flexibility without chaos
  Allow workflows to evolve without becoming opaque, fragile, or unmaintainable.
• Visibility without overload
  Make system logic, dependencies, and effects understandable without flooding users with detail.

Solving this required more than choosing the right UI patterns — it required rethinking how system logic itself was represented and manipulated.

Designing Visual Workflows for Expert Systems

To address the limitations of rigid, text-based configuration, GoPxL introduced a visual workflow model that made system structure explicit rather than implicit.

At the center of this approach was the tool diagram: a visual representation of tools, their inputs and outputs, and the connections between them. Instead of requiring users to mentally track relationships across lists and configuration panels, the diagram externalized system logic in a form that could be directly inspected, reasoned about, and manipulated.

This shift was not primarily about speed or convenience. It was about supporting expert reasoning in the presence of growing system complexity.

Key design principles guided this work:

• Make structure visible
  Tools, data flow, and dependencies needed to be legible at a glance, reducing reliance on memory and inference.
• Let users act directly on the system model
  Drag-and-drop interactions allowed users to add, remove, reorder, and select tools directly within the diagram, keeping action and understanding tightly coupled.
• Expose inputs and outputs as first-class concepts
  By clearly showing what each tool consumed and produced, the system made downstream effects easier to anticipate and diagnose.
• Balance flexibility with guardrails
  The workflow model supported a wide range of configurations while preventing invalid or ambiguous connections that could lead to errors.

Rather than hiding complexity, the visual workflow approach acknowledged it — providing users with a representation that scaled as workflows grew longer, more interdependent, and more dynamic over time.

Three examples of small interaction changes with outsized impact on expert workflows.

These interaction decisions share a common thread: they reduce cognitive load not by hiding complexity, but by aligning system behavior more closely with how experts think, inspect, and reason about their work .

Iteration and Validation Over Time

GoPxL was not designed as a single, fixed solution. It evolved through continuous iteration and validation, informed by real usage, expert feedback, and emerging constraints as the system moved from concept to production.