At Liberty I was tasked with building a product design team to be integrated into newly established agile squads. While there was a desire to have UX/design as part of the development process, product owners and developers had never worked with product designers before nor understood what design could do for development.

Why this matters

Properly integrating UX process into development is critical to a team’s success. Done well, a squad can build impactful experiences that deliver real business value. Done poorly, a squad will struggle to move quickly, find themselves unable to tackle big challenges, and see team morale fall.

The Challenge

Squads were unintentionally operating in a waterfall framework at Liberty Mutual. A designer was tasked with designing a particular page in one two week sprint. Developers would pick up that work the following sprint. Often the design work would go longer than a sprint - new feedback needed to be incorporated, designs needed approval, design needed to change based on amended requirements.This would push out development. And while taking longer, it was harder to pivot a design or push for bigger changes.

The reality is that design should be able to move faster than development. A designer should be able to design a straightforward landing page faster than it takes a developer to build it. When I point this out, in struggling organizations I often get a response of something like, “that’s not true.”

But it should be.

A two week cadence (typical sprint timeframe) is awkward for design. The work doesn’t fit neatly into that box. And honestly, if you give a designer two weeks to design the afore mentioned landing page, he or she will take two weeks to design it. But the reality is it shouldn’t take nearly that long. This is part of the challenge of tackling design within a sprint.

The Solution

In bringing UX into the Agile framework, I ask teams to consider design work to be more a part of the “definition of ready” rather than “sprint work.” In this way, UX is responsible for providing enough runway for developers to keep churning out work.

This also allows for the fact that design is a non-linear process. Good design encompasses many parts (research, exploration, sketching, ideation, pixel-perfect design) that are pursued in different order based on the work, sometimes returned to, sometimes done in parallel. It is not readily broken down into base steps and ordered (to be sure, good design process is repeatable knowable; it’s just different than coding).

I refer to this approach as UX Kanban. UX will take on work, complete it, and move on to the next item as quickly and efficiently as possible.

I outline four key parts to the process:

1. UX write their own UX stories. This is important so that UX has a sense of ownership of the work to be done, and the direction it will take. And by writing their own stories for JIRA, they are accountable to their squad and provide a level of transparency. Additionally, this helps designers “speak” the language of POs and developers.

2. POs own prioritization. Even if we’re taking our work “outside the sprint” it’s still important that the team is moving in the same direction. Product owners are responsible for prioritization. This is still the case.

3. Transparency with the entire squad. I believe strongly that clear communication and shared understanding is the most important piece of Agile, more so than any specific ceremony or practice. UX can’t go off to do their thing in a vacuum; the squad should always be aware and able to see what designers are working on.

4. UX is a part of Definition of Ready. The UX work is not tied to a two week cadence; it happens outside of it. Kanban provides a framework for tracking the work and making it visible for reporting, etc. For developers to pick up work, UX needs to be far enough along* that work can reasonably be picked up and completed.

* I don’t believe design needs to be pixel-perfect finished for developers to pick up the work. There’s some nuance here, and it again relies on transparency and the culture of trust established among squad members.

Critically, there is UX work to be done “in sprint.” While the bulk of exploration, research, and design is completed “out of sprint,” designers have a role in sprint as well. They are expected to support developers as they pick up the work. Designers sit with developers as needed, explain intended behaviors, and adjust assets when needed. This ensures work is properly supported from conception through deployment.

To implement these changes to process, I worked with product owners and developers, listening to their concerns and thoughts, and walking them through my approach. I spoke at numerous town halls and quarterly planning events. I worked diligently to bring the organization along with this change.

The Result

Squads took to the new approach. All UX stories were tagged appropriately so they could be pulled into a JIRA Kanban board for UX to review. Monday mornings I hold a UX Standup for the week where we review stories in progress. I also meet with POs bi-weekly to review the UX backlog. This ensures that work is getting done and squads are moving quickly (UX is not holding things up). An added benefit is with our ability to visualize UX work across streams, I am able to shift resources as needed to help when needs arise.

By going to UX Kanban, we were able to move much more quickly and effectively. We successfully redesigned the Liberty homepage in this fashion, and with the flexibility to adjust our designs as we conducted iterative user testing.

Ultimately we went to our UX Kanban model and never looked back. POs feel they better insight into what is going on from a design perspective. UX feels they have the freedom to do what is needed and can pivot when appropriate. Engineering across our group has a robust runway of work to take up. And more importantly, they have visibility into work in progress and can share perspective in flight, which ensures UX-developer hand-offs go smoothly and is more on-going rather than a specific moment in time.