IN.
No context switching. No dead ends.
Access granted — staying in context.
Strategy & Systems
Streamlining sign-in — Verizon
Lead Designer · Authentication Strategy · Cross-functional team · 6-month program
Lead Designer · Authentication Strategy · Cross-functional team · 6-month program
Overview
Verizon's sign-in flow required customers to switch contexts twice to complete verification — opening SMS for a tokenized link, then a browser page to allow access, then manually returning to where they started. The goal: eliminate the context switching.
NGD launched with a mandate to modernize authentication and almost nothing else. No defined scope. No design direction. A 6-month funding window. KPMG brought in to facilitate. I led design from day one — defining what the program would actually solve, partnering with UX research on a moderated usability study with 12 real Verizon customers, and shipping features within the constraint while building a recommendation deck for everything that couldn't fit inside it.
The alternate number for authentication initiative is now a formally funded initiative. The work is still being built.
Overview
Verizon's sign-in flow required customers to switch contexts twice to complete verification — opening SMS for a tokenized link, then a browser page to allow access, then manually returning to where they started. The goal: eliminate the context switching.
NGD launched with a mandate to modernize authentication and almost nothing else. No defined scope. No design direction. A 6-month funding window. KPMG brought in to facilitate. I led design from day one — defining what the program would actually solve, partnering with UX research on a moderated usability study with 12 real Verizon customers, and shipping features within the constraint while building a recommendation deck for everything that couldn't fit inside it.
The alternate number for authentication initiative is now a formally funded initiative. The work is still being built.
The constraint
Two realities shaped every decision:
• Funding window: 6 months — program ends, money stops
• Technical reality: true back-end authentication changes take years, not months.
The gap between those two things wasn't a problem to solve — it was a condition to design within. What could we ship in 6 months that was meaningful on its own and set up the next team to keep going? That question drove everything from prioritization to the recommendation deck.
The scenario that defined everything
A customer using her mom's phone to sign in. Verification link going to her own broken device. No alternate number on file. No other option available. Just a wall.
The research put it plainly: customers on shared accounts sometimes had to physically drive to the primary account holder to sign in. This wasn't an edge case. It was a system failure hiding in plain sight — and it became the north star for the entire design direction.
The systemic version of the same problem
The dead end scenario was one customer, one broken flow. But the inconsistency ran across the entire product. Mobile, FWA, and Fios each had completely different verification methods — non-Verizon numbers couldn't be used at all, leaving FWA and Fios customers with weaker, less consistent options. It wasn't one broken flow. It was the entire authentication system.
The systemic version of the same problem
The dead end scenario was one customer, one broken flow. But the inconsistency ran across the entire product. Mobile, FWA, and Fios each had completely different verification methods — non-Verizon numbers couldn't be used at all, leaving FWA and Fios customers with weaker, less consistent options. It wasn't one broken flow. It was the entire authentication system.
What the funding window couldn't hold
Not everything could ship in 6 months — and that was always going to be true. Back-end authentication changes are multi-year programs. The recommendation deck was how those directions stayed alive — documenting the problem, the rationale, and the path forward clearly enough that the next team could pick it up without starting over. Several are now active programs. That was the goal.
The constraint
Two realities shaped every decision:
• Funding window: 6 months — program ends, money stops
• Technical reality: true back-end authentication changes take years, not months.
The gap between those two things wasn't a problem to solve — it was a condition to design within. What could we ship in 6 months that was meaningful on its own and set up the next team to keep going? That question drove everything from prioritization to the recommendation deck.
What we built
(as of April 2026)
Alternate number for authentication — shipped
Customers can now authenticate via any number they have access to — not just the primary on the account. The verification link goes somewhere they can actually receive it. This work is now a formally funded initiative with its own roadmap.

What we built
(as of April 2026)
Alternate number for authentication — shipped
Customers can now authenticate via any number they have access to — not just the primary on the account. The verification link goes somewhere they can actually receive it. This work is now a formally funded initiative with its own roadmap.

