Even early in my career as a business analyst, before I received any formal training in user experience design, I was deeply passionate about user experience and considered it part of my job. I spent significant time shadowing users while understanding their needs, and in modeling all the information I gathered into something that could help developers understand what the usability of software meant for the customer. Information Architecture came naturally to me and the prototypes I created often generated some great opportunities for collaboration between users and developers. As I started to understand UX more as a formal discipline, I was excited about its potential to further help me understand the customer. But, as I started working with UX professionals more and more, I found many of them to be stylishly aloof and demanding an exclusive jurisdiction over user experience design. I did not let this affect me because I was just excited about the possibilities of what I could do when I had designers work with me.
What I was missing though was the impact of this culture of exclusivity on the development teams and the IT organization as a whole. I’ve often seen proxy wars being fought over user interface design that I suspect was more a resistance towards this socially restricted patronage of UX skills. When I first read books like “The inmates are running the asylum”, I was so excited, it made me feel like I was part of a movement that would change the world! I admire Alan Cooper for what he has done for user experience but, I do feel that he could have taken a less intransigent approach than he did in the book. Even if we argued that the compelling argument he makes about the development community’s apathy to user experience was necessary and relevant to create the movement that it did at the time, it’s time to stop towing that line.
Jeff Patton, who has been an inspiration to me once told me this in the context of UX roles: “Named roles are a mechanism for defining a process. I believe all discussion that focuses on named roles as a starting point, as opposed to skills, start with a traditional process in mind. If we can bust down to the skills it takes to build a software product, then build back up to process that allows lots of people who collectively have the skills to work together, then we have something. I don’t know what an ideal process would look like. But, I do spend lots of time trying to tear down assumptions about roles and responsibilities (characteristics of process), and move focus to skills.”
If more of us can focus on making user experience second nature to software development teams rather than force it as a role or a process, I am optimistic that the “UX + Agile challenge” would become a no-brainer to solve.