DevUX – the development of a common language

In collaborations between development and design, two disciplines of different perspectives collide. UI/UX expert Sina Busch and software developer Dr. Axel Habermaier, demonstrate how a common language can be found with the aid of the DevUX mindset, and report on their experiences of practical implementation.

Against the background of increasing complexity of modern frontends, new technologies and frameworks are constantly emerging, which also raise the expectations of and requirements on, UI/UX. The intense collaboration between developers and designers thereby takes on increasing importance. Despite that, many are still working according to outdated principles: the product defines function, designers create concepts and developers integrate them. Lack of communication and interaction quickly leads to silo mentalities, blockages caused by dependencies, misunderstandings and thereby to frustration for all involved. Furthermore, the two disciplines take hugely different perspectives, represented by the following sample cliches:


“Everything must be pixel perfect. I don’t care how it is implemented, that is up to the developers.”


“The main thing is that the application is functional. We don’t have to go the extra mile to polish it.”

Although certainly not quite as cliched and exaggerated as expressed above, this problem of different perspectives is often encountered in practice. Silo mentalities emerge, especially when the development and design teams barely interact and may even be working in different locations.

To avoid silo mentalities and to limit the distance between the two disciplines, we at XITASO have already worked for several years in interdisciplinary, cross functional teams in which developers, UI/UX experts, product owner and agile coaches are represented. And it is not merely physical closeness which is important. The differing mindsets and perspectives of the disciplines cannot simply be eliminated by short distances, physical proximities and intense communication, although they help. Since we at XITASO are always striving to continuously improve, we were looking for ways to optimize our cooperation even further and came across the DevUX concept.

The DevUX concept

The DevUX concept describes a culture of collaboration between designers and developers. It provides a set of ideas and procedures that allow different roles to work together as a team, improving collaboration and thus accelerating development. As a team, you can reach four different levels of collaboration with this concept:

  • Level 0: Dysfunction
  • Level 1: Basics
  • Level 2: Efficency  This is where we are.
  • Level 3: Symbiosis  This is where we want to go!

At level 0 there is no common language used between designers and developers. Both teams work separately and at cross purposes, because communication is missing. The designers do the mockup, the developers integrate it and there is no interaction which quickly leads to misunderstandings, blockages and frustration. With increasing interaction and integration of the different roles into individual areas, you reach higher levels of DevUX collaboration. Level 3 then describes the full symbiosis.

At Level 3, the team designs and develops hand in hand; this applies to most of the entire workflow. A developer is even involved in the mockup creation, which is normally exclusively a designer’s responsibility. And of course, one or more designers will be involved in the development process.

DevUX in practice

With our interdisciplinary, cross-functional teams and our focus on close cooperation, constant exchange and transparency, we at XITASO placed ourselves at DevUX level 2. The step to symbiosis at level 3 appeared to us to be a baby step. In practice, however, it turned out that the collaboration did not yet feel 100% symbiotic for us and that design and development were still not speaking the same language entirely, which meant that we still had a lot of clarification requirements. While searching for the reasons why, we came across an idea from Brad Frost 2 according to which the front end breaks down into two parts:

Front of the Frontend


  • HTML, CSS, Design, Interaction, Patterns, Accessibility,
    Animation, Semantic Markup …


Back of the Frontend


  • JavaScript, TypeScript, React, Angular, State Management, Functional Programming, Asynchronität, MVC, Build Tools, Architecture …

The front of the frontend and the back of the frontend are assigned completely different skill sets and there appears to be a chasm between them. Brad Frost sees consumable UI components as a bridge between the two sides. For example, there are libraries such as Material-UI for React that package front of the frontend concerns into consumable UI components that are easy to use in the back of the frontend.

How does this knowledge help us on the way to Level 3 DevUX? We purchased the Sketch Library for Material UI and the designers now use it as a basis. Components and wording are now almost identical to the components and wording in the code, which has brought us a whole lot closer to a common language between design and development. All at once, we had significantly fewer queries in the backlog refinement, as the vocabulary used was understandable to both sides. In the joint design and development activities of designers and developers, it also became noticeably easier to exchange ideas and to come to a common understanding.

Of course, we do not use Material UI in every project, and furthermore we do not always have a suitable Sketch Library available. But it is exactly then, when we use other libraries or create our own libraries in-house, that it makes sense for the developers and designers to consider the perspectives of the other discipline respectively, and to find a common language.

On our journey to the DevUX symbiosis, we learned how much it helps to gain more insight into the way each other’s profession works and experienced how we were able to create concepts and vocabulary together that eliminate ambiguities and misunderstandings. Symbiotic working is thereby not only faster but it is noticeably more fun!

Are UI/UX-designers then also developers – and vice versa?

So, if in the spirit of DevUX we try to create a common language and understand each other’s perspective and way of working, will the boundaries become blurred? Are designers then also developers and therefore responsible for mapping the front of the frontend? And are the developers then just as responsible for the design? Do we require some kind of hybrids who can master both disciplines?

From our point of view, this is hardly possible due to the very different skill sets, and also not necessary. At XITASO, we instead rely on experts from the respective disciplines, who form our interdisciplinary teams together with the other roles. Because our understanding of software engineering requires an equal share of all these competences. What is most important is that everyone in the team is open to other perspectives and ways of working, and is prepared to learn from others to create a common understanding. In our understanding, this is not only the basis of the DevUX concept, but also a central part of our values, anchored in the XITASO code.

Software engineering at XITASO: Interdisciplinary networked core competences

Our Conclusion

Design and development are and will remain two different disciplines within software engineering, which sometimes come from very different perspectives. From our point of view this is a benefit as multi-subjectivity creates the best ideas and results. In order to enable the best possible cooperation required for this purpose, it is above all necessary to be open to the other’s profession and to have the willingness to learn from each other in order to create a common understanding. Interdisciplinary teams are a good basis, but it is not enough to just sit next to each other, rather it is much more to show each other how we think and work. This is the only way we can establish a common language with shared concepts and vocabulary to the benefit of all concerned.

Authors & contact persons

Do you have questions, ideas or feedback on this topic? Feel free to contact us!

Dr. Axel Habermaier

Sources and further information