Password required
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
Overview—
NCR Voyix Edge offers retailers the ability to manage physical store systems with the agility of digital channels through tactical, containerized 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-3000+.
Overview—
NCR Voyix Edge offers retailers the ability to manage physical store systems with the agility of digital channels through tactical, containerized 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-3000+.
Overview—
NCR Voyix Edge offers retailers the ability to manage physical store systems with the agility of digital channels through tactical, containerized 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-3000+.
Phase 1 Challenge—
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 had to scale. Customers needed a way to deploy upgrades to hundreds or even thousands of stores in one scheduled operation. Early conversations with dev partners seemed to support the use of store tags or labels to form generalized deploy targets. This approach seemed highly efficient and carried over patterns from Kubernetes, a core part of the Edge stack. However, real questions remained about how customers might use labels as a guide for bulk deployments.
Phase 1 Challenge—
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 had to scale. Customers needed a way to deploy upgrades to hundreds or even thousands of stores in one scheduled operation. Early conversations with dev partners seemed to support the use of store tags or labels to form generalized deploy targets. This approach seemed highly efficient and carried over patterns from Kubernetes, a core part of the Edge stack. However, real questions remained about how customers might use labels as a guide for bulk deployments.
Phase 1 Challenge—
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 had to scale. Customers needed a way to deploy upgrades to hundreds or even thousands of stores in one scheduled operation. Early conversations with dev partners seemed to support the use of store tags or labels to form generalized deploy targets. This approach seemed highly efficient and carried over patterns from Kubernetes, a core part of the Edge stack. However, real questions remained about how customers might use labels as a guide for bulk deployments.
I'd already designed tools and flows enabling users to create and assign custom labels to stores and lanes. Labels were initially envisioned as a multipurpose attribute, useful both for observing and taking action on store groupings.
I'd already designed tools and flows enabling users to create and assign custom labels to stores and lanes. Labels were initially envisioned as a multipurpose attribute, useful both for observing and taking action on store groupings.
I'd already designed tools and flows enabling users to create and assign custom labels to stores and lanes. Labels were initially envisioned as a multipurpose attribute, useful both for observing and taking action on store groupings.
A counterpoint perspective from users
Interviews with Voyix 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—no team wanted to be fully restricted by labels when it came to building their final deploy lists. Critically, I learned that target store lists were likely to be compiled outside of Edge in most 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 with Voyix 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—no team wanted to be fully restricted by labels when it came to building their final deploy lists. Critically, I learned that target store lists were likely to be compiled outside of Edge in most 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 with Voyix 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—no team wanted to be fully restricted by labels when it came to building their final deploy lists. Critically, I learned that target store lists were likely to be compiled outside of Edge in most 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 designed a bulk 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 rather than explicit targets.
A more flexible approach to list building
Working iteratively with the same internal and external stakeholders, I designed a bulk 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 rather than explicit targets.
A more flexible approach to list building
Working iteratively with the same internal and external stakeholders, I designed a bulk 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 rather than explicit targets.
The list builder presents users with two paths: Select eligible stores via the transfer table or simply upload a CSV list of target stores.
The list builder presents users with two paths: Select eligible stores via the transfer table or simply upload a CSV list of target stores.
The list builder presents users with two paths: Select eligible stores via the transfer table or simply upload a CSV list of target stores.
DevOps users wanted a full, editable view of their app’s config with a referenceable ReadMe
DevOps users wanted a full, editable view of their app’s config with a referenceable ReadMe
DevOps users wanted a full, editable view of their app’s config with a referenceable ReadMe
The deployments “cart” view: Users needed a full summary of their choices before pulling the trigger on a deployment affecting hundreds of stores.
The deployments “cart” view: Users needed a full summary of their choices before pulling the trigger on a deployment affecting hundreds of stores.
The deployments “cart” view: Users needed a full summary of their choices before pulling the trigger on a deployment affecting hundreds of stores.
A catalyst for customer growth
The release of v1 bulk deployments in early 2026 contributed directly to a period of dramatic customer growth for Voyix Edge. Real-world features like bulk deployments helped grow live stores from 20 to over 600, representing over 3000 active lanes.
A catalyst for customer growth
The release of v1 bulk deployments in early 2026 contributed directly to a period of dramatic customer growth for Voyix Edge. Real-world features like bulk deployments helped grow live stores from 20 to over 600, representing over 3000 active lanes.
A catalyst for customer growth
The release of v1 bulk deployments in early 2026 contributed directly to a period of dramatic customer growth for Voyix Edge. Real-world features like bulk deployments helped grow live stores from 20 to over 600, representing over 3000 active lanes.
12x customers
From 1 pilot customer to 12 signed customers
20x stores
From 20 to 620 live stores
Phase 2 Challenge—
Projecting simplicity, accommodating complexity
With bulk deployments in the wild for a few months, I circled back with users to understand their experience with the feature so far. Sentiment was positive, but users wanted more. Above all, users wanted the ability to package multiple changes into a single scheduled deployment. Around the same time, the Voyix restaurant team began to consider how their customers might also take advantage of Edge deployments. Whereas retail strategy was focused on established DevOps teams, the restaurant team wanted to explore the suitability of Edge for less technical personas, up to and including small business operators. This spectrum of personas presented a unique challenge: Could a single deployment builder accommodate the needs and aptitudes of both expert and novice users?
Phase 2 Challenge—
Projecting simplicity, accommodating complexity
With bulk deployments in the wild for a few months, I circled back with users to understand their experience with the feature so far. Sentiment was positive, but users wanted more. Above all, users wanted the ability to package multiple changes into a single scheduled deployment. Around the same time, the Voyix restaurant team began to consider how their customers might also take advantage of Edge deployments. Whereas retail strategy was focused on established DevOps teams, the restaurant team wanted to explore the suitability of Edge for less technical personas, up to and including small business operators. This spectrum of personas presented a unique challenge: Could a single deployment builder accommodate the needs and aptitudes of both expert and novice users?
Phase 2 Challenge—
Projecting simplicity, accommodating complexity
With bulk deployments in the wild for a few months, I circled back with users to understand their experience with the feature so far. Sentiment was positive, but users wanted more. Above all, users wanted the ability to package multiple changes into a single scheduled deployment. Around the same time, the Voyix restaurant team began to consider how their customers might also take advantage of Edge deployments. Whereas retail strategy was focused on established DevOps teams, the restaurant team wanted to explore the suitability of Edge for less technical personas, up to and including small business operators. This spectrum of personas presented a unique challenge: Could a single deployment builder accommodate the needs and aptitudes of both expert and novice users?
In the v2 deployment flow, I replaced the standard stepper with a modular deployment builder, enabling users to add multiple tasks or operations to a single scheduled job.
In the v2 deployment flow, I replaced the standard stepper with a modular deployment builder, enabling users to add multiple tasks or operations to a single scheduled job.
In the v2 deployment flow, I replaced the standard stepper with a modular deployment builder, enabling users to add multiple tasks or operations to a single scheduled job.
Not every upgrade requires a Helm configuration update—and not every user needs to be confronted by opaque YAML code during a routine upgrade. Tucking configs like this into a “Workload options” drawer means fewer steps to click through and less intimidation for less technical users.
Not every upgrade requires a Helm configuration update—and not every user needs to be confronted by opaque YAML code during a routine upgrade. Tucking configs like this into a “Workload options” drawer means fewer steps to click through and less intimidation for non-technical users.
Not every upgrade requires a Helm configuration update—and not every user needs to be confronted by opaque YAML code during a routine upgrade. Tucking configs like this into a “Workload options” drawer means fewer steps to click through and less intimidation for less technical users.
Not every upgrade requires a Helm configuration update—and not every user needs to be confronted by opaque YAML code during a routine upgrade. Tucking configs like this into a “Workload options” drawer means fewer steps to click through and less intimidation for less technical users.
The deployment builder itself displays a running summary of user intent, providing full transparency at every stage. No need to wait for the final step.
The deployment builder itself displays a running summary of user intent, providing full transparency at every stage. No need to wait for the final step.
The deployment builder itself displays a running summary of user intent, providing full transparency at every stage. No need to wait for the final step.
“Day 1” deployments
The v1 deployment builder was well-suited to existing Edge stores, but left some gaps when it came to onboarding new ones. Using scripts cooked up by an enterprising field engineer as a starting point, I designed a “Workload template” task allowing users to transfer a complete snapshot of store software from one store to others.
“Day 1” deployments
The v1 deployment builder was well-suited to existing Edge stores, but left some gaps when it came to onboarding new ones. Using scripts cooked up by an enterprising field engineer as a starting point, I designed a “Workload template” task allowing users to transfer a complete snapshot of store software from one store to others.
“Day 1” deployments
The v1 deployment builder was well-suited to existing Edge stores, but left some gaps when it came to onboarding new ones. Using scripts cooked up by an enterprising field engineer as a starting point, I designed a “Workload template” task allowing users to transfer a complete snapshot of store software from one store to others.
Templates provide a certified combination of the many services required to run an Edge store, ideal for an initial lab-to-store transfer.
Templates provide a certified combination of the many services required to run an Edge store, ideal for an initial lab-to-store transfer.
Templates provide a certified combination of the many services required to run an Edge store, ideal for an initial lab-to-store transfer.
Pre-launch momentum
With usability testing ongoing, the job builder pattern has received favorable feedback from users at all technical levels. As a result, the updated pattern is currently positioned as a unifying model for software deployments across both restaurant and retail teams—a major win at NCR Voyix, where potential always exists for competing efforts between the two units.
Pre-launch momentum
With usability testing ongoing, the job builder pattern has received favorable feedback from users at all technical levels. As a result, the updated pattern is currently positioned as a unifying model for software deployments across both restaurant and retail teams—a major win at NCR Voyix, where potential always exists for competing efforts between the two units.
Pre-launch momentum
With usability testing ongoing, the job builder pattern has received favorable feedback from users at all technical levels. As a result, the updated pattern is currently positioned as a unifying model for software deployments across both restaurant and retail teams—a major win at NCR Voyix, where potential always exists for competing efforts between the two units.