The Problem
Verizon had 57.6K calls per month related to sign-in issues z, and 2 million password resets every month. Customers weren't just frustrated — they were completely stuck. A dedicated moderated usability study (12 Verizon wireless customers, January 2024) confirmed what we were seeing in the flows: the verification system was failing people in real, predictable ways.


Authentication settings redesign — app, mobile web, desktop
The legacy page was 11 years old — three viewports, three different UIs, broken components. We rebuilt it as one consistent system across all surfaces.
The Problem
Verizon had 68K calls per month related to passwords and authentication, and 2 million password resets every month. Customers weren't just frustrated — they were completely stuck. A dedicated moderated usability study (12 Verizon wireless customers, January 2024) confirmed what we were seeing in the flows: the verification system was failing people in real, predictable ways.
The scenario that defined everything
A customer using her mom's phone to sign in. Verification link going to her own broken device. No alternate number on file. No other option available. Just a wall.
The research put it plainly: customers on shared accounts sometimes had to physically drive to the primary account holder to sign in. This wasn't an edge case. It was a system failure hiding in plain sight — and it became the north star for the entire design direction.
A moment I'm most proud of
Turning something obscure into work that keeps going after the program ends.
The recommendation deck had a strict format mandated by our senior director. I used it as a framework — mapping complex authentication systems through before-and-after flow maps that made years of tangled logic easy to follow at a glance. It became the template for how the team documents authentication experiences going forward. Future roadmaps are being built from it now.
The format was given to me. The clarity was mine to create.


The systemic version of the same problem
The dead end scenario was one customer, one broken flow. But the inconsistency ran across the entire product. Mobile, FWA, and Fios each had completely different verification methods — non-Verizon numbers couldn't be used at all, leaving FWA and Fios customers with weaker, less consistent options. It wasn't one broken flow. It was the entire authentication system.


Authentication settings redesign — app, mobile web, desktop
The legacy page was 11 years old — three viewports, three different UIs, broken components. We rebuilt it as one consistent system across all surfaces.
What the funding window couldn't hold
Not everything could ship in 6 months — and that was always going to be true. Back-end authentication changes are multi-year programs. The recommendation deck was how those directions stayed alive — documenting the problem, the rationale, and the path forward clearly enough that the next team could pick it up without starting over. Several are now active programs. That was the goal.
What we built
(as of April 2026)
Alternate number for authentication — shipped
Customers can now authenticate via any number they have access to — not just the primary on the account. The verification link goes somewhere they can actually receive it. This work is now a formally funded initiative with its own roadmap.


