How EA Moved from Shipping Features to Shaping Journeys

Andra Bond, Olivia Lucas at UXDX USA. Video: https://youtu.be/V4ittd1t360

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

The request that has no product attached to it

[00:00:08] Andra: Maybe this sounds familiar to some of you. You get a request, something like "we need to remove friction from the experience" or "add personalization". Or maybe it's something more specific, like "we want to create a loyalty program". It's an OKR. Leadership is aligned and there's probably multiple teams pointed at solving the problem. But nobody has a product that they're going to build. Nobody has a definition for the experience yet. You just have a lot of teams who are trying to move fast and get something shipped. Hi, I'm Andra Bond and I run the CX discovery and experimentation team at Electronic Arts.

[00:00:46] Olivia: And I'm Olivia Lucas, a service designer at EA. So today we're going to talk to you about how we move teams from shipping features to shaping journeys. We're going to cover the tools and frameworks that help us keep customers at the center of what we do, build shared understanding and alignment across many, many different teams, and create the clarity needed to deliver cohesive experiences.

[00:01:11] Andra: Before we dive into all that, we want to provide some context about the environment we work in, because it's shaped what we're going to talk to you about today. EA has roughly 14,000 employees. That is a lot of different teams, and it includes both centralized and decentralized teams, all of whom operate on their own tech stacks with different timelines and different processes. This creates a uniquely complex environment.

[00:01:41] We have over half a billion customers around the world, and those customers don't just play a single game. They actually play across our ecosystem. They play multiple games, and often they're showing up for years in our ecosystem, and hopefully lifetimes. So there's a lot of complexity in what we're designing for, the experiences we're designing for, the teams that we're working with. Today's talk is really Olivia and I picking little cherries from our design process that we hope help you understand how we operate in complexity, how we bring design through that complexity and deliver better experiences. So yes, we're going to talk about our design process, but we're just going to talk about a few key ways that we work.

Fan need identification

[00:02:27] Oops, wrong slide. Okay, let's get into it: the way we work. We have something that we do in the discovery process that we call fan need identification. This is absolutely where we're looking at and understanding the signals that we already have from our customers. Oh, and by the way, our fans, we use that word interchangeably at EA. Our fans are our customers. But in fan need identification and discovery, we're really grounding ourselves in understanding that we're looking at those signals. We're understanding the touch points that make up a fan need across our business, because it's complex.

[00:03:08] I like to use this analogy when we're talking about data, when we're talking about fan needs and understanding what we know about our customers. At EA, like I'm sure most of your companies, we have a lot of data. It's like the night sky. There are billions of data points like there are stars. It's beautiful, overwhelming, and hard to navigate. Most teams are only really looking at data from their point of view, from their product, their feature, or their channel. And that's by design. We need people who are experts at their products and in their spaces. But when they're only looking at their signals and building their road maps based off that data, it can cause problems. It can make them make choices that don't fit the whole experience.

[00:03:52] What we've seen, and I'm sure you guys have heard this term before, is that that's when you get siloed, and that's when you get products or experiences where teams are just shipping their org chart. I'm sure you guys have had an experience like that, where something seems seamless and the handoff from one system to the other just doesn't work. So I'm going to give you guys an example of something that we saw at EA a few years ago.

[00:04:21] One of our big titles, I won't talk about game names, but one of our big titles came up with a feature that they wanted to ship, and it was a really cool feature. Everybody was super pumped about it. This is a game that came out every year, and that feature was something that was going to connect this big AAA game, like Xbox, PlayStation, console, to one of our mobile SKUs, a totally different game. It was a great idea. We were going to connect these ecosystems. We were going to connect these player bases, and everybody was really excited about it.

[00:04:53] It was a good feature until it launched and it totally broke. And it didn't break because the feature was designed poorly or the code was bad. It broke because we didn't understand the actual experience. We didn't understand the connections and our touch points and all the products and processes that went into it. In retrospect, this is kind of hard to say out loud, but we realized that people didn't actually even know they had an EA account. So when they went to connect these game experiences, it just totally broke. This is the kind of problem we want to fix in fan need identification, in that discovery, in that beginning before we begin designing. We want to understand the experiences and the touch points we need to design for.

[00:05:40] I like this concept of a constellation when we're talking about this, because when we're talking about an experience, at least in our world, it's not linear. Players don't go from one touch point to another in a perfect line. It's more like a constellation. These are the kinds of patterns we want to identify and create maps for, for our teams, so that we can navigate these things together. Here's an example of a constellation, where you have all these different touch points that people may not think about when they begin that design process.

The experience atlas

