JRNY Strength with Motion Tracking
Introduction
JRNY is Bowflex’s adaptive digital fitness platform, built to deliver cardio, strength, and whole-body workouts that get smarter as you go. I partnered with their team to elevate their strength training experience, designing and launching a reimagined strength workout experience with motion tracking, real-time form feedback, and intuitive voice commands to coach users through smarter, more effective workouts.
Year
2021 – 2022
Client
Bowflex
Company
Supply
Role
Creative Director, Product Planner, Strategist
JRNY Strength with Motion Tracking
Introduction
JRNY is Bowflex’s adaptive digital fitness platform, built to deliver cardio, strength, and whole-body workouts that get smarter as you go. I partnered with their team to elevate their strength training experience, designing and launching a reimagined strength workout experience with motion tracking, real-time form feedback, and intuitive voice commands to coach users through smarter, more effective workouts.
Year
2021 – 2022
Client
Bowflex
Company
Supply
Role
Creative Director, Product Planner, Strategist
JRNY Strength with Motion Tracking
JRNY is Bowflex’s adaptive digital fitness platform, built to deliver cardio, strength, and whole-body workouts that get smarter as you go. I partnered with their team to elevate their strength training experience, designing and launching a reimagined strength workout experience with motion tracking, real-time form feedback, and intuitive voice commands to coach users through smarter, more effective workouts.
Year
2021 – 2022
Client
Bowflex
Company
Supply
Role
Creative Director, Product Planner, Strategist
Context
JRNY is an adaptive digital fitness platform, designed to deliver workouts that get smarter over time. But in order to achieve this, it needs performance data. For cardio workouts this can be done directly by measuring user interactions via the hardware (bikes, ellipticals, treadmills, etc.). Weights and bodyweight, however, don’t have this direct connection, making similar personalization impossible. This left a blind spot in the user experience, leaving strength-focused members underserved.
Context
JRNY is an adaptive digital fitness platform, designed to deliver workouts that get smarter over time. But in order to achieve this, it needs performance data. For cardio workouts this can be done directly by measuring user interactions via the hardware (bikes, ellipticals, treadmills, etc.). Weights and bodyweight, however, don’t have this direct connection, making similar personalization impossible. This left a blind spot in the user experience, leaving strength-focused members underserved.
JRNY is an adaptive digital fitness platform, designed to deliver workouts that get smarter over time. But in order to achieve this, it needs performance data. For cardio workouts this can be done directly by measuring user interactions via the hardware (bikes, ellipticals, treadmills, etc.). Weights and bodyweight, however, don’t have this direct connection, making similar personalization impossible. This left a blind spot in the user experience, leaving strength-focused members underserved.
Democratizing access to fitness coaching.
Democratizing access to fitness coaching.
Democratizing access to fitness coaching.
Challenge
In late 2021, Bowflex approached Supply with a challenge: help them reimagine the JRNY strength experience to support smarter, more accessible coaching for people training at home with free weights. The goal? Improve form, track reps, and offer intelligent guidance — all powered by the phone or tablet users already owned. In addition to leading Supply’s design team, I led a multi-faceted effort that included the following challenges:
Challenge
In late 2021, Bowflex approached Supply with a challenge: help them reimagine the JRNY strength experience to support smarter, more accessible coaching for people training at home with free weights. The goal? Improve form, track reps, and offer intelligent guidance — all powered by the phone or tablet users already owned. In addition to leading Supply’s design team, I led a multi-faceted effort that included the following challenges:
In late 2021, Bowflex approached Supply with a challenge: help them reimagine the JRNY strength experience to support smarter, more accessible coaching for people training at home with free weights. The goal? Improve form, track reps, and offer intelligent guidance — all powered by the phone or tablet users already owned. In addition to leading Supply’s design team, I led a multi-faceted effort that included the following challenges:
01
Product planning and strategy.
Aligning a diverse cross-functional team on what we were building, why it mattered, and how we’d deliver it.
01
Product planning and strategy.
Aligning a diverse cross-functional team on what we were building, why it mattered, and how we’d deliver it.
01
Product planning and strategy.
Aligning a diverse cross-functional team on what we were building, why it mattered, and how we’d deliver it.
02
Designing for UX at a distance.
Creating a workout experience unique to JRNY, centered around motion tracking, form coaching, and voice interaction.
02
Designing for UX at a distance.
Creating a workout experience unique to JRNY, centered around motion tracking, form coaching, and voice interaction.
02
Designing for UX at a distance.
Creating a workout experience unique to JRNY, centered around motion tracking, form coaching, and voice interaction.
03
Collaborative design and development.
Helping Bowflex shift to a more collaborative design and development model for stronger execution.
03
Collaborative design and development.
Helping Bowflex shift to a more collaborative design and development model for stronger execution.
03
Collaborative design and development.
Helping Bowflex shift to a more collaborative design and development model for stronger execution.
Product planning and strategy.
Product planning and strategy.
Product planning and strategy.
01
With stakeholders across UX, voice UX, dev, vision tracking, exercise science, and media production, alignment was essential. My team translated Bowflex’s existing knowledge and research into an extensive, actionable UX and VUX backlog of 200+ user stories with effort estimates, constraints, and unresolved questions mapped out, all organized into a streamlined format for easy review with stakeholders. As spreadsheets go, it was a thing of beauty, and proved highly effective in driving alignment and unlocking key decisions from the product owner.
The process was so effective Bowflex asked us to share our methodology so they could learn how to replicate it for other projects. Here are a few key practices I recommended.
01
With stakeholders across UX, voice UX, dev, vision tracking, exercise science, and media production, alignment was essential. My team translated Bowflex’s existing knowledge and research into an extensive, actionable UX and VUX backlog of 200+ user stories with effort estimates, constraints, and unresolved questions mapped out, all organized into a streamlined format for easy review with stakeholders. As spreadsheets go, it was a thing of beauty, and proved highly effective in driving alignment and unlocking key decisions from the product owner.
The process was so effective Bowflex asked us to share our methodology so they could learn how to replicate it for other projects. Here are a few key practices I recommended.
With stakeholders across UX, voice UX, dev, vision tracking, exercise science, and media production, alignment was essential. My team translated Bowflex’s existing knowledge and research into an extensive, actionable UX and VUX backlog of 200+ user stories with effort estimates, constraints, and unresolved questions mapped out, all organized into a streamlined format for easy review with stakeholders. As spreadsheets go, it was a thing of beauty, and proved highly effective in driving alignment and unlocking key decisions from the product owner.
The process was so effective Bowflex asked us to share our methodology so they could learn how to replicate it for other projects. Here are a few key practices I recommended.
Plan for iteration.
Story development is a refinement process. Expect multiple rounds of revision, ideally with breaks in between to improve clarity and ensure we’ve captured all necessary details. The goal is well-defined, actionable work that supports confident execution.
Estimate with a shared sizing model.
Use a consistent sizing framework such as 1 point per full design or engineering day to align on effort and expectations. This helps all teams plan more effectively and make smarter trade-offs when needed.
Use consistent story structure.
“As a [user type], I want to [task], so that I can [achieve a meaningful outcome].” If a story tries to do too much (often signaled by multiple “and” statements) we’ll break it down into smaller, more focused units of work. This helps us prioritize better and move faster.
Include supporting context.
Stories should be accompanied by relevant notes: design rationale, business goals, known risks, and platform-specific constraints. This context enables faster, more informed conversations — especially when priorities shift or questions arise downstream.
Engage design and engineering early.
Before stories move forward, we review them with design and development leads. Their input helps identify technical constraints, design dependencies, and edge cases we may have missed. It’s a critical step toward reducing risk and avoiding costly rework later.
Provide a starting point for prioritization.
Every batch of stories includes a rough prioritization (SWAG) based on product and design input. This gives stakeholders a head start: low-complexity items can often be agreed upon quickly, which frees up time to focus on the higher-impact or more complex decisions.
Plan for iteration.
Story development is a refinement process. Expect multiple rounds of revision, ideally with breaks in between to improve clarity and ensure we’ve captured all necessary details. The goal is well-defined, actionable work that supports confident execution.
Estimate with a shared sizing model.
Used a consistent sizing framework — such as 1 point per full design or engineering day — to align on effort and expectations. This helps all teams plan more effectively and make smarter trade-offs when needed.
Use consistent story structure.
“As a [user type], I want to [task], so that I can [achieve a meaningful outcome].” If a story tries to do too much — often signaled by multiple “and” statements — we’ll break it down into smaller, more focused units of work. This helps us prioritize better and move faster.
Include supporting context.
Stories should be accompanied by relevant notes: design rationale, business goals, known risks, and platform-specific constraints. This context enables faster, more informed conversations _ especially when priorities shift or questions arise downstream.
Engage design and engineering early.
Before stories move forward, we review them with design and development leads. Their input helps identify technical constraints, design dependencies, and edge cases we may have missed. It’s a critical step toward reducing risk and avoiding costly rework later.
Provide a starting point for prioritization.
Every batch of stories includes a rough prioritization (SWAG) based on product and design input. This gives stakeholders a head start: low-complexity items can often be agreed upon quickly, which frees up time to focus on the higher-impact or more complex decisions.
Plan for iteration.
Story development is a refinement process. Expect multiple rounds of revision, ideally with breaks in between to improve clarity and ensure we’ve captured all necessary details. The goal is well-defined, actionable work that supports confident execution.
Estimate with a shared sizing model.
Used a consistent sizing framework — such as 1 point per full design or engineering day — to align on effort and expectations. This helps all teams plan more effectively and make smarter trade-offs when needed.
Use consistent story structure.
“As a [user type], I want to [task], so that I can [achieve a meaningful outcome].” If a story tries to do too much — often signaled by multiple “and” statements — we’ll break it down into smaller, more focused units of work. This helps us prioritize better and move faster.
Include supporting context.
Stories should be accompanied by relevant notes: design rationale, business goals, known risks, and platform-specific constraints. This context enables faster, more informed conversations _ especially when priorities shift or questions arise downstream.
Engage design and engineering early.
Before stories move forward, we review them with design and development leads. Their input helps identify technical constraints, design dependencies, and edge cases we may have missed. It’s a critical step toward reducing risk and avoiding costly rework later.
Provide a starting point for prioritization.
Every batch of stories includes a rough prioritization (SWAG) based on product and design input. This gives stakeholders a head start: low-complexity items can often be agreed upon quickly, which frees up time to focus on the higher-impact or more complex decisions.
Plan for iteration.
Story development is a refinement process. Expect multiple rounds of revision, ideally with breaks in between to improve clarity and ensure we’ve captured all necessary details. The goal is well-defined, actionable work that supports confident execution.
Estimate with a shared sizing model.
Used a consistent sizing framework — such as 1 point per full design or engineering day — to align on effort and expectations. This helps all teams plan more effectively and make smarter trade-offs when needed.
Use consistent story structure.
“As a [user type], I want to [task], so that I can [achieve a meaningful outcome].” If a story tries to do too much — often signaled by multiple “and” statements — we’ll break it down into smaller, more focused units of work. This helps us prioritize better and move faster.
Include supporting context.
Stories should be accompanied by relevant notes: design rationale, business goals, known risks, and platform-specific constraints. This context enables faster, more informed conversations _ especially when priorities shift or questions arise downstream.
Engage design and engineering early.
Before stories move forward, we review them with design and development leads. Their input helps identify technical constraints, design dependencies, and edge cases we may have missed. It’s a critical step toward reducing risk and avoiding costly rework later.
Provide a starting point for prioritization.
Every batch of stories includes a rough prioritization (SWAG) based on product and design input. This gives stakeholders a head start: low-complexity items can often be agreed upon quickly, which frees up time to focus on the higher-impact or more complex decisions.
Plan for iteration.
Story development is a refinement process. Expect multiple rounds of revision, ideally with breaks in between to improve clarity and ensure we’ve captured all necessary details. The goal is well-defined, actionable work that supports confident execution.
Estimate with a shared sizing model.
Used a consistent sizing framework — such as 1 point per full design or engineering day — to align on effort and expectations. This helps all teams plan more effectively and make smarter trade-offs when needed.
Use consistent story structure.
“As a [user type], I want to [task], so that I can [achieve a meaningful outcome].” If a story tries to do too much — often signaled by multiple “and” statements — we’ll break it down into smaller, more focused units of work. This helps us prioritize better and move faster.
Include supporting context.
Stories should be accompanied by relevant notes: design rationale, business goals, known risks, and platform-specific constraints. This context enables faster, more informed conversations _ especially when priorities shift or questions arise downstream.
Engage design and engineering early.
Before stories move forward, we review them with design and development leads. Their input helps identify technical constraints, design dependencies, and edge cases we may have missed. It’s a critical step toward reducing risk and avoiding costly rework later.
Provide a starting point for prioritization.
Every batch of stories includes a rough prioritization (SWAG) based on product and design input. This gives stakeholders a head start: low-complexity items can often be agreed upon quickly, which frees up time to focus on the higher-impact or more complex decisions.
Plan for iteration.
Story development is a refinement process. Expect multiple rounds of revision, ideally with breaks in between to improve clarity and ensure we’ve captured all necessary details. The goal is well-defined, actionable work that supports confident execution.
Estimate with a shared sizing model.
Used a consistent sizing framework — such as 1 point per full design or engineering day — to align on effort and expectations. This helps all teams plan more effectively and make smarter trade-offs when needed.
Use consistent story structure.
“As a [user type], I want to [task], so that I can [achieve a meaningful outcome].” If a story tries to do too much — often signaled by multiple “and” statements — we’ll break it down into smaller, more focused units of work. This helps us prioritize better and move faster.
Include supporting context.
Stories should be accompanied by relevant notes: design rationale, business goals, known risks, and platform-specific constraints. This context enables faster, more informed conversations _ especially when priorities shift or questions arise downstream.
Engage design and engineering early.
Before stories move forward, we review them with design and development leads. Their input helps identify technical constraints, design dependencies, and edge cases we may have missed. It’s a critical step toward reducing risk and avoiding costly rework later.
Provide a starting point for prioritization.
Every batch of stories includes a rough prioritization (SWAG) based on product and design input. This gives stakeholders a head start: low-complexity items can often be agreed upon quickly, which frees up time to focus on the higher-impact or more complex decisions.
Plan for iteration.
Story development is a refinement process. Expect multiple rounds of revision, ideally with breaks in between to improve clarity and ensure we’ve captured all necessary details. The goal is well-defined, actionable work that supports confident execution.
Estimate with a shared sizing model.
Used a consistent sizing framework — such as 1 point per full design or engineering day — to align on effort and expectations. This helps all teams plan more effectively and make smarter trade-offs when needed.
Use consistent story structure.
“As a [user type], I want to [task], so that I can [achieve a meaningful outcome].” If a story tries to do too much — often signaled by multiple “and” statements — we’ll break it down into smaller, more focused units of work. This helps us prioritize better and move faster.
Include supporting context.
Stories should be accompanied by relevant notes: design rationale, business goals, known risks, and platform-specific constraints. This context enables faster, more informed conversations _ especially when priorities shift or questions arise downstream.
Engage design and engineering early.
Before stories move forward, we review them with design and development leads. Their input helps identify technical constraints, design dependencies, and edge cases we may have missed. It’s a critical step toward reducing risk and avoiding costly rework later.
Provide a starting point for prioritization.
Every batch of stories includes a rough prioritization (SWAG) based on product and design input. This gives stakeholders a head start: low-complexity items can often be agreed upon quickly, which frees up time to focus on the higher-impact or more complex decisions.
Plan for iteration.
Story development is a refinement process. Expect multiple rounds of revision, ideally with breaks in between to improve clarity and ensure we’ve captured all necessary details. The goal is well-defined, actionable work that supports confident execution.
Estimate with a shared sizing model.
Used a consistent sizing framework — such as 1 point per full design or engineering day — to align on effort and expectations. This helps all teams plan more effectively and make smarter trade-offs when needed.
Use consistent story structure.
“As a [user type], I want to [task], so that I can [achieve a meaningful outcome].” If a story tries to do too much — often signaled by multiple “and” statements — we’ll break it down into smaller, more focused units of work. This helps us prioritize better and move faster.
Include supporting context.
Stories should be accompanied by relevant notes: design rationale, business goals, known risks, and platform-specific constraints. This context enables faster, more informed conversations _ especially when priorities shift or questions arise downstream.
Engage design and engineering early.
Before stories move forward, we review them with design and development leads. Their input helps identify technical constraints, design dependencies, and edge cases we may have missed. It’s a critical step toward reducing risk and avoiding costly rework later.
Provide a starting point for prioritization.
Every batch of stories includes a rough prioritization (SWAG) based on product and design input. This gives stakeholders a head start: low-complexity items can often be agreed upon quickly, which frees up time to focus on the higher-impact or more complex decisions.
Plan for iteration.
Story development is a refinement process. Expect multiple rounds of revision, ideally with breaks in between to improve clarity and ensure we’ve captured all necessary details. The goal is well-defined, actionable work that supports confident execution.
Estimate with a shared sizing model.
Used a consistent sizing framework — such as 1 point per full design or engineering day — to align on effort and expectations. This helps all teams plan more effectively and make smarter trade-offs when needed.
Use consistent story structure.
“As a [user type], I want to [task], so that I can [achieve a meaningful outcome].” If a story tries to do too much — often signaled by multiple “and” statements — we’ll break it down into smaller, more focused units of work. This helps us prioritize better and move faster.
Include supporting context.
Stories should be accompanied by relevant notes: design rationale, business goals, known risks, and platform-specific constraints. This context enables faster, more informed conversations _ especially when priorities shift or questions arise downstream.
Engage design and engineering early.
Before stories move forward, we review them with design and development leads. Their input helps identify technical constraints, design dependencies, and edge cases we may have missed. It’s a critical step toward reducing risk and avoiding costly rework later.
Provide a starting point for prioritization.
Every batch of stories includes a rough prioritization (SWAG) based on product and design input. This gives stakeholders a head start: low-complexity items can often be agreed upon quickly, which frees up time to focus on the higher-impact or more complex decisions.
Plan for iteration.
Story development is a refinement process. Expect multiple rounds of revision, ideally with breaks in between to improve clarity and ensure we’ve captured all necessary details. The goal is well-defined, actionable work that supports confident execution.
Estimate with a shared sizing model.
Used a consistent sizing framework — such as 1 point per full design or engineering day — to align on effort and expectations. This helps all teams plan more effectively and make smarter trade-offs when needed.
Use consistent story structure.
“As a [user type], I want to [task], so that I can [achieve a meaningful outcome].” If a story tries to do too much — often signaled by multiple “and” statements — we’ll break it down into smaller, more focused units of work. This helps us prioritize better and move faster.
Include supporting context.
Stories should be accompanied by relevant notes: design rationale, business goals, known risks, and platform-specific constraints. This context enables faster, more informed conversations _ especially when priorities shift or questions arise downstream.
Engage design and engineering early.
Before stories move forward, we review them with design and development leads. Their input helps identify technical constraints, design dependencies, and edge cases we may have missed. It’s a critical step toward reducing risk and avoiding costly rework later.
Provide a starting point for prioritization.
Every batch of stories includes a rough prioritization (SWAG) based on product and design input. This gives stakeholders a head start: low-complexity items can often be agreed upon quickly, which frees up time to focus on the higher-impact or more complex decisions.
Plan for iteration.
Story development is a refinement process. Expect multiple rounds of revision, ideally with breaks in between to improve clarity and ensure we’ve captured all necessary details. The goal is well-defined, actionable work that supports confident execution.
Estimate with a shared sizing model.
Used a consistent sizing framework — such as 1 point per full design or engineering day — to align on effort and expectations. This helps all teams plan more effectively and make smarter trade-offs when needed.
Use consistent story structure.
“As a [user type], I want to [task], so that I can [achieve a meaningful outcome].” If a story tries to do too much — often signaled by multiple “and” statements — we’ll break it down into smaller, more focused units of work. This helps us prioritize better and move faster.
Include supporting context.
Stories should be accompanied by relevant notes: design rationale, business goals, known risks, and platform-specific constraints. This context enables faster, more informed conversations _ especially when priorities shift or questions arise downstream.
Engage design and engineering early.
Before stories move forward, we review them with design and development leads. Their input helps identify technical constraints, design dependencies, and edge cases we may have missed. It’s a critical step toward reducing risk and avoiding costly rework later.
Provide a starting point for prioritization.
Every batch of stories includes a rough prioritization (SWAG) based on product and design input. This gives stakeholders a head start: low-complexity items can often be agreed upon quickly, which frees up time to focus on the higher-impact or more complex decisions.
Plan for iteration.
Story development is a refinement process. Expect multiple rounds of revision, ideally with breaks in between to improve clarity and ensure we’ve captured all necessary details. The goal is well-defined, actionable work that supports confident execution.
Estimate with a shared sizing model.
Used a consistent sizing framework — such as 1 point per full design or engineering day — to align on effort and expectations. This helps all teams plan more effectively and make smarter trade-offs when needed.
Use consistent story structure.
“As a [user type], I want to [task], so that I can [achieve a meaningful outcome].” If a story tries to do too much — often signaled by multiple “and” statements — we’ll break it down into smaller, more focused units of work. This helps us prioritize better and move faster.
Include supporting context.
Stories should be accompanied by relevant notes: design rationale, business goals, known risks, and platform-specific constraints. This context enables faster, more informed conversations _ especially when priorities shift or questions arise downstream.
Engage design and engineering early.
Before stories move forward, we review them with design and development leads. Their input helps identify technical constraints, design dependencies, and edge cases we may have missed. It’s a critical step toward reducing risk and avoiding costly rework later.
Provide a starting point for prioritization.
Every batch of stories includes a rough prioritization (SWAG) based on product and design input. This gives stakeholders a head start: low-complexity items can often be agreed upon quickly, which frees up time to focus on the higher-impact or more complex decisions.
Plan for iteration.
Story development is a refinement process. Expect multiple rounds of revision, ideally with breaks in between to improve clarity and ensure we’ve captured all necessary details. The goal is well-defined, actionable work that supports confident execution.
Estimate with a shared sizing model.
Used a consistent sizing framework — such as 1 point per full design or engineering day — to align on effort and expectations. This helps all teams plan more effectively and make smarter trade-offs when needed.
Use consistent story structure.
“As a [user type], I want to [task], so that I can [achieve a meaningful outcome].” If a story tries to do too much — often signaled by multiple “and” statements — we’ll break it down into smaller, more focused units of work. This helps us prioritize better and move faster.
Include supporting context.
Stories should be accompanied by relevant notes: design rationale, business goals, known risks, and platform-specific constraints. This context enables faster, more informed conversations _ especially when priorities shift or questions arise downstream.
Engage design and engineering early.
Before stories move forward, we review them with design and development leads. Their input helps identify technical constraints, design dependencies, and edge cases we may have missed. It’s a critical step toward reducing risk and avoiding costly rework later.
Provide a starting point for prioritization.
Every batch of stories includes a rough prioritization (SWAG) based on product and design input. This gives stakeholders a head start: low-complexity items can often be agreed upon quickly, which frees up time to focus on the higher-impact or more complex decisions.
Supply’s work exceeded our expectations. We even called on them to help us coach and build our internal teams’ practices and processes. We became a more effective team as a result of operating more like Supply.
Steve Rodden, Senior Director of User Experience at Bowflex
Supply’s work exceeded our expectations. We even called on them to help us coach and build our internal teams’ practices and processes. We became a more effective team as a result of operating more like Supply.
Steve Rodden, Senior Director of User Experience at Bowflex
Supply’s work exceeded our expectations. We even called on them to help us coach and build our internal teams’ practices and processes. We became a more effective team as a result of operating more like Supply.
Steve Rodden, Senior Director of User Experience at Bowflex
Designing for UX at a distance.
Designing for UX at a distance.
Designing for UX at a distance.
02
We designed a motion-tracked workout experience that provided real-time feedback, counted reps, and adjusted recommendations based on actual performance. One of the biggest challenges? Visibility. Unlike typical fitness apps viewed up close, users needed to see key metrics from 8–10 feet away.
02
We designed a motion-tracked workout experience that provided real-time feedback, counted reps, and adjusted recommendations based on actual performance. One of the biggest challenges? Visibility. Unlike typical fitness apps viewed up close, users needed to see key metrics from 8–10 feet away.
We designed a motion-tracked workout experience that provided real-time feedback, counted reps, and adjusted recommendations based on actual performance. One of the biggest challenges? Visibility. Unlike typical fitness apps viewed up close, users needed to see key metrics from 8–10 feet away.
Big, clean, and colorful.
To solve for this, we extended the JRNY design system, designing larger UI elements, simplified layouts, and bold, color-coded metrics to make it easy to follow workouts at a glance.
Big, clean, and colorful.
To solve for this, we extended the JRNY design system, designing larger UI elements, simplified layouts, and bold, color-coded metrics to make it easy to follow workouts at a glance.
Big, clean, and colorful.
To solve for this, we extended the JRNY design system, designing larger UI elements, simplified layouts, and bold, color-coded metrics to make it easy to follow workouts at a glance.
Big, clean, and colorful.
To solve for this, we extended the JRNY design system, designing larger UI elements, simplified layouts, and bold, color-coded metrics to make it easy to follow workouts at a glance.
Warm Up
(before workout)
Recover
(between circuits)
Work
(during an exercise)
Rest
(between exercises)
Cool Down
(after final circuit)
Visualizing your form.
To make coaching effective (and prove we're actually tracking you accurately) we needed a clear, real-time representation of the user’s body on screen. We started with a minimal “skeleton,” connecting key tracked points and overlaying it on the live camera view.
The final design used the "open dot and radius" aesthetic shown below, balancing clarity, scientific credibility, and visual polish. It was readable from a distance, helped users calibrate their position, and reinforced confidence in the system’s precision. Just as important, it made real-time form feedback intuitive, allowing users to focus on improving, not second-guessing the tech.
Visualizing your form.
To make coaching effective (and prove we're actually tracking you accurately) we needed a clear, real-time representation of the user’s body on screen. We started with a minimal “skeleton,” connecting key tracked points and overlaying it on the live camera view.
The final design used the "open dot and radius" aesthetic shown below, balancing clarity, scientific credibility, and visual polish. It was readable from a distance, helped users calibrate their position, and reinforced confidence in the system’s precision. Just as important, it made real-time form feedback intuitive, allowing users to focus on improving, not second-guessing the tech.
Visualizing your form.
To make coaching effective (and prove we're actually tracking you accurately) we needed a clear, real-time representation of the user’s body on screen. We started with a minimal “skeleton,” connecting key tracked points and overlaying it on the live camera view.
The final design used the "open dot and radius" aesthetic shown below, balancing clarity, scientific credibility, and visual polish. It was readable from a distance, helped users calibrate their position, and reinforced confidence in the system’s precision. Just as important, it made real-time form feedback intuitive, allowing users to focus on improving, not second-guessing the tech.
Visualizing your form.
To make coaching effective (and prove we're actually tracking you accurately) we needed a clear, real-time representation of the user’s body on screen. We started with a minimal “skeleton,” connecting key tracked points and overlaying it on the live camera view.
The final design used the "open dot and radius" aesthetic shown below, balancing clarity, scientific credibility, and visual polish. It was readable from a distance, helped users calibrate their position, and reinforced confidence in the system’s precision. Just as important, it made real-time form feedback intuitive, allowing users to focus on improving, not second-guessing the tech.
Giving voice a visual character.
To reduce friction during workouts, we added voice control so users could stay focused and hands-free. But voice alone isn’t always enough. Without clear visual cues, it’s easy to wonder: Did the system hear me? Is it still listening?
To address this, we introduced intuitive voice controls paired with a visual avatar that made JRNY’s voice assistant feel present and responsive. This on-screen avatar visually communicated when JRNY was listening, processing, or responding. Each state used distinct motion informed by physical metaphor to convey intent without distraction, giving users confidence that they were heard and keeping their attention where it belonged: on the workout.
Giving voice a visual character.
To reduce friction during workouts, we added voice control so users could stay focused and hands-free. But voice alone isn’t always enough. Without clear visual cues, it’s easy to wonder: Did the system hear me? Is it still listening?
To address this, we introduced intuitive voice controls paired with a visual avatar that made JRNY’s voice assistant feel present and responsive. This on-screen avatar visually communicated when JRNY was listening, processing, or responding. Each state used distinct motion informed by physical metaphor to convey intent without distraction, giving users confidence that they were heard and keeping their attention where it belonged: on the workout.
Giving voice a visual character.
To reduce friction during workouts, we added voice control so users could stay focused and hands-free. But voice alone isn’t always enough. Without clear visual cues, it’s easy to wonder: Did the system hear me? Is it still listening?
To address this, we introduced intuitive voice controls paired with a visual avatar that made JRNY’s voice assistant feel present and responsive. This on-screen avatar visually communicated when JRNY was listening, processing, or responding. Each state used distinct motion informed by physical metaphor to convey intent without distraction, giving users confidence that they were heard and keeping their attention where it belonged: on the workout.
Giving voice a visual character.
To reduce friction during workouts, we added voice control so users could stay focused and hands-free. But voice alone isn’t always enough. Without clear visual cues, it’s easy to wonder: Did the system hear me? Is it still listening?
To address this, we introduced intuitive voice controls paired with a visual avatar that made JRNY’s voice assistant feel present and responsive. This on-screen avatar visually communicated when JRNY was listening, processing, or responding. Each state used distinct motion informed by physical metaphor to convey intent without distraction, giving users confidence that they were heard and keeping their attention where it belonged: on the workout.
Standby
"quiet / waiting"
Standby
"quiet / waiting"
Standby
"quiet / waiting"
Standby
"quiet / waiting"
Listening
"ears open"
Listening
"ears open"
Listening
"ears open"
Listening
"ears open"
Capturing
"hearing"
Capturing
"hearing"
Capturing
"hearing"
Capturing
"hearing"
Processing
"drumming fingers"
Processing
"drumming fingers"
Processing
"drumming fingers"
Processing
"drumming fingers"
Speaking
"radiating"
Speaking
"radiating"
Speaking
"radiating"
Speaking
"radiating"
Confirming
"universal ok"
Confirming
"universal ok"
Confirming
"universal ok"
Confirming
"universal ok"
Here's what that looked like in action, with a user using voice commands to correct the weight they used at the end of a round of exercises.
Here's what that looked like in action, with a user using voice commands to correct the weight they used at the end of a round of exercises.
Here's what that looked like in action, with a user using voice commands to correct the weight they used at the end of a round of exercises.
Here's what that looked like in action, with a user using voice commands to correct the weight they used at the end of a round of exercises.
Collaborative design and development.
Collaborative design and development.
Collaborative design and development.
Collaborative design and development.
03
At the start of this project I was asked to help improve how Bowflex’s product design and development teams worked together. My approach was simple: treat design and development as one team, not two. We aligned our cadence with their existing sprint cycle, joining their agile rhythm with biweekly check-ins, co-reviews, and shared accountability. The shift paid off. Our designs were grounded in technical reality from day one, and we unlocked better ideas through shared problem-solving. This led to fewer surprises, and stronger, more implementable solutions.
03
At the start of this project I was asked to help improve how Bowflex’s product design and development teams worked together. My approach was simple: treat design and development as one team, not two. We aligned our cadence with their existing sprint cycle, joining their agile rhythm with biweekly check-ins, co-reviews, and shared accountability. The shift paid off. Our designs were grounded in technical reality from day one, and we unlocked better ideas through shared problem-solving. This led to fewer surprises, and stronger, more implementable solutions.
03
At the start of this project I was asked to help improve how Bowflex’s product design and development teams worked together. My approach was simple: treat design and development as one team, not two. We aligned our cadence with their existing sprint cycle, joining their agile rhythm with biweekly check-ins, co-reviews, and shared accountability. The shift paid off. Our designs were grounded in technical reality from day one, and we unlocked better ideas through shared problem-solving. This led to fewer surprises, and stronger, more implementable solutions.
At the start of this project I was asked to help improve how Bowflex’s product design and development teams worked together. My approach was simple: treat design and development as one team, not two. We aligned our cadence with their existing sprint cycle, joining their agile rhythm with biweekly check-ins, co-reviews, and shared accountability. The shift paid off. Our designs were grounded in technical reality from day one, and we unlocked better ideas through shared problem-solving. This led to fewer surprises, and stronger, more implementable solutions.
A successful launch.
A successful launch.
A successful launch.
A successful launch.
Outcome
JRNY Strength with Motion Tracking launched in January 2023 across Android and iOS. It was a meaningful leap forward for Bowflex, one that brought strength training front and center in their digital experience, and reestablished JRNY as a platform truly built for the whole body.
Outcome
JRNY Strength with Motion Tracking launched in January 2023 across Android and iOS. It was a meaningful leap forward for Bowflex, one that brought strength training front and center in their digital experience, and reestablished JRNY as a platform truly built for the whole body.
Outcome
JRNY Strength with Motion Tracking launched in January 2023 across Android and iOS. It was a meaningful leap forward for Bowflex, one that brought strength training front and center in their digital experience, and reestablished JRNY as a platform truly built for the whole body.
JRNY Strength with Motion Tracking launched in January 2023 across Android and iOS. It was a meaningful leap forward for Bowflex, one that brought strength training front and center in their digital experience, and reestablished JRNY as a platform truly built for the whole body.