EADP Engagement Model & Workflow

Problem: Teams arrived with under-defined problems; work ballooned from “2–3 weeks” to months
Stakes: Missed deadlines, thrash, strained relationships
My role: Co-created detailed workflow, entry criteria, journey maps, and a RACI; published runbook
Outcome: Clear gates & expectations, tighter scoping, accurate timelines, improved cross-functional trust

Project Overview

In EA’s Digital Platform, a small design team faced a flood of “ready for hi-fi” asks that weren’t. Product partners arrived under tight timelines and limited dev capacity, but key discovery was missing. We’d commit to what looked like 2–3 weeks of polish and end up in months of upstream research—frustrating teams and blowing dev deadlines.

Approach

My lead designer and I had several brainstorming sessions where we attempted to dive in to, why are we having so many projects drag on? Why do we continue to have mismatched expectations? We first went back to fundamentals.

Generally, my team subscribes to the double diamond approach to design, with the main tenets being Discover, Define, Develop, and Deliver. What we found was, a lot of our partners in the product team were attempting to do discovery and definition while we developed a solution. This explained why we kept going over the allotted time: what was presented to my team as a defined problem wasn’t, and so the Develop phase was being overstuffed with all the work of the phases before it.

Solution

We decided to tease out all of the steps involved in designing a product, being deliberately detailed about what is involved in every phase. This included building out the Mira board shown here, with high level descriptions of each step, flowcharts of the process throughout, and exhaustively detailed runbacks for each of the nine steps. Each step has entry criteria, showing what is required to have been completed prior to that step in order to began that step. Once implemented, this completely eliminated ambiguity about what part of the process we were in when the product team engaged the design team. If certain criteria for entering, say, the Solution Recommendation step had not been completed, it was clear to everyone that we weren’t yet prepared to enter that step. By gaining clarity up front of where a certain design ask was in the workflow, we were better able to determine sizing and give much more accurate estimations. This dramatically improved the working relationship with our partners in product and engineering.

Summary of the Workflow Steps

Here are steps one through three: Identifying the Problem, Discovery, and Define Scope & Requirements.

Summary of the Workflow Steps

Steps four through seven: Confirm Problem, Solution Recommendations, Validation, and Package & Approval.

Summary of the Workflow Steps

Steps eight and nine: Consult & Integration Support and Measure & Improve.

Key for the User Journey Maps

Workflow User Journey Maps

Workflow RACI Chart

This RACI Chart defines what roles are Responsible, Accountable, Consulted, and Informed for each step in the Design Workflow.

Example Runbook

This is the Runbook for Step Five - Solution Recommendations. This gives the product owner detailed specs on what is expected from them to enter this step, and what expected outcomes are.