Authentication settings redesign — app, mobile web, desktop
The legacy page was 11 years old — three viewports, three different UIs, broken components. We rebuilt it as one consistent system across all surfaces.
A moment I'm most proud of
Turning something obscure into work that keeps going after the program ends.
The recommendation deck had a strict format mandated by our senior director. I used it as a framework — mapping complex authentication systems through before-and-after flow maps that made years of tangled logic easy to follow at a glance. It became the template for how the team documents authentication experiences going forward. Future roadmaps are being built from it now.
The format was given to me. The clarity was mine to create.
What the funding window couldn't hold
Not everything could ship in 6 months — and that was always going to be true. Back-end authentication changes are multi-year programs. The recommendation deck was how those directions stayed alive — documenting the problem, the rationale, and the path forward clearly enough that the next team could pick it up without starting over. Several are now active programs. That was the goal.
A moment I'm most proud of
Turning something obscure into work that keeps going after the program ends.
The recommendation deck had a strict format mandated by our senior director. I used it as a framework — mapping complex authentication systems through before-and-after flow maps that made years of tangled logic easy to follow at a glance. It became the template for how the team documents authentication experiences going forward. Future roadmaps are being built from it now.
The format was given to me. The clarity was mine to create.
What the funding window couldn't hold
Not everything could ship in 6 months — and that was always going to be true. Back-end authentication changes are multi-year programs. The recommendation deck was how those directions stayed alive — documenting the problem, the rationale, and the path forward clearly enough that the next team could pick it up without starting over. Several are now active programs. That was the goal.
A moment I'm most proud of
Turning something obscure into work that keeps going after the program ends.
The recommendation deck had a strict format mandated by our senior director. I used it as a framework — mapping complex authentication systems through before-and-after flow maps that made years of tangled logic easy to follow at a glance. It became the template for how the team documents authentication experiences going forward. Future roadmaps are being built from it now.
The format was given to me. The clarity was mine to create.
What this shows
What this shows
The ability to create structure from ambiguity — defining a problem space when none exists, partnering with research to capture how customers actually live rather than how a system assumes they do, and shipping work that's legible enough for an entire organization to build on.
Strategic instinct about what to build, what to document, and what to hand off — so that a 6-month program leaves something behind that lasts. The alternate number for authentication initiative is proof that it did.
The constraint
Two realities shaped every decision:
• Funding window: 6 months — program ends, money stops
• Technical reality: true back-end authentication changes take years, not months.
The gap between those two things wasn't a problem to solve — it was a condition to design within. What could we ship in 6 months that was meaningful on its own and set up the next team to keep going? That question drove everything from prioritization to the recommendation deck.
IN.
No context switching. No dead ends.
Access granted — staying in context.
Strategy & Systems
Streamlining sign-in — Verizon
Lead Designer · Authentication Strategy · Cross-functional team · 6-month program
Lead Designer · Authentication Strategy · Cross-functional team · 6-month program
Overview
Verizon's sign-in flow required customers to switch contexts twice to complete verification — opening SMS for a tokenized link, then a browser page to allow access, then manually returning to where they started. The goal: eliminate the context switching.
NGD launched with a mandate to modernize authentication and almost nothing else. No defined scope. No design direction. A 6-month funding window. KPMG brought in to facilitate. I led design from day one — defining what the program would actually solve, partnering with UX research on a moderated usability study with 12 real Verizon customers, and shipping features within the constraint while building a recommendation deck for everything that couldn't fit inside it.
The alternate number for authentication initiative is now a formally funded initiative. The work is still being built.
Overview
Verizon's sign-in flow required customers to switch contexts twice to complete verification — opening SMS for a tokenized link, then a browser page to allow access, then manually returning to where they started. The goal: eliminate the context switching.
NGD launched with a mandate to modernize authentication and almost nothing else. No defined scope. No design direction. A 6-month funding window. KPMG brought in to facilitate. I led design from day one — defining what the program would actually solve, partnering with UX research on a moderated usability study with 12 real Verizon customers, and shipping features within the constraint while building a recommendation deck for everything that couldn't fit inside it.
The alternate number for authentication initiative is now a formally funded initiative. The work is still being built.
The constraint
Two realities shaped every decision:
• Funding window: 6 months — program ends, money stops
• Technical reality: true back-end authentication changes take years, not months.
The gap between those two things wasn't a problem to solve — it was a condition to design within. What could we ship in 6 months that was meaningful on its own and set up the next team to keep going? That question drove everything from prioritization to the recommendation deck.
The scenario that defined everything
A customer using her mom's phone to sign in. Verification link going to her own broken device. No alternate number on file. No other option available. Just a wall.
The research put it plainly: customers on shared accounts sometimes had to physically drive to the primary account holder to sign in. This wasn't an edge case. It was a system failure hiding in plain sight — and it became the north star for the entire design direction.
The systemic version of the same problem
The dead end scenario was one customer, one broken flow. But the inconsistency ran across the entire product. Mobile, FWA, and Fios each had completely different verification methods — non-Verizon numbers couldn't be used at all, leaving FWA and Fios customers with weaker, less consistent options. It wasn't one broken flow. It was the entire authentication system.
The systemic version of the same problem
The dead end scenario was one customer, one broken flow. But the inconsistency ran across the entire product. Mobile, FWA, and Fios each had completely different verification methods — non-Verizon numbers couldn't be used at all, leaving FWA and Fios customers with weaker, less consistent options. It wasn't one broken flow. It was the entire authentication system.
What the funding window couldn't hold
Not everything could ship in 6 months — and that was always going to be true. Back-end authentication changes are multi-year programs. The recommendation deck was how those directions stayed alive — documenting the problem, the rationale, and the path forward clearly enough that the next team could pick it up without starting over. Several are now active programs. That was the goal.
The constraint
Two realities shaped every decision:
• Funding window: 6 months — program ends, money stops
• Technical reality: true back-end authentication changes take years, not months.
The gap between those two things wasn't a problem to solve — it was a condition to design within. What could we ship in 6 months that was meaningful on its own and set up the next team to keep going? That question drove everything from prioritization to the recommendation deck.
What we built
(as of April 2026)
Alternate number for authentication — shipped
Customers can now authenticate via any number they have access to — not just the primary on the account. The verification link goes somewhere they can actually receive it. This work is now a formally funded initiative with its own roadmap.

