What do you mean UX design is horizontal?

There’s an interesting trend in enterprise organizations: folks are starting to refer to user experience design as a “horizontal” function. But what does this mean? While I am not typically a fan of these kinds of buzz words, such nomenclature indicates a critical shift in how our colleagues understand UX.

Within UX, we’ve long understood ourselves to be cross-functional and inter-disciplinary. Our primary function is to have an in-depth understanding of our users, and to translate needs across many teams and disciplines, including product management, engineering, documentation, quality assurance, support, marketing communications, and the list goes on. Referring to design as “horizontal” feels like an expansion of this understanding beyond our internal circles and one that will serve us well as we continue to engage across disciplines and departments.

Moving Further Upstream

Adopting a horizontal approach to design naturally solves a lot of challenges for UX. Most importantly, it allows us to move “further to the left." or further upstream so that UX is leveraged to understand users and analyze their problems well before any specific solution is prescribed. Before we start talking about a graphical user interface (GUI), application program interface (API), educational material, marketing communication, or any interface or asset, we need to start with if and why the user needs anything in the first place; otherwise known as the problem statement. When UX is vertically siloed under engineering or marketing, we typically get involved much later in the design process, after the team has already determined the problem and solution -- assuming they’ve actually identified a problem and are not developing blindly.

However, even though I’ve embraced the notion of horizontal design and celebrated its inter-disciplinary value, I’m left wondering how we scale our limited UX talent to provide coverage across so many organizations. We certainly cannot attend every meeting or be embedded in every org.

Forming a UX Guild

One approach to addressing the challenge of scale is to build a guild of sorts: a matrix of UX professionals embedded in key teams with a dotted line to their embedded teams while still reporting directly into a centralized UX org. The guild structure allows embedded team members to form relationships with product teams and gain a deeper understanding of the solutions they are designing. However, the embedded model also runs the risk of UX members empathizing more with their product teams’ problems and less with the users’. Additionally, by joining specific product teams, UX professionals may risk losing touch with the bigger picture of how their solution fits into the company’s portfolio.

A second approach is flipping the reporting structure so that the embedded pros report directly to their product teams rather than a central UX org. We’ve found, however, that reporting to product teams makes it even more difficult for the embedded UX member to prioritize the users' interests. In order for this model to work, you need a strong centralized research and architecture team operating from a clearly-defined roadmap, working closely with product management far upstream from the product teams.

UX as a Skillset

Taking distributed, horizontal UX a step further, what if we begin to think of UX as a set of skills rather than strictly a profession? In other words, what if product managers minored in UX, software architects employed design-thinking, and engineers were certified in UX methods? Cultivating UX skills across professional roles and titles makes it much easier to scale beyond a single dedicated role. Of course, this approach rests on a couple of assumptions: first, that other professionals will have an interest in becoming more inter-disciplinary; and second, that UX is an easily obtainable skillset (which, let’s be honest, some people should never touch a design tool!). Setting that aside, this would certainly move dedicated-UXers more into the workforce education domain and serve to make us a force multiplier. 

Real-world Example

At Teradata, we are employing a mix of a larger centralized horizontal org along with embedded professionals. We have embedded designers into product teams, where they work closely with product managers and engineers while still reporting directly to a centralized UX org. Within the horizontal org, we also have producers and researchers working closely with embedded team members as well as many other teams — including customer experience pros in customer support as well as the customer success team in sales. The next steps would be to embed a UX writer into the documentation org and a UX producer in the product management org. We are only a few months into this embedded model, and so far we have seen some returns. Our biggest challenge has been getting the centralized team upstream of the product teams. This feels like a natural problem that will resolve itself as we strengthen our role in the unified offering lifecycle and develop our UX roadmap and backlog.

What do you think?

I would love to hear your take on how to make UX a horizontal organization. How do you see UX becoming more cross-functional and being engaged earlier on in the offering lifecycle? Reach out to me on LinkedIn or Twitter with your ideas.