A framework is only useful as the culture and people that adopt it. Verizon’s Customer Intent model had strong internal support, but scaling it across a matrixed organization meant more than better documentation. It meant changing how design teams thought about their day-to-day work, and building relationships with the teams whose buy-in the framework depended on.
Prior to this project, the Customer Intent framework only mapped cleanly to a few project types, and there was no central hub for the templates, guidance, and examples teams needed to actually use/implement the framework in their day-to-day work.
I contributed to closing the gap by co-developing the Customer Intent Playbook, including its plays and templates. I also contributed in building implementation materials to show designers how the framework fit into their existing process, as well as designing and facilitating workshops that upskilled design teams to operate with a more customer-centric mindset.
Customer Intent is Verizon’s internal framework for organizing customer needs around what they are actually trying to accomplish while they’re interacting with Verizon, rather than around internal product verticals or channel structures. It encourages Verizon team members to approach problems from the customer’s lens and act accordingly, rather than focusing on siloed business objectives.
A framework is only as useful as the culture that adopts it. Verizon's Customer Intent model had real internal support, but no central hub for the templates, guidance, and training teams needed to actually put it into practice. This gap wasn't a documentation problem. It was an adoption problem.
Understanding the adoption gap
We interviewed 14 participants across design roles in CX Design, paired with a stakeholder process audit, to understand why the framework wasn’t sticking. In this process, I contributed by creating the research plan and interview questions. The findings were consistent: no standard customer-centric approach across teams, difficulty locating the right stakeholders for a given project, and difficulty balancing customer needs against business goals in day-to-day practice.
Building the plays
Building the plays
I contributed to developing the Playbook’s core content where we have 11 interactive “plays”, structured templates and activities such as Customer Intent Empathy Mapping, Identifying Customer Needs, Understanding Customer Mental Models, etc. These plays were each designed to be usable independently by a designer with no prior training in the framework. We also provided multi-media materials on what Customer Intent is on the Playbook.
Designing for implementation, not just documentation
Beyond the plays themselves, I built presentation decks showing how the framework could be woven directly into designers’ existing process, not only as an additional step or an after-thought, but directly integrated into how work already got done. In addition to showing these decks to designers, we also presented the proposed implementation process to other teams that designers work closely with, such as the Customer & Market Insights (CMI) team and Experience Managers.
Previews from the deck that we used to present to both the Design team and stakeholders on how we will be engaging with them and how they could reach out to us on how to implement the Customer Intent framework into their processes
Facilitating the mindset shift through workshops and consulting teams in projects
Knowing that self-service resources alone wouldn’t be enough and teams needed guidance to interpret and apply them consistently, I designed and facilitated workshops to upskill designers directly, with the objective to build the muscle of customer-centric thinking, rather than just handing over a reference document. In addition to workshops, I also got embedded in some team projects and consulted with teams on how they could implement the Customer Intent framework and approaches into their project.
Examples or participant workshop workspace taken from the Customer Intent Upskilling Workshop series where I incorporated exercises and templates from the Playbook to empower participants with customer-centric approaches in their day-to-day design processes
Building the framework turned out to be the easier half of the work. Teams didn't need a better document or a flashier artifact. They needed help changing how they already worked. This wasn't a product to ship. It was a change management effort that happened to product a Playbook.
Outcome
The outcome of this project is more qualitative than quantitative. By the time this case study was being written, the Playbook was live at a public-facing internal site, shipped 11 plays for the Playbook, and moved the roadmap from building foundational content to functional content. We also have a built-in engagement tracker into the Playbook as well as developed a process where teams could reach out to us when they need guidance on how to implement Customer Intent framework into their projects, and this has gotten us involved with 20+ projects.
In addition to that, we've also started hearing some good feedback from stakeholders and design leaderships about how designers have started to gradually frame their projects differently, more critically and taking the lens of customers. That being said, we acknowledged that there is still a lot of continuous work and improvements we need to do, and that this is a work of cultural change that doesn’t stop with us releasing the Playbook to the team.
Learnings
What I’ve learned from this project was that building the framework turned out to be the easier half of the work. The interviews made clear that teams didn’t need a better document or artifact, they needed help changing how they already worked, which meant this was more of a change management effort that happened to produce a Playbook, not the other way around.
I also noticed that the plays that landed best were the ones designers helped shape themselves or ones they gave detailed input on, which meant co-creation wasn’t just good research practice, it was the actual adoption mechanism.
Last but not least, I learned that the harder balance was staying close enough to real project problems to remain useful and trusted, while still holding a standard firm enough for the team to strive for. I learned how to hold and navigate both authority and accessibility, that are constantly pulling in opposite directions in this project.
