In September 2021, I blogged about defining a user-centred design process, adopted at the start of the project to build the platform to succeed EdWeb. As work continues towards resuming migrations to the new platform, it was timely to reflect on the process and consider how it has changed.

What is the UXD process and why did we need it?

In short, the process focused on ensuring development of the new Web Publishing Platform (WPP) was user-centred. It set out to make sure features and functionality built in to the platform aligned with the needs of those who use it – including the web publishing community and people visiting our websites looking for content to support their tasks.

Read more about the process in the blog post:

Defining the UXD process to support a user-centred web publishing platform

When the process was defined, we were at sprint 6 of the WPP project and I was still finding my feet as a UX practitioner on the team. As we head towards sprint 35, I’ve learned much more about the practicalities of making UX and Agile work together. Although Agile and UX share the same user-centred goal – the Agile manifesto states ‘the highest priority is to satisfy the customer’ – it can be difficult to align them. I’ve read extensively on the topic (see sources below) and have tried to put what I’ve learned into practice in my day-to-day work implementing UX within our chosen Agile methodology, Scrum.

Reflections (and confessions) from a Scrum-team UXer

There is no shortage of Agile+UX approaches, processes and procedures but although these seem straightforward in theory, how successful they are in practice depends on the culture and conditions you’re working in. Some tweaks can be made to make processes work, but other factors, like team structures, decision-making lines-of-command and accepted cultural norms are harder to change quickly. Compared to many IT and technical functions, UX is a new discipline, and since it requires a different mindset it’s unsurprising that it doesn’t always neatly slot into technology teams’ established ways of working. Over the past few years experimenting with the UXD process I’ve learned compromises are necessary to ensure UX is integrated within the team, and at times, I’ve cast aside aspirations of being a UX purist in favour of UX having impact and adding value where it matters most. Going forward, as the project continues, I’m aspiring to ensure UX continues to have a place in the WPP team to ensure we don’t lose sight of who we are building the new platform for.

Here are some of the things I have learned, and the ways we’ve flexed our process to make user-centred design work in the context of the project.

Separate tracks for UX discovery and development delivery can work well – but feedback is pivotal

In the initial UXD process we set out to ensure user focus with a dual-track model, with a discovery strand of work (aimed at identifying user needs) occurring slightly ahead of a delivery strand (aimed at developing software to meet these needs). Given the user needs of a web publishing platform are many, varied, complicated and often intertwined, it was appealing to enact discovery in the ‘Big Design Up Front’ method – where all the UX research is done ahead, with a view to handing this over to development for delivery.

Diagram depicting the dual-track Agile process, adapted a diagram by Jeff Patton (source below)

Adopting this approach at the start of the project had some benefits – it meant the UX team could gain a full knowledge of the bigger picture, taking an overview of user requirements including their interdependencies, to shape the vision of what ‘building the right product’ looked like. For some pieces of work we accumulated a body of UX research and did a hand-over from UX to development in the form of ‘list of requirements’ listed on tickets in our chosen project management tool, Jira. As the project progressed, we realised that this approach, synonymous with the anti-Agile ‘waterfall’ method ran the risk of ‘building the thing wrong’ when it came to delivery. Requirements could be misinterpreted and if the UX research had not gone far enough, it left developers with a dilemma of how to proceed.

Through practice, we learned that, although not always feasible due to resource, UX input at delivery, for example, involving UX team members in the completion of User Acceptance Test documentation, opened the opportunity to check if the original research was still valid, to reaffirm the user story at the heart of the work, and to establish if further questions had arisen once the full-extent of the technical capabilities was known. We realised the importance of defining and establishing feedback mechanisms between the discovery and delivery strands to ensure a two-way knowledge-sharing process, to avoid dual track Agile becoming ‘duel track’ Agile (to borrow a phrase from Jeff Patton – source listed below).

Reconciling UX research is difficult when the focus is on features not tasks

To plan delivery and keep it on schedule the Scrum method uses several complementary tools – the Product roadmap (the longer-term view – details of all the pieces of work to be delivered mapped in order against the defined product goals), the Product backlog (medium-term view – list of all defined pieces of work to be delivered in forthcoming sprints) and the Scrum backlog (short-term view – list of tasks to be completed or increments for the current sprint). As UX lead on the WPP project, I set out to keep sight of all three artefacts with a view to planning in advance and directing UX efforts to areas with greatest potential impact and value.

I repeatedly found, however, that I felt unprepared to answer questions about development of specific features despite having knowledge of user needs and tasks. For example, I’d have a sound understanding of how web publishers create pages but this wouldn’t help me advise on specific configuration of a part of the editorial interface. I felt my proactive research was falling short as I often needed to do UX research to answer questions about specific features in the midst of a sprint. I gradually realised that this mismatch was natural and that it comes from UX and development having different units of focus. While Scrum advises breaking down work down into manageable chunks, this can be interpreted differently. In product delivery the smallest chunk is often a piece of functionality – for example a reusable content component – but in product discovery or UX research, the smallest unit is likely to be a task a user wants to achieve, for example: scheduling content publication.

