Published on | Prototyping: From UX to Front End — Medium Tony Smith Found on Pexels.com

As a UX Manager, I’m constantly looking for ways to make our process more efficient, effective and enjoyable. The good thing is there’s no one-size-fits-all process. But that also makes it hard to define for your particular situation. With that in mind, the our team at eharmony has made recent changes that can help inform the direction you take.

Pain Points

Competing Objectives

The main problem we encountered was aligning the design process with development cycles. Often the two have different objectives, timelines, and deliverables. The design team is trying to think beyond obvious solutions to give the business a competitive advantage. This requires timeframes that are hard to estimate. And, the output is sometimes more useful for further investigation or user testing than for production.

Engineers, on the other hand, have sprint commitments that need clear product requirements. Detailed specs improve the reliability of time estimates. For companies that feel the pressure to release code every sprint, the roadmap favors production work while neglecting innovation methods.

Dev Tools For a UX Process

Task management platforms, like JIRA, are used to track the effort and velocity of development work. Dev tickets are not the best place to include design concepts, user testing results or other UX output. They distract from the information needed to simply code and test a feature. Sprint planning meetings and tech sessions are also bad places to capture UX tasks.

So where does UX work fit in? How do we bring these distinct processes of design and development into alignment? Here are few options…

Options

Add UX tasks into dev tickets

One suggestion is to integrate UX work directly into sprint tickets. The goal is to account for these tasks and reflect the dependencies of dev tickets on design output (specs, prototypes, etc.). Developers have more visibility into the UX process and everyone is speaking the same language.

Issues

UX work can effect multiple sprint teams
Scope of UX tickets are different from dev work
UX documentation can distract from information needed for production
Introduces new complexities for estimating and tracking work across multiple functions

Completely separate tracking of UX work

Another solution is to remove UX from the sprint process altogether. Allow flexibility to find processes that work for your team and the particular project. Staying a few sprints ahead should allow for the unpredictable nature of ideation.

Issues

Design teams using different metrics to track work requires a translation to dev metrics in order to align schedules and output
Increased likelihood of missed timelines when dev cycles are not followed
Potentially disconnects design from dev teams

Use common tracking system in parallel

The system we found to be most effective is to embrace the same task management system as tech teams (in our case JIRA). We work in sprints, estimate story points, and track velocity in the same way. However our tickets live on a dedicated UX sprint board. We define our own sprint stages that reflect our process (i.e. investigation, design, review, production, done). We also attach UX documentation to tickets without cluttering dev tickets. This is a useful way to reference concepts, rationale and key events in context.

Benefits

Tracking and planning

visibility into effort, velocity and capacity allow for accurate sprint planning and resource allocation
limits of capacity force prioritization and alignment
tracking allows for diagnosis and optimization of the process
UX tickets can have different requirements than dev tickets

Documentation of UX deliverables

attaching concepts, rationale, research results, etc. doesn’t interfere with production information
content can be searched and referenced across teams within same system

Provides transparency to entire organization

all teams can view UX sprint board to see what features are on the way
allows time for feedback, adjustments and alignment before dev sprint starts
gives marketing, acquisition, and customer care lead time to support features/releases

Recommendations

Use same scoring format so product managers, developers, and designers are using common language (i.e. fibonacci sequence)
Just like dev teams, designers score tickets together and justify outliers to arrive at a more objective estimate
Allow designers to recommend the scope and structure of tickets. They know how they will approach the project, which tasks will be clustered and which are too big to complete within a sprint
Hold separate retrospectives with design, product management and tech leads to discuss previous sprint and optimize the next one

Our projects typically run 1–2 sprints ahead of dev. We balance our sprints between smaller production tasks and larger ideation sessions. The production tasks keep a steady flow of deliverables going into development. But, these tickets don’t keep engineers busy for long. That’s why ideation is so critical. It produces a larger volume of projects and maintains focus on the strategic goals of the business.

Photo by rawpixel.com on Unsplash

We found success by joining the Agile process rather than fighting it. That means tracking our process like tech teams. It brought us into the conversation about priority, scheduling and capacity. These topics used to be fuzzy assumptions that were hard to track. Now we have the tools to optimize our process and deliver high-value solutions.

Thoughts?

What do you think about tracking design like a developer?
How do you track your UX process?

How to make UX and Agile work better together was originally published in prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to make UX and Agile work better together

Cool stuff, every week

More Articles