[00:06:17] Okay, great. It's a good idea, mapping these touch points. But something unique that we do is we created something called an experience atlas. So we're taking it a step further, which is not just saying we want to define these things when we begin the design process, but we actually want to have a practice around this where we speak the same language, where we're optimizing these experiences consistently and together. That's what the experience atlas serves for us. And it's made up of these key elements.

[00:06:50] The first is that it's a shared taxonomy, a governed taxonomy. Yes, that means there's a process there and there's a team you have to go through to update the language. But when I say "what is the refund flow", everybody understands that there is a definition for that and there's a place to go look it up and understand what that is. It's a shared language for all of us to start from. It also has the definitions of our touch points. These are the major touch points that we've identified that should be included in that.

[00:07:23] And then the signals. The signals are the ways we measure these touch points. And I don't just mean we say what the signals are. The experience atlas is actually a reporting tool, so that we can see and understand these measures in a uniform way and look at these experiences against each other. You know which experience has the most customers visiting it. Which experience is performing the best? It makes it easier to have it all documented and consistently updated.

[00:07:52] And then my favorite thing is the business outcome. Again, this is just changing the point of view from just being a product focus or a single channel focus to being across an experience, where multiple product teams can get aligned on a business outcome at the experience level. Business outcomes are important. That's what helps us understand, when we get in the room, how to build road maps, how to decide what features should be shipped, because we know that if we don't have that feature, we can't deliver on a business outcome.

[00:08:26] We built this experience atlas for a big project we did a couple of years ago, and I was really happy to see it really take off and not just be a design artifact. We all know what those can be. You spend so much time documenting stuff and then it just never gets looked at again. This is actually something that we operationalized. The operational teams that work on processes, that do marketing updates on our pages, they go in and they look at this and they own it. It becomes part of how we work.

[00:09:02] Just a side quest note: when we first built the experience atlas, it was really painful. I used to have a picture of the Google doc, which it actually is, because it was a lot of synthesizing and manual mapping and figuring out how all these different things actually fit together into a single document across teams. We're actually productizing it right now. It's a project we're working on this quarter, where we are using AI to synthesize a lot of this data and make that manual processing and manual updating, particularly around the reporting of the metrics, automated. It's going to be really cool. I'd love to talk more about it another time, but I'm going to pass it to Olivia to talk about the rest of our process.

Design sprints and the north star

[00:09:47] Olivia: Do you want to talk about design sprints?

[00:09:49] Andra: Sorry, I forgot I'm doing design sprints, part two. So yeah, we do a lot of discovery. It's really important to be grounded in our fan needs and in our data. And then I'll just touch on design sprints briefly. Design sprints, I'm sure you guys all know what those are. This is where we're really building our north star for our experience. What I love about the transition from discovery to design sprints, and the fact that we have this mapping, is that we know what teams to bring in the room to make sure that we have divergent thought when we begin ideating and building that north star.

[00:10:27] We know, especially in the complexity that we're operating in, that we can't just have designers and product managers building interfaces in a room. We need the people in there that are doing the policies, that are creating the processes, that are doing the behind-the-scenes systems that are enabling these experiences to happen, to be a part of that process with us.

[00:10:50] I love this picture from Jeff Patton. I'm sure you guys have probably seen it before, but just the idea of the other power of design is that we're taking words and ambiguity and all these things that people talk about and they think they understand and have defined, and we're making something tangible and real and clear. So whether it's a storyboard or a prototype built in any kind of way or fashion, we're turning words into a thing that we can all leave the room understanding exactly what we want to go and build. It's the north star. It's getting everybody rallied and aligned around that, so that we're not leaving the room speaking different languages.

From vision to delivery: evolution mapping

[00:11:34] Olivia: Now it's time. Everything Andra just mentioned about getting teams aligned to that ideal future state, that north star vision, is so important, but it isn't enough, and it certainly is not where our team's work ends. Because the big vision isn't what we go off and build all at once. That's what we're continuously working towards. So the next challenge for us was, how do we move from vision to delivery without losing everything we just worked so hard to uncover? Again, that fan need, the value that matters, everything that makes the experience meaningful.

[00:12:10] That's where we move to the next part of our process today: evolution mapping. This is named after the tool that we're going to talk a little bit about today. This is where we start to break down the vision into what we're going to execute on. We're continuing to pull the thread of alignment that has been something we've been talking about this whole time, but this time we're aligning teams to who's delivering what when.

[00:12:35] At EA we build iteratively, but I want to be really careful to explain what I mean by this, because we aren't shipping pieces of a product or even a single product. Our goal is always to ship small but complete experiences. Small here isn't necessarily size, because it may be a huge project or a big idea. It's just going to be a smaller part of that overall vision.