What we built
(as of April 2026)
Alternate number for authentication — shipped
Customers can now authenticate via any number they have access to — not just the primary on the account. The verification link goes somewhere they can actually receive it. This work is now a formally funded initiative with its own roadmap.

The Problem
Verizon had 57.6K calls per month related to sign-in issues z, and 2 million password resets every month. Customers weren't just frustrated — they were completely stuck. A dedicated moderated usability study (12 Verizon wireless customers, January 2024) confirmed what we were seeing in the flows: the verification system was failing people in real, predictable ways.


Authentication settings redesign — app, mobile web, desktop
The legacy page was 11 years old — three viewports, three different UIs, broken components. We rebuilt it as one consistent system across all surfaces.
The Problem
Verizon had 68K calls per month related to passwords and authentication, and 2 million password resets every month. Customers weren't just frustrated — they were completely stuck. A dedicated moderated usability study (12 Verizon wireless customers, January 2024) confirmed what we were seeing in the flows: the verification system was failing people in real, predictable ways.
The scenario that defined everything
A customer using her mom's phone to sign in. Verification link going to her own broken device. No alternate number on file. No other option available. Just a wall.
The research put it plainly: customers on shared accounts sometimes had to physically drive to the primary account holder to sign in. This wasn't an edge case. It was a system failure hiding in plain sight — and it became the north star for the entire design direction.
A moment I'm most proud of
Turning something obscure into work that keeps going after the program ends.
The recommendation deck had a strict format mandated by our senior director. I used it as a framework — mapping complex authentication systems through before-and-after flow maps that made years of tangled logic easy to follow at a glance. It became the template for how the team documents authentication experiences going forward. Future roadmaps are being built from it now.
The format was given to me. The clarity was mine to create.


The systemic version of the same problem
The dead end scenario was one customer, one broken flow. But the inconsistency ran across the entire product. Mobile, FWA, and Fios each had completely different verification methods — non-Verizon numbers couldn't be used at all, leaving FWA and Fios customers with weaker, less consistent options. It wasn't one broken flow. It was the entire authentication system.


Authentication settings redesign — app, mobile web, desktop
The legacy page was 11 years old — three viewports, three different UIs, broken components. We rebuilt it as one consistent system across all surfaces.
What the funding window couldn't hold
Not everything could ship in 6 months — and that was always going to be true. Back-end authentication changes are multi-year programs. The recommendation deck was how those directions stayed alive — documenting the problem, the rationale, and the path forward clearly enough that the next team could pick it up without starting over. Several are now active programs. That was the goal.
What we built
(as of April 2026)
Alternate number for authentication — shipped
Customers can now authenticate via any number they have access to — not just the primary on the account. The verification link goes somewhere they can actually receive it. This work is now a formally funded initiative with its own roadmap.


