UX as Disruption: Managing Team Conflict as a Productive Resource

Ux As Disruption: Managing Team Conflict As A Productive Resource

Another daily stand up meeting, another argument between the software engineer and the user experience designer. The project manager is ready to throw up her hands. The team is working towards the same end goal: to release a great piece of software. However, it feels like every conversation turns into a battle.

• UX Designer: Based on our research, the user, who is represented by the persona “Tom,” needs a way to save his work and continue later.

• Software Engineer: Really? If it was me, I’d just do it in one sitting. This would mean we have to add a log in system and manage different roles and access levels. It’s a whole new feature. Adding that at this point in time is going to require a bunch of rework.

• UX Designer: When we observed people like Tom in the field, we could see that interruptions are part of their workflow. If Tom can’t save his work that means he might lose a lot of time re-entering the same information. It’s frustrating for him.

• Software Engineer: I’m still not convinced that you can say that’s necessary. First of all, people have gotten used to how it works. And how can you say this based on talking with what, 8 people? What about the business team? They have never mentioned a save feature. It’s nowhere in the requirements. And again, it feels really late to be adding an entirely new feature.

• UX Designer: Well, that might be because this is the first time we’re actually looked at how people use our current system.

• Software Engineer: It seems like if the users needed that feature – we would have heard about it before now. I’m just not convinced.

• Project Manager: OK, let’s see if we can figure out a compromise that doesn’t set us back on the schedule.

This scenario may be familiar to professionals who have worked on software projects, especially in organizations where user experience (UX) practices are new. Projects can be disrupted for a myriad of reasons including the introduction of new processes, personality conflicts, and poor project management. However, we argue that the introduction of UX processes and the resulting tensions that occur signal something other than idiosyncratic project strife. In this article, we argue that introducing UX can disrupt existing processes within technical teams due to a clash of worldviews between UX practitioners and software engineers. Understanding the root cause of this clash and skillfully managing the resulting disruption can be a productive strategy for organizations.