[00:12:58] And when we say complete experiences: our fans come to us with a goal, something like play a game with friends. They should be able to achieve that goal from start to finish. That means they go through their end-to-end journey receiving value at every step, not hitting any dead ends or endless loops. So that's always our goal, small but complete experiences.

[00:13:21] To help show what I mean, I'll use this illustration from Henrik Kniberg. Before I get into it, I'm curious: show of hands if you've seen this illustration before, raise your hand. Yeah, a lot of people. If you haven't, really exciting, because it's such a good illustration. It does a really good job of showing exactly that iterative development where each iteration is that complete experience. The first iteration being a skateboard, not a car wheel, but an entire skateboard. So it solves for the fan need of transportation, getting them from point A to point B, and it gives the team something to put out in the world and learn from as they build toward the north star vision of the car.

[00:13:59] But we have a lot of planning that goes into each iteration, because we never, or rarely but probably never, have a single team building out something like a skateboard. There may be a team building the deck, another building the hardware, a third building the wheels, a fourth building out fulfillment services, and a fifth building out payment services. Iteration one is only complete if all of these teams coordinate and ship their piece. Because what's a skateboard without wheels, or the experience of buying a skateboard if there's no way to pay for it? The customers never care, probably never have, never will, how many teams it takes to ship something. If it's a skateboard, they care if they can buy it or if they can ride it.

[00:14:43] So this is exactly why we adopted the tool of evolution mapping. It pulls everything we need to align teams to, for each iteration up to the big vision, into a single view. For each iteration we map that fan need that we intend to solve for, to the business outcome we intend to deliver on, to all the teams needed to make it real. This is how we make sure that work from fan need identification through design sprints doesn't get lost in execution, and it keeps teams aligned to the same thing from the start: that complete experience at each iteration.

The loyalty program

[00:15:23] Last year our team helped launch a loyalty program, and it was exactly the kind of project that showed us why evolution mapping matters. It was a complex thing to pull off internally. There were a lot of program mechanics, so there were many concepts that we were trying to execute under this one program. There were also, like we've talked about earlier, a lot of teams involved, a lot of teams that it would take to make this real. And many of those teams were working together for the first time ever.

[00:15:51] As we went through our process, we found that the real value in this loyalty program was in rewarding fans in a way that connected deeply to their gameplay. So for our first evolution fan need, we mapped "rewards that are meaningful because they connect to game progress". That connection to the game is also what drove that business value. So for our first evolution business outcome, we mapped "increased in-game engagement". And then we mapped both that fan need and business outcome to all the teams it would take to make it happen, and we had our first evolution in our map.

[00:16:30] As development was underway, the game team came and said they could no longer prioritize connecting in-game actions to rewards. They had higher priority items on the road map they had to finalize before game launch. Well, this is where the evolution map really shines. We ground back to that fan need, rewards that are meaningful because they connect to gameplay progress. We ground back to the business outcome, increased in-game engagement. If the game team couldn't deliver the connection, we couldn't deliver on either of those.

[00:17:03] We were left with a generic rewards portal with no connection to the game. So naturally, the next question was: do we just ship that? But with the evolution map, we had that clear understanding of what a complete experience would be for our first iteration. We knew that a generic loyalty portal that offered rewards for things like "like us on Facebook" or "follow us on X" just didn't deliver the value needed.

[00:17:33] So with evolution mapping, if one piece changes or one dependency goes missing, we have a clear standard to check against. We can see if we're still delivering a complete experience or if we introduced a gap in value. And when we set that standard and align to it from the beginning, it becomes a lot easier, as we're moving through the process, to say, wait a minute, are we headed down the wrong path?

[00:17:54] Because like we mentioned earlier, when we're working on these projects, there is that pressure to move fast and to keep momentum, to achieve our OKRs and keep going and report on that quarterly. And when we're in that environment, it becomes really easy to just keep pushing to keep momentum and accept whatever becomes shippable. In the loyalty case, it would have been that generic rewards portal. But if we ship something that's disconnected, doesn't fit the journey or solve a fan need, the experience is going to suffer. The fan is going to feel that and we're never going to achieve our business outcome. So now the standard we try to hold is not "what can we ship", but "will this bring value". And evolution mapping is a really helpful tool for us to do that.

Recap: the habit, not just the tools

[00:18:45] Andra: Thanks, Olivia. I love evolution mapping. It's something that Olivia brought to the team a couple of years ago when she came and it's really changed the game for us. Just to recap what we talked about with everyone: we start with fan need identification. This is a key part of our discovery process where we really ground ourselves in not just what the fan needs, but what these experiences are, what touch points, processes and policies and things in our ecosystem we need to consider before we even begin the design process.

