When asking a user experience designer at a conference or meetup where they sit in the org-chart of their companies you get an interesting variety of different answers. Some report to be part of their marketing organization, others are the (unsung) heroes of software development. Some teams are organized as independent internal agencies while others are spread out and sit distributed with the agile teams they work with. Team sizes vary massively too, I have seen everything from several hundredths to the well know “UX team of one”.

With this apparent diversity, is there one good way to position and organize UX design in an organization, or is it all relative on industry, maturity, size, type of products, etc.? Let’s assume you come in fresh and start from zero and introduce UX design as a new discipline, are their best practices to get started? Where to hire and position the first designer(s), in marketing, in development, as an independent team, or doesn’t it even matter? And which approach and structure ensures that UX design scales seamlessly and continues to deliver consistent high quality design output when the organization flourishes and growths itself? I continuously asked myself those questions with the last companies I worked for,  all large B2B technology vendors, so I will explain my own “mental model” for positioning and growing UX design based on the experiences I gained there.

At the time I joined my last company, it was relatively immature and inexperienced with UX design and were just convinced enough to give this “UX thing” a try. The leadership felt the pressure to do “something” as customer feedback continuously pointed to “usability” as an issue. The look and feel of the products were just not as modern as the latest iPhone experience, and worse than that, the competition received better feedback and ratings for their UX. Something needed to change. The initial approach and scope for this problem was set to the visual attractiveness or “lovability” of the “output” the development organization was shipping, what else is there to do right? That’s where I came in.

I joined an agile SCRUM team and added UX design as another discipline to the cross-functional mix, next to development, cloud operations, Q&A, and technical writing. To get up to speed I joined all SCRUM ceremonies available (daily standups, planning meetings, backlog grooming, retrospectives, etc.) and tried to learn as much as possible about the business domain, user personas, workflows and tasks, as well as technical requirements and constraints.

The clear and articulated need the team had for UX was “providing visual designs for all user stories” the team was committing to in their sprint planning meetings. “Don’t make it too complicated with user research and all that”. So, for a start I did exactly that. Working closely with the product owner and UI developers, delivering UI designs based on industry best practices, design principles, and usability heuristics. It was a good way to become part of the team, deliver some tangible value, and earn the trust of even the skeptical developers. So the first step was done, this UX thing was perceived as a useful addition to the agile software development practice.

I think it’s fair to generalize and say that development teams do not leave the building very often (figuratively speaking), so their focus is very inside-out. They develop, test, ship and run code, working off of a product backlog that is managed and prioritized by product management. So even though they aim to continuously optimize their teams’ performance, they usually work based on set and unquestioned requirements from outside the team. Even though I now managed to become an integral part of a SCRUM team, UX design does not work this inside-out way, so I kept approaching other stakeholders to get out of the building and in front of customers.

Persistence and stubbornness helped me to get some contacts at customer organizations with whom I set up some interviews. This initial qualitative research provided me with the required context and user empathy to have more educated and informed discussions with the product owner and the team. Questions such as “how to solve a specific customer problem” now were not entirely opinion based anymore. I could use customer examples and quotes to frame the discussion much better and in this way educated the team too. It also helped in the endless negotiations and reprioritizing with developers when we had to scope down a design. From this point on I made customer contact and user research a regular activity.

The agile team, UX design included, was still working from a backlog of business epics and a roadmap that was created, maintained, and prioritized by product management. But with the direct link to customers and the ability to run tests and research studies, we were sufficiently equipped to design and develop code that was usable and lovable by our end users. We were fully focused on finding the best solution for a given problem.

For UX design this involved sketching ideas, creating wireframes and user flows, building interactive prototypes, as well as detailed visual screen and UI control design. After initial fricition, we agreed that UX would at least work one sprint ahead to prepare and validate designs for stories for the next sprint.

That means that in relatively little time, UX has to ideate, create, and iterate as many different design solutions as possible for a user story. Then validate which one is the best for the user (e.g. through usability testing), verify which one is the most feasible to build with development (e.g. in mid-sprint backlog grooming meetings), and throughout all that negotiate a viable compromise with product owners or product management. This is the application of the diverge/converge design thinking model as introduced earlier to the iterative nature of agile software development and I think it works really well.

Integrating UX into an agile development team takes a few months to set up and then it runs fairly effectively. As a UX designer on several of such teams myself, I quickly learned a lot about and the products, the related technology (including its limitations), but most of all about the users and their business domain. When you perform qualitative research, especially contextual enquiries or user interviews, you learn a lot about their business, workflows, processes, communication, collaboration, other tools they use, and all the problems and difficulties they experience. And that is when UX usually starts to swim “upstream” and begins to questions and discuss the problems they are being assigned to by product management.

