EADP Experience Design Engagement Model and Workflow

In the EA Digital Platform organization, we were a small design team under tight deadlines. We would get lots of product owners coming to us with needs, under their own constraints of time and developer resources. In these circumstances, it was understandable that the product team would often bring us projects that they felt were ready to go into high-fidelty designs, but in reality, were missing a lot of the details and discovery work necessary to make a good design. The problem was we were often agreeing to work that looked on the surface to be 2-3 weeks of fleshing out the design of fully-formed ideas, but became months of iterating through early discovery and research before getting to a real design. This led to a lot of frustration from the product team, as well as missed deadlines for the developers.

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.