[00:19:16] We use our design sprints to really ground us in the north star vision and make sure that we're bringing in divergent thinking from around the company, to make sure that we've thought through the entire experience, so that when we go into delivery and execution we have the right plan in place. We use evolution mapping to produce something in a timebound time frame, so that when we deliver something day one it's not just about delivering a feature or an MVP. It's about delivering a whole experience that we're confident is going to deliver value to our fans.

[00:19:55] We didn't talk about measures, but measures of course are the undercurrent of all of this. We're constantly measuring. We obviously measure the output and the outcomes of our experiences and that feeds back into our process.

[00:20:15] I hope that this was helpful. We know that ambiguity, and big projects that seem harder to get done than ever, are not going to go away. But we believe that this process really helps provide clarity, brings teams together, creates that collaboration from the start that helps teams go faster and deliver better experiences.

[00:20:38] And honestly, the tools are really helpful. They've helped us a lot. But we find that it's more about building this habit. That habit of asking, what is the fan need underneath this? What does complete look like at this stage? Are teams aligned to that complete experience at each iteration and not just the big vision? And we found that when we started embedding this type of thinking in the way teams work, the work is getting better, the experiences are getting better, and the fans don't have to feel like we shipped our org chart. Thank you.

Q&A

[00:21:15] Host: All right, that was great stuff. Okay, we have plenty of time for some questions here. Let's see what we have. Okay, we'll start at the top here. How do you raise concerns to stakeholders about features that don't deliver value to the user?

[00:21:33] Olivia: Do you want me to start? Okay. That's why the theme of alignment that we tried to carry throughout is so important, because making sure the right people are in the room from the beginning. Who are these teams that we need, are they aligned to what that value is at every step? Making sure, if people aren't aligned to that, that there is the space to talk about that, because everyone, in the interest of the constellation, we all have our unique perspectives that are important to consider. So making sure all voices are heard from the beginning is what we try to do. Get everyone in the room, and then that helps keep everyone aligned to what that value is. So when there is a change to that, even if it's not the loyalty example we gave where there's a stark contrast, it's still obvious enough that you're able to say, this isn't the value we agreed upon. This is something different. Does this even bring value? And then you either pivot or move on to something else.

[00:22:33] Host: Did you get any pushback in implementing these processes from other disciplines?

[00:22:39] Andra: Yes, I think yes. We've talked about the value of design and bringing people along on that journey. You go find your champions, the people that understand it, and bring people along. But not everybody understands the value of it from the get-go. I think you just have to implement a little bit at a time and show value and bring people along in that process.

[00:23:05] Olivia: Yeah, I think it's always one of the hardest things anywhere I've worked as a designer, is coming in and just being like, just trust me, this is going to work. So you have to really be pragmatic, and I think Andra's so great at this. You have to work with teams in a way that works for them, and build that trust and get that buy-in, because you can't just walk in and be like, here's my framework, we're going to use it and it's going to work. I wish. It takes a while to build up that trust, and I think someone did a really good job of talking earlier about design maturity. I think that plays a role too, and you can only do so much at a time.

[00:23:40] Host: Any tips on how to build trust or gain that influence when implementing something new?

[00:23:44] Olivia: I think I would say find your champions, find your people, and bring people along with you. I love, we say "shitty first draft", I don't know if I can say that, but I love putting ideas out there and bringing people along to give feedback, and being as open as you want them to be with you. You have to be the same and receptive to that feedback and change.

[00:24:08] Andra: And it can be fun seeing that take a life of its own. Like with the experience atlas, when we created it, it was like three of us working on it, and then suddenly it was like 15 people's product. And it was like, wow, own it. I want to see that kind of evolution in the way teams think and work together.

[00:24:28] Olivia: Yeah. And what I like about our team is we treat it almost like a design problem, about bringing people along. So we're always looking for ways to improve our process internally and make sure that the people we're working with are receiving the information well and that it's working in that sense. We're always checking in on our process about how to do that and improve that.

[00:24:45] Host: Great. How, as a company, did you make that go/no-go decision around the generic loyalty portal?

[00:24:55] Olivia: Yeah, I think that's a great question. Actually, like I said, there were a lot of people involved. So it was definitely a lot of voices that had to be heard, a lot of key stakeholders. It wasn't easy, and there were pivots. A lot of what we talked about, it doesn't work perfectly. We still aren't the most mature design organization. So yeah, it wasn't easy. There were definitely some pivots made, and I will say we didn't end up with exactly the value that we had outlined from the beginning. But at least we were involved early enough in the process and helped shape what the experience could look like, to try to stay grounded in that fan need and the value that we needed to deliver, and just try to keep designing towards that.