Authentication settings redesign — app, mobile web, desktop
The legacy page was 11 years old — three viewports, three different UIs, broken components. We rebuilt it as one consistent system across all surfaces.
A moment I'm most proud of
Turning something obscure into work that keeps going after the program ends.
The recommendation deck had a strict format mandated by our senior director. I used it as a framework — mapping complex authentication systems through before-and-after flow maps that made years of tangled logic easy to follow at a glance. It became the template for how the team documents authentication experiences going forward. Future roadmaps are being built from it now.
The format was given to me. The clarity was mine to create.
What the funding window couldn't hold
Not everything could ship in 6 months — and that was always going to be true. Back-end authentication changes are multi-year programs. The recommendation deck was how those directions stayed alive — documenting the problem, the rationale, and the path forward clearly enough that the next team could pick it up without starting over. Several are now active programs. That was the goal.
A moment I'm most proud of
Turning something obscure into work that keeps going after the program ends.
The recommendation deck had a strict format mandated by our senior director. I used it as a framework — mapping complex authentication systems through before-and-after flow maps that made years of tangled logic easy to follow at a glance. It became the template for how the team documents authentication experiences going forward. Future roadmaps are being built from it now.
The format was given to me. The clarity was mine to create.
What the funding window couldn't hold
Not everything could ship in 6 months — and that was always going to be true. Back-end authentication changes are multi-year programs. The recommendation deck was how those directions stayed alive — documenting the problem, the rationale, and the path forward clearly enough that the next team could pick it up without starting over. Several are now active programs. That was the goal.
A moment I'm most proud of
Turning something obscure into work that keeps going after the program ends.
The recommendation deck had a strict format mandated by our senior director. I used it as a framework — mapping complex authentication systems through before-and-after flow maps that made years of tangled logic easy to follow at a glance. It became the template for how the team documents authentication experiences going forward. Future roadmaps are being built from it now.
The format was given to me. The clarity was mine to create.
What this shows
What this shows
The ability to create structure from ambiguity — defining a problem space when none exists, partnering with research to capture how customers actually live rather than how a system assumes they do, and shipping work that's legible enough for an entire organization to build on.
Strategic instinct about what to build, what to document, and what to hand off — so that a 6-month program leaves something behind that lasts. The alternate number for authentication initiative is proof that it did.
The constraint
Two realities shaped every decision:
• Funding window: 6 months — program ends, money stops
• Technical reality: true back-end authentication changes take years, not months.
The gap between those two things wasn't a problem to solve — it was a condition to design within. What could we ship in 6 months that was meaningful on its own and set up the next team to keep going? That question drove everything from prioritization to the recommendation deck.
IN.
No context switching. No dead ends.
Access granted — staying in context.
Strategy & Systems
Streamlining sign-in — Verizon
Lead Designer · Authentication Strategy · Cross-functional team · 6-month program
Lead Designer · Authentication Strategy · Cross-functional team · 6-month program
Overview
Verizon's sign-in flow required customers to switch contexts twice to complete verification — opening SMS for a tokenized link, then a browser page to allow access, then manually returning to where they started. The goal: eliminate the context switching.
NGD launched with a mandate to modernize authentication and almost nothing else. No defined scope. No design direction. A 6-month funding window. KPMG brought in to facilitate. I led design from day one — defining what the program would actually solve, partnering with UX research on a moderated usability study with 12 real Verizon customers, and shipping features within the constraint while building a recommendation deck for everything that couldn't fit inside it.
The alternate number for authentication initiative is now a formally funded initiative. The work is still being built.
Overview
Verizon's sign-in flow required customers to switch contexts twice to complete verification — opening SMS for a tokenized link, then a browser page to allow access, then manually returning to where they started. The goal: eliminate the context switching.
NGD launched with a mandate to modernize authentication and almost nothing else. No defined scope. No design direction. A 6-month funding window. KPMG brought in to facilitate. I led design from day one — defining what the program would actually solve, partnering with UX research on a moderated usability study with 12 real Verizon customers, and shipping features within the constraint while building a recommendation deck for everything that couldn't fit inside it.
The alternate number for authentication initiative is now a formally funded initiative. The work is still being built.
The constraint
Two realities shaped every decision:
• Funding window: 6 months — program ends, money stops
• Technical reality: true back-end authentication changes take years, not months.
The gap between those two things wasn't a problem to solve — it was a condition to design within. What could we ship in 6 months that was meaningful on its own and set up the next team to keep going? That question drove everything from prioritization to the recommendation deck.
The scenario that defined everything
A customer using her mom's phone to sign in. Verification link going to her own broken device. No alternate number on file. No other option available. Just a wall.
The research put it plainly: customers on shared accounts sometimes had to physically drive to the primary account holder to sign in. This wasn't an edge case. It was a system failure hiding in plain sight — and it became the north star for the entire design direction.
The systemic version of the same problem
The dead end scenario was one customer, one broken flow. But the inconsistency ran across the entire product. Mobile, FWA, and Fios each had completely different verification methods — non-Verizon numbers couldn't be used at all, leaving FWA and Fios customers with weaker, less consistent options. It wasn't one broken flow. It was the entire authentication system.
The systemic version of the same problem
The dead end scenario was one customer, one broken flow. But the inconsistency ran across the entire product. Mobile, FWA, and Fios each had completely different verification methods — non-Verizon numbers couldn't be used at all, leaving FWA and Fios customers with weaker, less consistent options. It wasn't one broken flow. It was the entire authentication system.
What the funding window couldn't hold
Not everything could ship in 6 months — and that was always going to be true. Back-end authentication changes are multi-year programs. The recommendation deck was how those directions stayed alive — documenting the problem, the rationale, and the path forward clearly enough that the next team could pick it up without starting over. Several are now active programs. That was the goal.
The constraint
Two realities shaped every decision:
• Funding window: 6 months — program ends, money stops
• Technical reality: true back-end authentication changes take years, not months.
The gap between those two things wasn't a problem to solve — it was a condition to design within. What could we ship in 6 months that was meaningful on its own and set up the next team to keep going? That question drove everything from prioritization to the recommendation deck.
What we built
(as of April 2026)
Alternate number for authentication — shipped
Customers can now authenticate via any number they have access to — not just the primary on the account. The verification link goes somewhere they can actually receive it. This work is now a formally funded initiative with its own roadmap.

