Firstly, a definition may be in order. Although I've been working with UX professionals for over a decade (and have generally loved it), I still encounter people who have never had the opportunity to work directly with UX or are from an organization that doesn't have a UX function. In general, UX is a growing field that is responsible for creating the best user experience possible for software. Going well beyond "just" defining the user interface (UI), UX encompasses activities such as defining personas, designing prototypes and executing usability tests. I find the definition here reasonably complete. Even those of us with experience working with UX can be forgiven for sometimes being overwhelmed by the new UX-related roles that have developed over the years (and continue to). You can find an impressive list of roles/titles here.
I get a full body shudder when I think that at the beginning of my career (in the early 90's), I, as a developer, was expected to create UIs for the software I was coding. To my way of thinking, it was akin to asking a mechanic to design a beautiful car. Needless to say, end users suffered the now obvious down side of this arrangement.
Organizational setup is always a tricky topic. Let me start with my usual caveat: any organization structure can work. Organizational structure must be optimized for a variety of factors, including available skills, organizational legacy and even egos. In this post, I'd like to share important considerations for creating an organizational structure that is sustainable, i.e., one that is likely to survive the tribulations of changing priorities and personnel. In my courses, I always begin discussions about software product-related organizations making the distinction between the functional and technical perspectives. Essentially, the functional view is outside-in, the way a customer sees a product. The technical view is related to implementation or how something is built
Based on this distinction, it is clear to me that the vast majority of UX professionals are functional, i.e., they create designs for implementations but do not implement software themselves. In my mind, this means that having UX report to development (an organization with a technical perspective) is a mismatch. I think the best product decisions are made when there is a healthy tension between functional and technical perspectives, each keeping the other in check (within the context of shared goals). Ideally, UX, as a functional discipline, should be separate organizationally from engineering.
Does that mean UX should report to product management? I'm not so sure. In my (big shop) experience, UX professionals reported into a central organization, with a certain number of UX designers having a strong affinity with a product or set of products while the others floated around as needed. For example, experts in designing usability studies would engage with product development teams as necessary.
I've seen this centralized setup work well -- it provides consistency at the product level but is flexible enough to respond to changes in priorities and release schedules. When you consider that many UX organizations also play a role in UX governance (ensuring UI consistency, appropriate branding etc.), a centralized organization makes sense. In contrast to the brainmates post, I have never seen UX reporting directly to product management, although such alignment makes much more sense to me that their reporting to development.
UX reporting relationships can have important implications with respect to a typical source of conflict with product management: product accountability. I believe products are most successful when a single person is accountable end-to-end for their success. I would propose that product management should assume this accountability. However, UX is a well-evolved art and science and is often very highly empowered with respect to UX design (as they should be). This high level of influence begs the question, "When PM and UX disagree on something, e.g., how much investment to make in UI improvements in an upcoming release, who prevails?". While that question merits a blog post in itself, I can tell you that having UX report to a technically-oriented organization does not make resolution of such impasses easier. In cases in which product management is struggling to assume accountability for the direction of the product (as is often the case with product management is introduced), having UX in the development organization can seriously compromise PM authority.
By the way, the statement in the brainmates blog concerning "UX {being) closer to the customer" followed by a reference to "user goals" made me a bit uneasy. In the enterprise space, the term "customer" is almost meaningless. Typically, the people who buy and use the software are different and can have conflicting sets of perceptions and requirements. I plan to write a post about the "mythical" enterprise customer in the coming weeks.
In summary, while I think any organizational setup can work (at least for a while), I believe that the long-term benefit of having functional and technical concerns separated organizationally is a compelling reason to ensure that UX (clearly a functional discipline by my definition) doesn't report directly into engineering. In mature shops, I've seen a centralized, empowered UX organization function reasonably well, although issues like sufficient product knowledge and right-sizing of governance efforts must be closely managed. Finally, UX reporting to product management could make sense, but I simply haven't encountered it in companies I work or consult for. I'm curious if this is a trend in markets outside Europe or if it's simply a matter of chance that I haven't encountered such organizational setups.
What is your experience? Do you have a strong opinion about where UX should report? What is the organizational setup of your UX team? You can find out more about me and my offerings on my site.
This comment has been removed by a blog administrator.
ReplyDelete