[00:25:43] Host: Did AI help you come up with the experience atlas framework and the fan experience touch points and signals and measures? And if so, in what way, and if not?

[00:25:54] Andra: Not in the beginning. We created the experience atlas a few years ago, before I even really was playing around with AI too much. It was manual, in a spreadsheet, tagging content, thousands and thousands of rows of content, to get the data in the place that it was, but it was worth it. But today, productizing it, we built a prototype a few months ago and now we're in production for using LLMs to do that kind of manual synthesis, or to replace the manual synthesis with AI. So yeah, that is the future.

[00:26:33] Host: Okay. What does it look like in practice to embed this kind of thinking on your teams?

[00:26:40] Olivia: I would say it's not like one big moment where you're just like, this is the way we're thinking now and everyone's on board. It definitely could be painstaking at times. But it's in the little things we do every day, the little collaboration moments, like Andra said, finding the people that are going to help you champion your work. It's a lot of, especially at EA because it's so big, a lot of networking, meeting with people and meeting people where they are. So it's definitely in the day-to-day work and, again, building up that trust and that collaboration over time. And I feel like one day you're like, oh wow, this is working a lot better than it was. But yeah, it definitely takes time, and sometimes years. I think a lot of people think, oh, I can give a presentation on this concept or this way of working at the kickoff and then we'll just do it. And I like to remind people that you have to remind people every time you meet, until it becomes something that they're thinking too.

[00:27:40] Andra: Yeah. I heard someone at a conference once say frameworks are like toothbrushes: everyone has one, but no one wants to use someone else's. And I feel like that was the best thing I ever heard. It's so true.

[00:27:54] Olivia: I like that.

[00:27:57] Host: Is it possible to make this impact in an org that doesn't prioritize users' full experiences, and how do you bring this thinking to places with more resistance? Definitely a theme there with the questions that are coming in.

[00:28:08] Andra: We talk a lot about friction. I've spent maybe the last 10 years of my career at EA talking about friction and helping to illuminate it and put a business value on it and figure out, how do we actually measure this? How does it map back to retention, and telling that story? So I don't know if I'm getting off track with the question here, but I think you have to understand and connect it back to the business impact it has. If I'm saying hey, we need an experience atlas, or we need this process, the story has to all come back to "and this is why it matters". This is what we did. This is the impact it had on the big KPIs we're all going after.

[00:28:54] Olivia: Yeah, I think exactly that.

[00:28:57] Host: It looks like there's a question here for Olivia. Maybe we can move the next one down. Thinking of Olivia's role in bringing evolution mapping to the table and helping prioritize features and user and business needs, and the differences between service design and PM: have you seen any overlap or key differences?

[00:29:15] Olivia: Yeah, I think there's definitely, anywhere I've worked also, there's always a lot of role overlap, which sometimes can be a point of contention or sometimes can help you deliver the best work, because then it's more people that have these skills and perspective. I think our team is really good about leaning in and saying we don't have to own everything or do everything. We could build off each other's work, so we try to do that.

[00:29:50] And then again it's like bringing people along. If you have a good relationship with the, I'm going to take it as, product manager, then you're able to build that trust over time and they'll take more of your frame, you take more of theirs, and you also figure out how you could adjust your process and learn from them better. So I don't know if there's anything key to call out. There's actually a PM I work with here who, for example, she brought a RICE model, and I've never used a RICE model in my work but I thought it was awesome. I have tons of prioritization frameworks in my pocket ready to go, but I really liked the thinking that she used through that. So we're never sticklers for our process, because I think that's where design teams can die, by trying to be like, this is our process and we're sticking to it. So we try to be flexible and adapt to what other people are doing as well, and just try to get the best results and really just make sure we're focused on user needs, business needs, and driving up, like, what is the value we need and how are we getting to it? When we focus on that, it's less about the tools and frameworks and more about just how we're going to do it together.

[00:31:00] Host: Yeah, I love that. I love the collaboration side of it. I know we're close on time. There's one more here, maybe we could get to it quick, but it definitely has some upvotes. Is there a major difference between the experience atlas and the design system, and is the experience atlas more universal?

[00:31:13] Andra: Yeah, we have a lot of design systems at EA, and we have a design system on our team. It is totally different. The experience atlas is like a modern voice of the customer tool. It is based on customer feedback, customer data, classifying that into experiences that we want to design for, where we need to provide service, where we need to be thinking about and making sure that we're delivering on those experiences. So they work together, I guess, but they are totally different things.