Mehr Infos

The Baby Effect – When Developers Love Too Much

Author: Benjamin Franz

Reading time:

Sep 2023

Love is never bad. And there can’t be too much love. Or so you think. That may be true for people, but it doesn’t have to be the case for products. Today, we’d like to turn the spotlight on what happens when developers love too much. We, that’s 3 enthusiastic UXers who together have been optimizing the user experience of products for users for more than 50 years. And we all know HIM: the baby effect. The baby effect is not about cute toddlers, we are talking about a high identification with an idea and later in the progressive development process with a product – the “baby” of a developer. A connection that often becomes even more intense over time. If we were in Lord of the Rings, Gollum would purr “My preciouszz” and press the ring to himself. It’s all about the defenses you encounter when products need to be changed based on user experience. The psychological “sunk costs”, in other words, which are not paid in euros, but in lifeblood. And this lifeblood increases the longer one works on one’s own “baby”.

User Experience, the word comes from the two parts of the word: User – the user, and Experience – the experience. So user experience design is all about designing the user experience. If you look at many classic companies that do not (yet) have their focus in software development, you might occasionally have the feeling that it is not about the user experience at all, but about the developer experience. Often, the “battle” for the user experience in development takes place in a completely different place than thought: It is not the users who discuss different approaches and do not agree, but the developers who are not willing to change their concept that has been cherished and maintained for years. The reasons given for this on the surface are manifold:

  • internal approvals
  • certain clients, who are known and who need this feature/this process/this interface element… absolutely the same way
  • technical feasibility
  • time to launch
  • the costs
  • “We have always done it this way”


But if you ask and show ways how the implementation of the concept can still succeed, it often still does not go further. One reason after the other comes to the focus, until you as a UXer have the feeling that you are not facing a single developer, but a whole army of reasons. And so, little by little, it becomes apparent: It’s not about the releases or the technical feasibility at all. It’s about fears. And about love.

The fears can be manifold. There is the fear of change, caused by the unknown land that lies ahead of you, by the door you have to open. But there are also fears of failure, such as the fear of no longer being “worth as much” as a developer because your concept doesn’t get the recognition you hoped for or doesn’t meet user needs – but that’s exactly what you actually wanted.

On the other hand, there is the attention to detail that was invested in the development. The many thoughts and hours and agreements that have taken place and through which you have struggled to have exactly THIS product in front of you at the end. The heated discussions with colleagues, the long evenings just before launch, the joy over the finished product. The warm feeling in the chest when the product is out in the wild for the first time. So it’s all about the love for the product that has grown slowly but steadily over many (sometimes lonely) hours.

In both cases, the cause lies in a strong identification and connection of his own person with “his” product. From a motivational point of view, this is also exactly what is desirable. Because only those who are intrinsically motivated can also rise above themselves and create great things. But it also has downsides when identification develops into a blindspot bias like the baby effect described above.

The change suggestion by the UXler or the feedback from the users is then no longer the longed-for help to develop an even better product, but it is perceived as an attack on the great work that has been done. The UXler becomes the parents who don’t accept the first friend. To the others who don’t want to begrudge the friends. To those who don’t WANT to understand why this product is perfect just the way it is.

We find this one thing above all: a pity. But understandable. Coming from a world where technology – and the understanding of it – was the preserve of a few experts, it’s the natural path of many established companies to prioritize the expertise of their employees over the expertise of laypeople. And in many areas, this is exactly the right approach. A user will seldom be in a position to say HOW a product should look. But the user is always in a position to say WHETHER the product is suitable for him and WHY that is (or why it isn’t).

In the meantime, however, technology permeates every aspect of our daily lives and contact with technology has become part of everyday life for many people. Even older people are using an ever-increasing variety of technical products and the Covid crisis has even accelerated this change in many areas. As a result, the user suddenly becomes an expert. Not in the design, but in the use of products, he can suddenly compare and evaluate. Maybe it makes sense to think about the user no longer as a technology layman, but as a use expert who knows more about his goals, tasks and desires than any developer ever could.

And maybe it’s time to rethink in development, too. How would it be if one’s own pride and love were no longer fed by having thought up the best solution oneself, but by having found the best solution with and for one’s own users. Perhaps love could arise not only for the product, but also for the user with his or her wishes, who is ultimately responsible for the success of one’s own product? For this to succeed, respect is a big issue: respect for the goals, tasks, wishes and abilities of the users. Respect for the inventiveness with which developers implement these tasks. Respect for the feedback that comes with the concept. Respect for the resources of everyone involved.

And the best way to conserve these resources is to use user-centric methods and approaches that enable rapid iterations with quick feedback and revision loops. This conserves developer time by spending more time selecting and optimizing and less time defending. But it’s also a way to save heart and pride. If I don’t have time to fall in love with the “wrong” concept due to quick iterations with sample tests, then I can relax and work towards the next stage. And then, in the end, I might have the chance – together with my users – to hug the finished product to my chest and purr “My Preciousss”.

And let’s face it, even a UXer who focuses on the conceptual design work and “forgets” about the users over time can be hit by the baby effect. What helps against this while maintaining motivation to create great products: User-centricity and testing, testing, testing.

And what are your experiences? Do you have a “baby” of your own? How do you solve the problem? We are curious to hear about your experiences.

About the authors:

Dr. Benjamin Franz – Linkedin

  • Study of Mechanical Engineering at the TU Darmstadt
  • Doctorate at the TU Darmstadt on the topic of human-machine interaction in highly automated vehicles
  • Lectureship on the lecture “Design of Human-Machine Interfaces” at the TU Darmstadt
  • Since 2013 founder and managing director of the Data Driven UX agency Custom Interactions, which focuses on User Research / UX / User Interface Design


Dr. Lutz Krauß – Linkedin

    • Study of mechanical engineering at the University of Kaiserslautern
    • Doctorate at the University of Kaiserslautern in the field of human-machine interaction and specifically in the area of interaction elements such as touchscreens; the VDI/VDE guideline was also created in this context (VDI/VDE 3850)
    • Since 2003 at Porsche responsible for UI/UX in different roles for the HMI generations HMI2005, HMI2010, HMI2015, HMI2020 as well as some apps (Porsche Connect, Porsche Track Precission App, Offroad App, etc.)


    Dr. Michaela Kauer-Franz – Linkedin

      • Studied Psychology at the TU Darmstadt
      • Doctorate on the topic of technology acceptance in mechanical engineering at the TU Darmstadt
      • Teaching assignment for the lecture “Design of Human-Machine Interfaces” at the TU Darmstadt
      • Collaboration in the national standardization committee of DIN on the topics of ergonomics and usability
      • Since 2013, founder and managing director of the Data Driven UX agency Custom Interactions, which focuses on User Research / UX / User Interface Design.


      0 / 5 (0)

      Subscribe for our newsletter

      E-Mail *
      This field is for validation purposes and should be left unchanged.

      Related Posts

      Video confrontation – What is it?

      With many of the methods used, it is important not to interfere with the user's interaction with the product in order to get an unbiased picture of actual usage.  How does a video confrontation...

      read more