The focus shifts from “Build the thing right” towards “Building the right thing” and with that asking “Are we solving the right problem?”. This is where UX extends its focus, contribution and impact from product development towards product management and product strategy. Not just working on the optimal execution of a product release from a backlog, but defining the themes for the next release and with that providing input into the definition of the product roadmap and backlog itself.

On this product strategy level, UX is primarily working with Product Management, Product Marketing, and (Enterprise) Architects. The focus is usually set on preparing the Epics and roadmap for the next product release(s). This is done using the same diverge/converge design thinking mindset as in product development, but applying different tools and methods. The starting point is usually customer and market research which results in a variety of data and insights about problems, trends, and opportunities in the marketplace.

When I got the chance to join product management for regular customer visits, I developed a much deeper understanding of our customers’ current problems, their mid-term plans and tactics, and their long-term strategies. The discussion I had as a result changed from usability and lovability of a product user interface towards the value of the product provides (or not) as a whole. Does it support the customers’ business processes and growth ambitions? If not, what is missing? Such questions can easily be addressed by user and customer research methods. The resulting data and insights can be transformed into design concepts and early conceptual prototypes, using design thinking and service design methods. Those prototypes can then be validated and discussed with customers again, which provides evidence and confidence for product management for backlog prioritization.

Let’s give an example: I was the UX designer for a large-scale web content management system, fully focused on designing new features as defined and prioritized by product management. The scope was fixed to extending and improving the existing user interface. The product was traditionally sold to IT departments in large scale Enterprise organizations which implemented it and then provided it as an internal service to their business and marketing. If marketing teams needed anything differently than initially planned in a “requirements gathering workshop” (never happens, right?), it had to be requested with IT.

Well, requesting changes with corporate IT is often bureaucratic and slow and caused a lot of friction with a new and emerging class of data-driven digital marketing teams, which demanded full flexibility over their tools and processes to be able respond to customer needs and changes in the market as quickly as possible. As a consequence, we observed a shift in the way large organizations run their marketing operations and we saw budgets moving from IT directly towards marketing and the CMO.

Now my company as a technology vendor started talking directly to the marketing group which, opposed to IT, had very different expectations and requirements. This situation required a different approach and opened the door for me to involve myself into the product strategy discussion, hoping to demonstrate how UX can bring significant value into defining product strategy. Together with the product manager we run an extended research study with the focus on digital marketing teams. We run a customer roadshow at which we visited customers from different industries across Europe and the US and interviewed their marketing teams. We learned about their processes, goals, KPI’s, the roles and competences they had on the team, the products they were using next to ours, and understood much better what they were expecting and where they were heading themselves. This allowed us to run internal design and prototyping sessions that resulted into a clickable prototype of an entirely new user interface. This prototype we then took back to all those customers and validated it with them in discussions and basic usability testing with end users. The outcome was a solid understanding of the problems and expectations of this new customer type and a validated design prototype of a concrete solution.

From here it was relatively straight-forward to analyze the design prototype with the development teams and estimate the actual development costs. PM broke it down into epics and features, so there was no difference to the execution process. Also all details had to be discussed and designed sprint by sprint, so there was still a lot work to do. But overall it was a great and successful demonstration how UX methods can support and drive the product strategy process, outside the scope of any agile development team. Following this example, we started adding a new layer of senior UX strategist to all our product lines to ensure that Product Management has a strong and reliable partner when defining product roadmaps and backlogs that resulted not only into usable and lovable user interfaces, but also ensure that products solved the right problems and for that reason were valuable to their intended customer segments.

In summary

Regardless of the shape, size, and structure of your organization – in my opinion it is best to begin building a strong UX discipline on the product development level to ensure that any given input from product management will result into the best design solution possible. This works best in an embedded way, so UX designers should be part of one or a few agile teams. If they supporting multiple teams then it’s essential to select teams that work on products serving the same business domain, otherwise the stretch becomes too large and compromises design quality. Ones this is set up and UX design is an integral and effective part of your development pipeline, move UX design upstream and pair senior UX designers or UX strategists with product managers to prepare product roadmaps and backlogs. Both areas follow the diverge/converge design thinking mindset and combined resemble what became known as the double diamond model. This is a very effective model and I used it to embed UX into product strategy and product development, scaling over several separate product lines in different business domains.

Both areas follow the diverge/converge design thinking mindset and combined resemble what became known as the double diamond model. This is a very effective model and I used it to embed UX into product strategy and product development, scaling over several separate product lines in different business domains.