AgileUncategorized

UCD and Enterprise Business Agility

Earlier this week, working with clients in a large global organization, I received a question from some folks responsible for design in another area of the organization. They are experts in design but had not yet been exposed to Agile practices at an enterprise level. This was “first contact” with the Transformation for them. Here is the gist of one of their questions (Note: I’m paraphrasing how the question was asked):

We are concerned because we do not see how a User-Centered Design (UCD) process is evident in the System of Delivery being established as part of our Agile Transformation.

We define UCD as an iterative cycle which includes the following elements:

a. Empathize
b. Define
c. Prototype
d. Test
e. Implement

Here’s my response:

Hey {awesome design leaders},

You will already know most of this, but may not have seen it presented from the frame of the System of Delivery we use to support the cross-functional product development activities at {awesome client name}.

The way I think about UCD (and design in general), there are three primary frames of work:

  1. Understanding the needs of users – understanding what the most important problems are from the point of view of users; organizing market segments into personas, etc.

    This is mostly “off-stage” work which affects the quality of the artifacts which move through the system.  {Awesome client} has typically taken an agency-approach to all of this work – development of personas, primary research.  The system of delivery accounts for including the necessary aspects and insights through the activities, definitions of done, and the training around how to facilitate discussions – primarily with portfolio teams.

  2. Developing design approaches – collaborating to develop the design approaches for how we choose to solve the problems we choose to solve.

    In this case, the System of Delivery explicitly accounts for all of the activities of designing and selecting solution approaches in the solution definition and solution design phases. Design participation is integral to effective cross-functional team collaboration at both the portfolio and product tiers.

  3. Evaluative research – gathering the signals, synthesizing them, and learning from them to enable us to course-correct our approaches as we discover our mistakes.

    In this case, we identified—particularly in the context of the globalization of evaluative research practices and the partnership with in-market product owners—the key learning-opportunity points within the System of Delivery, where targeted research is appropriate.

Further, during epic validation, we have the opportunity for teams to evaluate the success criteria/effectiveness/solution hypotheses of individual epics. This measurement activity for “speeds and feeds” epics is naturally gravitating towards the analytics group, and for “more qualitative” behavioral changes, UCD is the right frame for discovery.

I believe the (centralized) Transformation office has already provided documentation and explanation of the System of Delivery, but may have emphasized different points at that time (there are many!). Hopefully, this additional specificity helps connect the broader context to the UCD frame.

TLDR

Design is deeply integrated throughout the cross-functional and cross-team collaborations articulated in our approach to enterprise business Agility. UCD is the current industry best-practice flavor of design. All the elements of {awesome design leader’s} described UCD process live expressly in each of the areas also described above: 

  1. Understanding needs – (a) empathy (b) define (c) prototype
  2. Designing approaches – (b) define (c) prototype (d) test (e) implement
  3. Evaluative research – (d) test (e) implement

The key difference is that a given objective is not pursued (a) through (e)  in isolation as a functional “design service” providing insights to the teams, but rather all of those elements are appropriately and deeply intertwined into a shared process.  It is within this context we solve for internal/external “agency model” staffing, dedicated stable design members of teams, etc.

Please feel free to reach out with any follow-up questions. Sometimes it is the nuance of specifics that helps people reach a shared understanding, happy to help do that.

This article originally appeared on the LeadingAgile blog