Voyix Edge Deployments
Designing a flexible framework for scalable and transparent software deployments
2025–Present
UX/UI Design
React Web App
Voyix Edge Deployments
Designing a flexible framework for scalable and transparent software deployments
2025–Present
UX/UI Design
React Web App
Voyix Edge Deployments
Designing a flexible framework for scalable and transparent software deployments
2025–Present
UX/UI Design
React Web App
NCR Voyix Edge offers retail customers the ability to manage physical store systems with the agility of digital channels through tactical, container-based software updates. As the team’s lead designer, I helped define and refine Edge software deployment flows over several iterations of its early product life, growing active store lanes from 0-1500+.
NCR Voyix Edge offers retail customers the ability to manage physical store systems with the agility of digital channels through tactical, container-based software updates. As the team’s lead designer, I helped define and refine Edge software deployment flows over several iterations of its early product life, growing active store lanes from 0-1500+.
NCR Voyix Edge offers retail customers the ability to manage physical store systems with the agility of digital channels through tactical, container-based software updates. As the team’s lead designer, I helped define and refine Edge software deployment flows over several iterations of its early product life, growing active store lanes from 0-1500+.
Phase one—
Enabling deployments at scale
During its POC phase, Edge limited software installs and upgrades to one store at a time. As the platform matured towards MVP, deployment flows needed to scale. Customers needed a way to deploy upgrades to hundreds or even thousands of stores in one scheduled operation.
Phase one—
Enabling deployments at scale
During its POC phase, Edge limited software installs and upgrades to one store at a time. As the platform matured towards MVP, deployment flows needed to scale. Customers needed a way to deploy upgrades to hundreds or even thousands of stores in one scheduled operation.
Phase one—
Enabling deployments at scale
During its POC phase, Edge limited software installs and upgrades to one store at a time. As the platform matured towards MVP, deployment flows needed to scale. Customers needed a way to deploy upgrades to hundreds or even thousands of stores in one scheduled operation.
The labels hypothesis
Based on early conversations with dev partners, a theory emerged that bulk deployments should target store labels rather than targeting stores directly. For example, an upgrade directed to the store:large label would be applied to all stores with that label, bypassing the need for custom lists to be assembled at deploy time. This approach seemed intuitive and carried over patterns and conventions from Kubernetes, a core part of the Edge stack.
The labels hypothesis
Based on early conversations with dev partners, a theory emerged that bulk deployments should target store labels rather than targeting stores directly. For example, an upgrade directed to the store:large label would be applied to all stores with that label, bypassing the need for custom lists to be assembled at deploy time. This approach seemed intuitive and carried over patterns and conventions from Kubernetes, a core part of the Edge stack.
The labels hypothesis
Based on early conversations with dev partners, a theory emerged that bulk deployments should target store labels rather than targeting stores directly. For example, an upgrade directed to the store:large label would be applied to all stores with that label, bypassing the need for custom lists to be assembled at deploy time. This approach seemed intuitive and carried over patterns and conventions from Kubernetes, a core part of the Edge stack.
Anticipating the future importance labels, I'd already designed tools and flows enabling users to create and assign custom labels to stores and lanes.
Anticipating the future importance labels, I'd already designed tools and flows enabling users to create and assign custom labels to stores and lanes.
Anticipating the future importance labels, I'd already designed tools and flows enabling users to create and assign custom labels to stores and lanes.
User-generated labels were envisioned as a multipurpose attribute, useful both for observing and taking action on store groupings
User-generated labels were envisioned as a multipurpose attribute, useful both for observing and taking action on store groupings
User-generated labels were envisioned as a multipurpose attribute, useful both for observing and taking action on store groupings
A counterpoint perspective from users
Interviews conducted with internal professional service teams and retail customers revealed a different set of expectations. While everyone agreed labels would be useful for organizing store lists and in some cases for establishing deployment context, neither group wanted to be fully restricted by labels when it came to building their final deploy lists. Critically, we learned that target store lists were likely to be compiled outside of Edge in many real-world cases: Both Internal and external stakeholders wanted the ability to upload their lists in CSV or similar formats.
A counterpoint perspective from users
Interviews conducted with internal professional service teams and retail customers revealed a different set of expectations. While everyone agreed labels would be useful for organizing store lists and in some cases for establishing deployment context, neither group wanted to be fully restricted by labels when it came to building their final deploy lists. Critically, we learned that target store lists were likely to be compiled outside of Edge in many real-world cases: Both Internal and external stakeholders wanted the ability to upload their lists in CSV or similar formats.
A counterpoint perspective from users
Interviews conducted with internal professional service teams and retail customers revealed a different set of expectations. While everyone agreed labels would be useful for organizing store lists and in some cases for establishing deployment context, neither group wanted to be fully restricted by labels when it came to building their final deploy lists. Critically, we learned that target store lists were likely to be compiled outside of Edge in many real-world cases: Both Internal and external stakeholders wanted the ability to upload their lists in CSV or similar formats.
KEY FINDING #1
Last minute list changes are common
KEY FINDING #2
Lists are likely to be built with external tools
A more flexible approach to list building
Working iteratively with the same internal and external stakeholders, I refined a deploy flow allowing users to upload their own external store list or manually build one in Edge using store labels and other attributes as filter criteria. In this world, labels serve as an optional reference rather than an explicit deployment target. Following several rounds of usability testing, we released this approach as our MVP approach for bulk deployments.
A more flexible approach to list building
Working iteratively with the same internal and external stakeholders, I refined a deploy flow allowing users to upload their own external store list or manually build one in Edge using store labels and other attributes as filter criteria. In this world, labels serve as an optional reference rather than an explicit deployment target. Following several rounds of usability testing, we released this approach as our MVP approach for bulk deployments.
A more flexible approach to list building
Working iteratively with the same internal and external stakeholders, I refined a deploy flow allowing users to upload their own external store list or manually build one in Edge using store labels and other attributes as filter criteria. In this world, labels serve as an optional reference rather than an explicit deployment target. Following several rounds of usability testing, we released this approach as our MVP approach for bulk deployments.
A transfer-table presents users with two options: Select eligible stores from the left or upload a CSV list of target stores.
A transfer-table presents users with two options: Select eligible stores from the left or upload a CSV list of target stores.
A transfer-table presents users with two options: Select eligible stores from the left or upload a CSV list of target stores.
Labels remain an optional reference via filtering. Users can refine their selection by isolating and adding/removing stores with a given label.
Labels remain an optional reference via filtering. Users can refine their selection by isolating and adding/removing stores with a given label.
Labels remain an optional reference via filtering. Users can refine their selection by isolating and adding/removing stores with a given label.
A catalyst for customer growth
The release of bulk deployments in early 2026 correlated directly with a period of dramatic customer growth for Voyix Edge: live stores grew from 20 to over 300, representing almost 1600 active lanes.
A catalyst for customer growth
The release of bulk deployments in early 2026 correlated directly with a period of dramatic customer growth for Voyix Edge: live stores grew from 20 to over 300, representing almost 1600 active lanes.
A catalyst for customer growth
The release of bulk deployments in early 2026 correlated directly with a period of dramatic customer growth for Voyix Edge: live stores grew from 20 to over 300, representing almost 1600 active lanes.
10x customers
From 1 pilot customer to 10 signed customers
10x customers
From 1 pilot customer to 10 signed customers
16x stores
From 20 to 320 live stores
16x stores
From 20 to 320 live stores
Phase 2—
Projecting simplicity, accommodating complexity
With bulk deployments in the wild for a few months, I launched a survey and helped host a series of interviews to understand users’ experience with the feature so far. Sentiment was positive, but users wanted more: specifically, the ability to package multiple changes into a single deployment was top priority. Around the same time, the Voyix restaurant team was beginning to consider how their customers might also take advantage of the Edge platform in a hospitality context. They too felt it was important for customers to bundle deployment changes. Though not fully validated, I also heard a recurring concern that SMB restaurant operators might find aspects of the Edge UI deployments too technical.
Phase 2—
Projecting simplicity, accommodating complexity
With bulk deployments in the wild for a few months, I launched a survey and helped host a series of interviews to understand users’ experience with the feature so far. Sentiment was positive, but users wanted more: specifically, the ability to package multiple changes into a single deployment was top priority. Around the same time, the Voyix restaurant team was beginning to consider how their customers might also take advantage of the Edge platform in a hospitality context. They too felt it was important for customers to bundle deployment changes. Though not fully validated, I also heard a recurring concern that SMB restaurant operators might find aspects of the Edge UI deployments too technical.
Phase 2—
Projecting simplicity, accommodating complexity
With bulk deployments in the wild for a few months, I launched a survey and helped host a series of interviews to understand users’ experience with the feature so far. Sentiment was positive, but users wanted more: specifically, the ability to package multiple changes into a single deployment was top priority. Around the same time, the Voyix restaurant team was beginning to consider how their customers might also take advantage of the Edge platform in a hospitality context. They too felt it was important for customers to bundle deployment changes. Though not fully validated, I also heard a recurring concern that SMB restaurant operators might find aspects of the Edge UI deployments too technical.
I replaced the stepper template with a modular deployment builder, giving users the ability to add multiple tasks or operations to a single scheduled job.
I replaced the stepper template with a modular deployment builder, giving users the ability to add multiple tasks or operations to a single scheduled job.
I replaced the stepper template with a modular deployment builder, giving users the ability to add multiple tasks or operations to a single scheduled job.
Not every user needs to update their applications’ helm charts—or even understand their purpose. The advanced section streamlines the deployment process for SMB users while keeping optional technical inputs accessible for enterprise teams.
Not every user needs to update their applications’ helm charts—or even understand their purpose. The advanced section streamlines the deployment process for SMB users while keeping optional technical inputs accessible for enterprise teams.
Not every user needs to update their applications’ helm charts—or even understand their purpose. The advanced section streamlines the deployment process for SMB users while keeping optional technical inputs accessible for enterprise teams.
Early wins and continued learnings
With usability testing ongoing, the job builder pattern has received favorable feedback from users of all technical levels. As a result, the pattern is currently positioned as a unifying model for deployments across both restaurant and retail teams—a major win at NCR Voyix, where there’s always potential for redundant work between the two business units. One specific challenge to consider going forward: while the proposed job builder automatically orders any requested dependencies at deployment time, some users had concerns about whether they were sequencing dependencies correctly in the flow builder. In the next iteration, I’m aiming to alleviate any anxiety on this topic by more clearly communicating Edge’s role.
Early wins and continued learnings
With usability testing ongoing, the job builder pattern has received favorable feedback from users of all technical levels. As a result, the pattern is currently positioned as a unifying model for deployments across both restaurant and retail teams—a major win at NCR Voyix, where there’s always potential for redundant work between the two business units. One specific challenge to consider going forward: while the proposed job builder automatically orders any requested dependencies at deployment time, some users had concerns about whether they were sequencing dependencies correctly in the flow builder. In the next iteration, I’m aiming to alleviate any anxiety on this topic by more clearly communicating Edge’s role.
Early wins and continued learnings
With usability testing ongoing, the job builder pattern has received favorable feedback from users of all technical levels. As a result, the pattern is currently positioned as a unifying model for deployments across both restaurant and retail teams—a major win at NCR Voyix, where there’s always potential for redundant work between the two business units. One specific challenge to consider going forward: while the proposed job builder automatically orders any requested dependencies at deployment time, some users had concerns about whether they were sequencing dependencies correctly in the flow builder. In the next iteration, I’m aiming to alleviate any anxiety on this topic by more clearly communicating Edge’s role.