The role and place of UX designers in the company
There is still a raging debate on the web about the role of UX designers, user research, and how much we need to know about the user. On the one hand, UX is viewed as a specialized set of knowledge that provides technical development of projects and sets requirements. On the other hand, UX is the responsibility of the entire organization.
Several concepts are presented below that can facilitate deeper discussion by making meaningful distinctions.
1.UX lies on the border between supply and demand
UX is formed at the boundary between what is technically possible and what is appropriate for the problem at hand. The canonical picture for this boundary is the client / firm relationship. The firm can do a lot of things. The client wants something specific. The firm tries to understand the client as best as possible and do what he wants (create “value” in business jargon).
This border runs at various points within the company. Any border can be viewed from the side offers or from the side demand… Someone knows how to do something (supply), while someone needs something (demand). These two perspectives meet at every link in the value chain.
For example, programmers code something according to certain requirements. Requirements are established in accordance with a certain understanding of the problem. The person who is responsible for understanding the problem looks at it from demand side, and the person who is responsible for finding a solution to this problem looks at it from supply side… Or the same person can do both, alternating their point of view from the demand side to the supply side.
Often when we talk about UX, we assume the view from the end user – the last link in the chain. Knowing which link we are talking about can help the discussion. For example, the user and the customer can be different people. They both need “UX”. To clarify what this means, we can make the border explicit. The supply side parts at the buyer s frontier (marketing, sales, product features) will be different from the parts at the user frontier (learning, interaction flows, internal performance).
The concept of supply-demand frontier allows us to think about how far we will go. Consider a freelancer who is powered by WordPress. WordPress design affects UX from a macro perspective. But from a freelancer s point of view, WordPress is a supply-side constraint, and its job is to adapt its potential to the client s requirements.
2. Modular vs integrated boundaries and UX
The boundary between the two links in the chain can be of different types: either a distant relationship or a closer “let s decide together” relationship. A freelancer using WordPress is an example of the first type. A designer and programmer working together on an interface concept is an example of the latter. Following Clay Christensen s example, we can call the first option “modular” because there is a standardized interface, and the second “integrated” (he calls it “interdependent”).
This distinction describes the organization of people who provide supply to match demand. Some teams are small and actively collaborate. They talk directly to the client and then sit at a table together to come up with a solution. In this case, the boundary between setting requirements and programming integrated…
When a company goes beyond a certain point, the boundary is modular… This means that at the border there is a formal interface (aka handover) with a procedure for transferring information from the demand side to the supply side. An extreme example of this is a relationship where one team creates specifications for a project and another team implements those specifications. Each has its own border. From point of view creator specifications, the demand side is the use case that is expected when the specification is developed, and the capabilities of the technical team are the supply side. From point of view performer specifications, the demand side is the specification itself, and the supply side is their knowledge and toolbox. Both do “UX” in the sense that they want to provide a better experience on the demand side of their frontier. But they don t all sit on that final end-user boundary.
This does not mean that any type of organization is good or bad. Different organizations set different limits. In general, if a problem has been solved a hundred times before, the organization can be modular. On the other hand, if the solution has never been applied before, additional integration between the links in the chain is required. That s why at Basecamp, our designers and developers work closely to develop a completely new feature. For the same reason, Apple had to create a Pencil that integrates with the iPad in order to outperform capacitive styluses.
3. UX dependent and independent of a specific area of expertise
The third difference we can point out is knowledge and skills that improve UX. generally, and knowledge and skills in a specific area.
Area-specific UX means understanding how supply should match demand tailored to the specific situation and use case… For example, imagine that a user of a task management tool walks from their office to the parking lot and suddenly remembers a task for their team. He tries to add a task on his phone before he forgets it, but it takes so many steps to get the file right that it s hard for him to remember the task halfway through the process. This is specific knowledge about a specific issue that affects the UX design of a mobile product.
On the other hand, many aspects of UX do not require situational knowledge. They are based on the general limitations of human perception, memory and cognition, or the ergonomic network of the device and the environment in which it is used. These independent of the field of activity UX elements are also important. They make up most of what was written about in the early days of usability. A concrete example would be using lettering on icons instead of just icons so that users understand their meaning.
This type of UX problem is the topic of books like “Design of familiar things” Don Norman or “Visual presentation of large amounts of information” Edward Tufty. These examples are at the edge of interface design. On the server side, books like “Subject-oriented design” Eric Evans or Refactoring. Improving existing code “ Erich Gamma and Martin Fowler show how to provide better UX to API consumers and editors.
A domain independent UX must permeate the entire organization. This refers to the general skills and knowledge of each link in the chain. This is part of learning how to become a good designer, programmer, marketer, salesperson, and so on. Looking at the company as a whole, domain-independent UX belongs to the supply side.
Domain specific UX is different because for every customer, product, or use case, you bring new costs… If an interaction designer wants to expand his domain knowledge, he must stop developing interfaces and spend some time researching. Then he must analyze the knowledge gained and synthesize it into conclusions that are general enough to create requirements. In terms of the firm as a whole, domain-specific UX refers to demand. It s about understanding what to produce and sell.
Each employee in the firm needs a specific area of expertise, depending on your architecture. A company with modular boundaries between teams will need to acquire this knowledge modularly. In other words, specific people in the organization spend time researching. Their requirements are domain-specific UX.
On the other hand, a company with integrated borders can rotate its schedule. Sometimes researching the client s situation, sometimes developing a suitable solution.
Which approach is appropriate will depend on the size of the company, the complexity of the use case, the complexity of the technology, and other factors.
Hopefully, these concepts will help take the discussion of UX deeper, allow designers and researchers to think more carefully about their place in the organization, and give companies the tools to better allocate responsibility for different types of knowledge and decision making.