![](data:image/svg+xml,<svg display="block" id="990806758" role="presentation" viewBox="0 0 108 44" xmlns="http://www.w3.org/2000/svg"><path d="M 14.85 27.131 C 13.226 27.414 11.572 27.499 9.862 27.726 L 4.646 12.546 L 4.646 28.377 C 3.021 28.547 1.539 28.773 0 29 L 0 0 L 4.333 0 L 10.261 16.454 L 10.261 0 L 14.85 0 Z M 23.829 10.62 C 25.596 10.62 28.304 10.535 29.929 10.535 L 29.929 15.066 C 27.905 15.066 25.539 15.066 23.829 15.151 L 23.829 21.892 C 26.508 21.722 29.188 21.495 31.895 21.41 L 31.895 25.771 L 19.268 26.763 L 19.268 0 L 31.895 0 L 31.895 4.531 L 23.829 4.531 Z M 48.855 4.531 L 44.123 4.531 L 44.123 25.375 C 42.584 25.375 41.045 25.375 39.563 25.432 L 39.563 4.531 L 34.832 4.531 L 34.832 0 L 48.855 0 Z M 56.266 10.309 L 62.508 10.309 L 62.508 14.84 L 56.266 14.84 L 56.266 25.12 L 51.791 25.12 L 51.791 0 L 64.532 0 L 64.532 4.531 L 56.266 4.531 Z M 71.943 21.155 C 74.537 21.212 77.159 21.41 79.696 21.552 L 79.696 26.026 C 75.62 25.771 71.544 25.517 67.382 25.432 L 67.382 0 L 71.943 0 Z M 83.544 26.338 C 84.997 26.423 86.537 26.508 88.019 26.678 L 88.019 0 L 83.544 0 Z M 108 0 L 102.214 13.792 L 108 29 C 106.29 28.773 104.579 28.462 102.869 28.179 L 99.591 19.796 L 96.257 27.499 C 94.603 27.216 93.007 27.131 91.354 26.904 L 97.226 13.622 L 91.924 0 L 96.826 0 L 99.819 7.618 L 103.012 0 Z" fill="rgb(216, 31, 38)" height="29px" id="bXox46a9X" width="107.99999713627835px"/></svg>)
Hundreds of Flows.
No Source of Truth.
I was the Lead Product Designer working alongside the Consumer Lifecycle platform team. As a contractor, I worked outside of the design org. On the project, I had full autonomy over design direction.
Hundreds of Flows.
No Source of Truth.
I was the Lead Product Designer working alongside the Consumer Lifecycle platform team. As a contractor, I worked outside of the design org. On the project, I had full autonomy over design direction.
Hundreds of Flows.
No Source of Truth.
I was the Lead Product Designer working alongside the Consumer Lifecycle platform team. As a contractor, I worked outside of the design org. On the project, I had full autonomy over design direction.
Hundreds of Flows.
No Source of Truth.
I was the Lead Product Designer working alongside the Consumer Lifecycle platform team. As a contractor, I worked outside of the design org. On the project, I had full autonomy over design direction.
The Problem
What is the Real Experience?
Teams at Netflix couldn't actually see what a customer saw. Yes, they had a designer's staging of a happy path, they had data science teams that could analyze the funnel, and they had engineers that could look at logs, but even with all that, it's simply hard to know what any given session actually looked like. On top of that, all the different combinations of devices, member states, languages, locales, active A/B tests, etc.
Legal could not verify a customer or government inquiry about an experience that might be years old.
Design could not scope a redesign without manually auditing what existed or if other flows would be impacted.
Localization could not translate confidently without context or if translated text broke the layout.
The Problem
What is the Real Experience?
Teams at Netflix couldn't actually see what a customer saw. Yes, they had a designer's staging of a happy path, they had data science teams that could analyze the funnel, and they had engineers that could look at logs, but even with all that, it's simply hard to know what any given session actually looked like. On top of that, all the different combinations of devices, member states, languages, locales, active A/B tests, etc.
Legal could not verify a customer or government inquiry about an experience that might be years old.
Design could not scope a redesign without manually auditing what existed or if other flows would be impacted.
Localization could not translate confidently without context or if translated text broke the layout.
The Problem
What is the Real Experience?
Teams at Netflix couldn't actually see what a customer saw. Yes, they had a designer's staging of a happy path, they had data science teams that could analyze the funnel, and they had engineers that could look at logs, but even with all that, it's simply hard to know what any given session actually looked like. On top of that, all the different combinations of devices, member states, languages, locales, active A/B tests, etc.
Legal could not verify a customer or government inquiry about an experience that might be years old.
Design could not scope a redesign without manually auditing what existed or if other flows would be impacted.
Localization could not translate confidently without context or if translated text broke the layout.
The Problem
What is the Real Experience?
Teams at Netflix couldn't actually see what a customer saw. Yes, they had a designer's staging of a happy path, they had data science teams that could analyze the funnel, and they had engineers that could look at logs, but even with all that, it's simply hard to know what any given session actually looked like. On top of that, all the different combinations of devices, member states, languages, locales, active A/B tests, etc.
Legal could not verify a customer or government inquiry about an experience that might be years old.
Design could not scope a redesign without manually auditing what existed or if other flows would be impacted.
Localization could not translate confidently without context or if translated text broke the layout.
The Process
Gathering Team Assumptions
When I jumped in, the team had already done lots of work standing up the back-end architecture, as well as speaking to different teams about their specific use cases. I needed to get all that info out of their brains. So I ran a FigJam workshop. I prompted them with questions about user pain points, current solutions, workarounds, and end-to-end journeys. Of course, some of the answers were assumptions. But this gave me a basis for strong research questions. That is, what should I know in order to make evidence-based decisions?
The Process
Gathering Team Assumptions
When I jumped in, the team had already done lots of work standing up the back-end architecture, as well as speaking to different teams about their specific use cases. I needed to get all that info out of their brains. So I ran a FigJam workshop. I prompted them with questions about user pain points, current solutions, workarounds, and end-to-end journeys. Of course, some of the answers were assumptions. But this gave me a basis for strong research questions. That is, what should I know in order to make evidence-based decisions?
The Process
Gathering Team Assumptions
When I jumped in, the team had already done lots of work standing up the back-end architecture, as well as speaking to different teams about their specific use cases. I needed to get all that info out of their brains. So I ran a FigJam workshop. I prompted them with questions about user pain points, current solutions, workarounds, and end-to-end journeys. Of course, some of the answers were assumptions. But this gave me a basis for strong research questions. That is, what should I know in order to make evidence-based decisions?
The Process
Gathering Team Assumptions
When I jumped in, the team had already done lots of work standing up the back-end architecture, as well as speaking to different teams about their specific use cases. I needed to get all that info out of their brains. So I ran a FigJam workshop. I prompted them with questions about user pain points, current solutions, workarounds, and end-to-end journeys. Of course, some of the answers were assumptions. But this gave me a basis for strong research questions. That is, what should I know in order to make evidence-based decisions?
UNCOVERING CONFLICT
User Flows Are Seen Differently
To a designer
A flow is the path you intend: a linear sequence from entry point to success state. Clear start, clear end, clear purpose. The happy path.
To an engineer
A flow is a graph traversal. Nodes connected by conditional logic, no fixed start or end. The path depends entirely on the user's state.
To a customer
A flow is whatever actually happened: errors, back-navigation, dead ends. Two users starting from the same screen may never share a path.
UNCOVERING CONFLICT
User Flows Are Seen Differently
To a designer
A flow is the path you intend: a linear sequence from entry point to success state. Clear start, clear end, clear purpose. The happy path.
To an engineer
A flow is a graph traversal. Nodes connected by conditional logic, no fixed start or end. The path depends entirely on the user's state.
To a customer
A flow is whatever actually happened: errors, back-navigation, dead ends. Two users starting from the same screen may never share a path.
UNCOVERING CONFLICT
User Flows Are Seen Differently
To a designer
A flow is the path you intend: a linear sequence from entry point to success state. Clear start, clear end, clear purpose. The happy path.
To an engineer
A flow is a graph traversal. Nodes connected by conditional logic, no fixed start or end. The path depends entirely on the user's state.
To a customer
A flow is whatever actually happened: errors, back-navigation, dead ends. Two users starting from the same screen may never share a path.
UNCOVERING CONFLICT
User Flows Are Seen Differently
To a designer
A flow is the path you intend: a linear sequence from entry point to success state. Clear start, clear end, clear purpose. The happy path.
To an engineer
A flow is a graph traversal. Nodes connected by conditional logic, no fixed start or end. The path depends entirely on the user's state.
To a customer
A flow is whatever actually happened: errors, back-navigation, dead ends. Two users starting from the same screen may never share a path.
shaping strategy
Different Teams, Same Problems
User Interviews
I ran generative interviews with 20+ subjects across five functions. I wanted to understand their workflow, jobs-to-be-done, gaps in getting work done, and why having flows was valuable to them.
Identifying Gaps
Then, I mapped each function's entire workflow. Spikes in the graph indicated gaps in the flow, ie areas of opportunity. Overlapping each map revealed areas of opportunity which were shared across functions.
Strategic Alignment
I turned those insights into themes that drove strategy. For example, one theme was "Gathering". Essentially, users needed a way to find, organize, and share flows. Proposed features supported this theme.
shaping strategy
Different Teams, Same Problems
User Interviews
I ran generative interviews with 20+ subjects across five functions. I wanted to understand their workflow, jobs-to-be-done, gaps in getting work done, and why having flows was valuable to them.
Identifying Gaps
Then, I mapped each function's entire workflow. Spikes in the graph indicated gaps in the flow, ie areas of opportunity. Overlapping each map revealed areas of opportunity which were shared across functions.
Strategic Alignment
I turned those insights into themes that drove strategy. For example, one theme was "Gathering". Essentially, users needed a way to find, organize, and share flows. Proposed features supported this theme.
shaping strategy
Different Teams, Same Problems
User Interviews
I ran generative interviews with 20+ subjects across five functions. I wanted to understand their workflow, jobs-to-be-done, gaps in getting work done, and why having flows was valuable to them.
Identifying Gaps
Then, I mapped each function's entire workflow. Spikes in the graph indicated gaps in the flow, ie areas of opportunity. Overlapping each map revealed areas of opportunity which were shared across functions.
Strategic Alignment
I turned those insights into themes that drove strategy. For example, one theme was "Gathering". Essentially, users needed a way to find, organize, and share flows. Proposed features supported this theme.
shaping strategy
Different Teams, Same Problems
User Interviews
I ran generative interviews with 20+ subjects across five functions. I wanted to understand their workflow, jobs-to-be-done, gaps in getting work done, and why having flows was valuable to them.
Identifying Gaps
Then, I mapped each function's entire workflow. Spikes in the graph indicated gaps in the flow, ie areas of opportunity. Overlapping each map revealed areas of opportunity which were shared across functions.
Strategic Alignment
I turned those insights into themes that drove strategy. For example, one theme was "Gathering". Essentially, users needed a way to find, organize, and share flows. Proposed features supported this theme.
design decision
Product Teams Define Their Flows
As mentioned, the back-end had nodes. A node is simply a spot where a user lands. That node could have different screens associated with it (that is, what the customer is actually seeing). So if a team wanted to find a particular flow, say sign-up, it would first need to be defined: the sign-up flow equals these nodes, edges, and screens. Our team decided we shouldn't be responsible for flow definitions. Flows were seeded in the system with the help of designers since they knew their domains best. We also added a Flow Builder feature to enable teams to create themselves.
design decision
Product Teams Define Their Flows
As mentioned, the back-end had nodes. A node is simply a spot where a user lands. That node could have different screens associated with it (that is, what the customer is actually seeing). So if a team wanted to find a particular flow, say sign-up, it would first need to be defined: the sign-up flow equals these nodes, edges, and screens. Our team decided we shouldn't be responsible for flow definitions. Flows were seeded in the system with the help of designers since they knew their domains best. We also added a Flow Builder feature to enable teams to create themselves.
design decision
Product Teams Define Their Flows
As mentioned, the back-end had nodes. A node is simply a spot where a user lands. That node could have different screens associated with it (that is, what the customer is actually seeing). So if a team wanted to find a particular flow, say sign-up, it would first need to be defined: the sign-up flow equals these nodes, edges, and screens. Our team decided we shouldn't be responsible for flow definitions. Flows were seeded in the system with the help of designers since they knew their domains best. We also added a Flow Builder feature to enable teams to create themselves.
design decision
Product Teams Define Their Flows
As mentioned, the back-end had nodes. A node is simply a spot where a user lands. That node could have different screens associated with it (that is, what the customer is actually seeing). So if a team wanted to find a particular flow, say sign-up, it would first need to be defined: the sign-up flow equals these nodes, edges, and screens. Our team decided we shouldn't be responsible for flow definitions. Flows were seeded in the system with the help of designers since they knew their domains best. We also added a Flow Builder feature to enable teams to create themselves.
The value proposition
Finding the Right Flow
Use case: A designer is tasked with improving the registration flow. First, they might ask: if I touch screen X, what other flows are impacted? Any active A/B tests? Is there a variation in country Z? Another: Legal gets a claim that a customer did not receive a promotion. They say the promotion promised 3 months of free Netflix. This was a year ago. So what did the promotion actually say? And many, many more. This is what Eon would deliver. Searching for flows exactly as the customer would have seen them. Shipped!
The value proposition
Finding the Right Flow
Use case: A designer is tasked with improving the registration flow. First, they might ask: if I touch screen X, what other flows are impacted? Any active A/B tests? Is there a variation in country Z? Another: Legal gets a claim that a customer did not receive a promotion. They say the promotion promised 3 months of free Netflix. This was a year ago. So what did the promotion actually say? And many, many more. This is what Eon would deliver. Searching for flows exactly as the customer would have seen them. Shipped!
The value proposition
Finding the Right Flow
Use case: A designer is tasked with improving the registration flow. First, they might ask: if I touch screen X, what other flows are impacted? Any active A/B tests? Is there a variation in country Z? Another: Legal gets a claim that a customer did not receive a promotion. They say the promotion promised 3 months of free Netflix. This was a year ago. So what did the promotion actually say? And many, many more. This is what Eon would deliver. Searching for flows exactly as the customer would have seen them. Shipped!
The value proposition
Finding the Right Flow
Use case: A designer is tasked with improving the registration flow. First, they might ask: if I touch screen X, what other flows are impacted? Any active A/B tests? Is there a variation in country Z? Another: Legal gets a claim that a customer did not receive a promotion. They say the promotion promised 3 months of free Netflix. This was a year ago. So what did the promotion actually say? And many, many more. This is what Eon would deliver. Searching for flows exactly as the customer would have seen them. Shipped!
Testing & Contraints
Using AI in the codebase let me test on real data, surfacing two discoveries. First: flow metadata at the top (country, language, etc) was confusing, users expecting it to act like a dropdown. I moved it to the bottom so it read properly as a reference. Second: I'd designed search as one query across all entities. The backend had no cross-entity filters. I decided to put an entity selector as a required choice next to the search field.
Key Screens Delivered
Landing Screen
Search Results
Flow Builder
Creating a Flow
Screen Details
Key String Search
Key Screens Delivered
Landing Screen
Search Results
Flow Builder
Creating a Flow
Screen Details
Key String Search
Key Screens Delivered
Landing Screen
Search Results
Flow Builder
Creating a Flow
Screen Details
Key String Search
Key Screens Delivered
Landing Screen
Search Results
Flow Builder
Creating a Flow
Screen Details
Key String Search
Future State Delivery
Before leaving Netflix, I designed four concept explorations as a north star for the team — showing how Eon could evolve from documentation to intelligence: flow health, dependency mapping, funnel analytics, and no-code copy editing.
Future State Delivery
Before leaving Netflix, I designed four concept explorations as a north star for the team — showing how Eon could evolve from documentation to intelligence: flow health, dependency mapping, funnel analytics, and no-code copy editing.
Future State Delivery
Before leaving Netflix, I designed four concept explorations as a north star for the team — showing how Eon could evolve from documentation to intelligence: flow health, dependency mapping, funnel analytics, and no-code copy editing.
Future State Delivery
Before leaving Netflix, I designed four concept explorations as a north star for the team — showing how Eon could evolve from documentation to intelligence: flow health, dependency mapping, funnel analytics, and no-code copy editing.
Copyright © 2025 Jesse Bones. All Rights Reserved. All content, designs, and images on this website are the property of Jesse Bones and respective clients. Unauthorized use, reproduction, or distribution of any materials without explicit permission is prohibited.
Copyright © 2025 Jesse Bones. All Rights Reserved. All content, designs, and images on this website are the property of Jesse Bones and respective clients. Unauthorized use, reproduction, or distribution of any materials without explicit permission is prohibited.
Copyright © 2025 Jesse Bones. All Rights Reserved. All content, designs, and images on this website are the property of Jesse Bones and respective clients. Unauthorized use, reproduction, or distribution of any materials without explicit permission is prohibited.
Copyright © 2025 Jesse Bones. All Rights Reserved. All content, designs, and images on this website are the property of Jesse Bones and respective clients. Unauthorized use, reproduction, or distribution of any materials without explicit permission is prohibited.