Over time I accumulated a greater holistic knowledge of user tasks and an increased awareness of the features available to support these. I invested time learning about Drupal and its capabilities to aid conversations with the development team. This enabled me to become better at making connections between specific features and user needs, and meant I could pull on the relevant research when questioned, to help guide decisions.

It’s important to have sight of UX work in the team alongside other work

Within the dual track approach, discovery activities happen at the same time as delivery tasks, and there are decisions to make about the best way to represent and document this work. A single backlog with all the tasks is one option, another is a single backlog with UX tasks as a separate stream, or a separate, UX-focussed backlog is another alternative. Within the WPP project we experimented with different approaches and concluded that a single backlog with all tasks was the better option.

At the start of the project the backlog was huge – there were many pieces of work to complete and we were uncertain (and at times overly optimistic) about what could be completed in the course of a sprint. We began a separate backlog to log work cascading from UX research  but quickly realised that, as a team, we were unable to keep track of two backlogs, we ended up duplicating items on both backlogs and missing dependencies between tasks listed on each. Over time, and following the departure of our agency partner TPX Impact, we have learned that a single well-groomed backlog works best to keep visibility of both the tasks that feed into the sprint goal as well as the user needs and research underpinning the subsequent work coming up. This visibility also helped encourage feedback loops between discovery and delivery in the form of questions and conversations between different team members.

There’s not enough time to research everything – project timescales dictate what’s feasible

Scrum is a method designed for product development, therefore it requires some adjustment and compromise to apply in a project context. Within the WPP project, the need to migrate EdWeb sites from Drupal 7 before it reaches its end of life, has meant it has been necessary to make choices based on technical capabilities and heuristics – it hasn’t been an option to carry out research with representative users to guide every decision. There have been times when technical infrastructure work has been necessary as part of the main platform build, without a requirement for UX input.

Part of my UX role within the WPP Scrum team has been to decide where to direct UX research efforts, and to judge when research will do little more than affirm what is already known and widely accepted. Sometimes the team look for research with representative users to answer questions and give direction, and where it is not feasible to acquire this it is necessary to inform them about relevant heuristics and accepted good practices to ensure this information can be used to make user-centred decisions as swiftly as possible to guide development.

In some instances, re-creating current functionality, using EdWeb to inform the ‘definition of done’ has been the right course of action to avoid unnecessary delays caused by ‘re-inventing the wheel’.

UXers play different Scrum roles – developers, subject-matter experts and stakeholders

Well-documented Scrum roles include the Product Owner, Scrum Master and Developers. Scrum doesn’t define a specific UX role, meaning it is up to the team to decide whether UXers are classed as developers – working on increments contributing to sprint goals – or advisors – called upon to direct and inform the roadmap and backlogs – or evaluators – brought in to review progress against plans. In the  WPP project I’ve learned that UXers can add value in all three realms and provide input in all associated meetings – from the daily scrums to sprint planning meetings and backlog refinements (or progress reviews).

UXers can help guide decision-making by the Product Owner and Scrum Master towards a user-centred directive but restricting UXers to this specialist role runs the risk of the waterfall ‘Big Design Upfront’ model. UX work, like development work, can be broken down into smaller incremental tasks which directly map to sprint goals, therefore classifiying UXers as developers (in the Scrum sense of the term) has multiple benefits – it gives the whole team visibility of UX, makes UX accountable for reporting on progress and highlighting problems and presents more opportunities for cross-discipline conversations and shared understanding within the team.

Some reading about UX and Agile

The WPP project doesn’t stand still and as it continues to progress it’s healthy to continue reviewing and iterating our UXD process, and trying new ways to make UX and Agile work together. There is a wealth of knowledge in the literature to draw upon to guide the way we work. Here are some of the sources I’ve found helpful so far on my pathway to implement UX within Agile for the WPP project.

Websites

Manifesto for Agile Software Development

Scrum.org

Blog posts

Here is how UX Design Integrates with Agile and Scrum by Jeff Gothelf (Medium)

5 Rules for Integrating UX with Agile and Scrum by Jeff Gothelf (Medium)

Dual Track Development is not Duel Track by Jeff Patton (Jeff Patton & Associates)

The best way to do Dual Track Agile by Alex Ballarin (UX Collective)

Where do we put the UX tasks? by John Cutler (Medium)

Agile Design Rituals: 7 Essential Meetings by Peter Berrecloth (Medium)

Integrating UX into the Product Backlog by Jon Innes (Boxes and Arrows)

Agile UX: How to Incorporate UX and Product Design Into Agile by Debbie Levitt (Toptal)

Books

The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity, 2004 (2nd Edition) by Alan Cooper (Sams Publishing)

Product Management for UX People by Christian Crumlish, 2022 (Rosenfeld Media)