DESIGN
Every team has unique attributes and constraints that shape its design process.
End to End Design (E2E)
The E2E Design framework is an enhanced version of the classic iterative design process.
On paper, the iterative process makes pretty good sense. In practice, depending on how it is interpreted, there are at least 3 critical gaps ( view on diagram ):
- Design teams don't know what they don't know at the initial Planning phase.
- Design team's ability to iterate effectively is blocked during the Design phase.
- Engineering team's ability to understand user requirements is compromised by assumptions.
When these gaps go unadressed, the impacts to the customer and user experiences can range from minor inconveniences and missed opportunities, all the way up to critical incompatibilities that are costly for customers to work around and expensive for product teams to fix.
E2E Design addresses the gaps by building aligned understanding about business, user, and functional requirements on the cross-functional team so that the solution addresses holistic needs and performance can be tracked in production.
See the video above for a more verbose description of the E2E Design process.
PROCESS
At VMware, I deployed two frameworks in response to the team's unique needs.
Tri-Track Agile
The E2E design process assumes leaders from UX, PM, and Engineering are aware of the gaps in user and business requirements as described at left.
It also assumes the cross-functional team has been provided a process framework that addresses the gaps in a way that compliments business-critical DevOps and delivery cadences.
The Tri-Track model solves for this by adopting the vernacular of agile development, while also establishing a more holistic requirement gathering and team onboarding workflows.
The model dictates that "planning" phase activities necessarily includes investigation of the user's environment and needs relative to the business opportunity. It also indicates that planning should occur in parallel to ongoing tactical design and implementation work.
Finally, the model assumes that someone on the team – typically either UX or PM – is taking responsibility for synthesizing user research data into tangible, user-centric perspectives that are enumerated as requirements with appropriate emphasis relative to business and functional concerns.
