How does UX fit into software development?

There are benefits to both waterfall and agile methodologies. However, when it comes to creating phenomenal user experiences, waterfall cycles tend to come up short and here is why:

The user experience on paper can be VERY different from the user’s experience. There are often things that the researcher or business analyst might suggest that only address the symptom and not the issue, or the initial interaction design fails to address a major use-case, or the visual design detracts from the usability of the product in some way. All of the members of the team across all of the disciplines involved must work together to overcome these obstacles as they arise during the product development. Because, the truth is, you are never going to be able to account for every problem or scenario in the BRD that was written three months ago.

In an earlier post, I identified the different UX disciplines in order to describe the function of a UX Strategist. Those role definitions lent themselves well to being described in a waterfall context (i.e. The researcher hands off to the interaction designer, who then hands off to the visual designer, and they to the developer).  But most software teams are not big enough to have one of each sub-discipline within UX. Often, a business analyst fills the role of a researcher and visual designers are sometimes responsible for interaction design. Regardless of how your team is setup, an effective implementation will rely on those people acting cohesively in a more agile framework. I would encourage you to read Lean UX and attempt to incorporate as many of those principles as you can into your workflow and team design.

We all know that silos happen and we have all seen the damage that comes from work done in a silo. Everyone has defined roles and we tend to build fences around those roles. This is MY responsibility and when I’m done, then YOU can contribute your piece. But this mindset is hardly conducive to meeting user needs and creating an intuitive, value-adding experience. Thus, we must eliminate the silo, and in some cases role delineations, in order to make decisions together, leveraging everyone’s skills and abilities over their traditional “role” on paper. But removing silos is not easy and it poses it’s own challenges… if your entire team is one large group of internal stakeholders that all get an equal say in the decision-making, you are going to end up with a Ultra Super EZ ToastMaster 9000 Special Limited Signature Pro Edition Plus. Someone needs to have the authority to make the final say, in order to avoid designing by committee. That does not mean, however, that they should ever retreat back into their silos to make those decisions without input from the rest of the team. There is a balance to be struck here.

For example…
Let’s say you have a small team: 1 business analyst, 1 interaction designer, 1 visual designer, and 1 developer. Everyone should work together in adversarial collaboration to arrive at the best answer for each problem the team faces. When there are disagreements, cases should be stated, but without attacking the person behind the opposing idea. It is easy to be dismissive of anything that originates from someone you don’t like or don’t have a great working relationship with; there are a host of cognitive biases and logical fallacies that contribute to this. The goal should always be to seek out data (ideally from your users) that supports the right decision. Getting actionable user data isn’t always feasible and sometimes someone just needs to be authorized to make the decision.

In the past, I’ve seen this authority split between roles. For example, the Interaction Designer has final say on anything that impacts the behavior or the experience (like degrees of contrast for action buttons in order to guide the user flow), but the visual designer has final say over colors, button styles, and other visual elements. It’s important that everyone on the team support the authorization of these individuals to have the final say so that the  team is not constantly arguing over changes to subjective, and sometimes immaterial, elements of the product design.

How does UX fit into software development?

UX is about designing for the human element of an experience and that applies to physical processes as much as it does to digital products. The process of software development is a “product” and has users (i.e. the development team). We should be designing that product around the needs of the team and organization.

Increasingly, UX is software development and the development methodology needs to begin to take shape around solid UX principles as opposed to trying to squeeze UX into archaic methodologies that originated during the DOTcom boom.