What we built
(as of April 2026)
Alternate number for authentication — shipped
Customers can now authenticate via any number they have access to — not just the primary on the account. The verification link goes somewhere they can actually receive it. This work is now a formally funded initiative with its own roadmap.

The Problem
Verizon had 57.6K calls per month related to sign-in issues z, and 2 million password resets every month. Customers weren't just frustrated — they were completely stuck. A dedicated moderated usability study (12 Verizon wireless customers, January 2024) confirmed what we were seeing in the flows: the verification system was failing people in real, predictable ways.


Authentication settings redesign — app, mobile web, desktop
The legacy page was 11 years old — three viewports, three different UIs, broken components. We rebuilt it as one consistent system across all surfaces.
The Problem
Verizon had 68K calls per month related to passwords and authentication, and 2 million password resets every month. Customers weren't just frustrated — they were completely stuck. A dedicated moderated usability study (12 Verizon wireless customers, January 2024) confirmed what we were seeing in the flows: the verification system was failing people in real, predictable ways.
The scenario that defined everything
A customer using her mom's phone to sign in. Verification link going to her own broken device. No alternate number on file. No other option available. Just a wall.
The research put it plainly: customers on shared accounts sometimes had to physically drive to the primary account holder to sign in. This wasn't an edge case. It was a system failure hiding in plain sight — and it became the north star for the entire design direction.
A moment I'm most proud of
Turning something obscure into work that keeps going after the program ends.
The recommendation deck had a strict format mandated by our senior director. I used it as a framework — mapping complex authentication systems through before-and-after flow maps that made years of tangled logic easy to follow at a glance. It became the template for how the team documents authentication experiences going forward. Future roadmaps are being built from it now.
The format was given to me. The clarity was mine to create.


The systemic version of the same problem
The dead end scenario was one customer, one broken flow. But the inconsistency ran across the entire product. Mobile, FWA, and Fios each had completely different verification methods — non-Verizon numbers couldn't be used at all, leaving FWA and Fios customers with weaker, less consistent options. It wasn't one broken flow. It was the entire authentication system.


Authentication settings redesign — app, mobile web, desktop
The legacy page was 11 years old — three viewports, three different UIs, broken components. We rebuilt it as one consistent system across all surfaces.
What the funding window couldn't hold
Not everything could ship in 6 months — and that was always going to be true. Back-end authentication changes are multi-year programs. The recommendation deck was how those directions stayed alive — documenting the problem, the rationale, and the path forward clearly enough that the next team could pick it up without starting over. Several are now active programs. That was the goal.
What we built
(as of April 2026)
Alternate number for authentication — shipped
Customers can now authenticate via any number they have access to — not just the primary on the account. The verification link goes somewhere they can actually receive it. This work is now a formally funded initiative with its own roadmap.


Authentication settings redesign — app, mobile web, desktop
The legacy page was 11 years old — three viewports, three different UIs, broken components. We rebuilt it as one consistent system across all surfaces.
A moment I'm most proud of
Turning something obscure into work that keeps going after the program ends.
The recommendation deck had a strict format mandated by our senior director. I used it as a framework — mapping complex authentication systems through before-and-after flow maps that made years of tangled logic easy to follow at a glance. It became the template for how the team documents authentication experiences going forward. Future roadmaps are being built from it now.
The format was given to me. The clarity was mine to create.
What the funding window couldn't hold
Not everything could ship in 6 months — and that was always going to be true. Back-end authentication changes are multi-year programs. The recommendation deck was how those directions stayed alive — documenting the problem, the rationale, and the path forward clearly enough that the next team could pick it up without starting over. Several are now active programs. That was the goal.
A moment I'm most proud of
Turning something obscure into work that keeps going after the program ends.
The recommendation deck had a strict format mandated by our senior director. I used it as a framework — mapping complex authentication systems through before-and-after flow maps that made years of tangled logic easy to follow at a glance. It became the template for how the team documents authentication experiences going forward. Future roadmaps are being built from it now.
The format was given to me. The clarity was mine to create.
What the funding window couldn't hold
Not everything could ship in 6 months — and that was always going to be true. Back-end authentication changes are multi-year programs. The recommendation deck was how those directions stayed alive — documenting the problem, the rationale, and the path forward clearly enough that the next team could pick it up without starting over. Several are now active programs. That was the goal.
A moment I'm most proud of
Turning something obscure into work that keeps going after the program ends.
The recommendation deck had a strict format mandated by our senior director. I used it as a framework — mapping complex authentication systems through before-and-after flow maps that made years of tangled logic easy to follow at a glance. It became the template for how the team documents authentication experiences going forward. Future roadmaps are being built from it now.
The format was given to me. The clarity was mine to create.
What this shows
What this shows
The ability to create structure from ambiguity — defining a problem space when none exists, partnering with research to capture how customers actually live rather than how a system assumes they do, and shipping work that's legible enough for an entire organization to build on.
Strategic instinct about what to build, what to document, and what to hand off — so that a 6-month program leaves something behind that lasts. The alternate number for authentication initiative is proof that it did.
The constraint
Two realities shaped every decision:
• Funding window: 6 months — program ends, money stops
• Technical reality: true back-end authentication changes take years, not months.
The gap between those two things wasn't a problem to solve — it was a condition to design within. What could we ship in 6 months that was meaningful on its own and set up the next team to keep going? That question drove everything from prioritization to the recommendation deck.