The sad story is: there are too many UX professionals with high stress and even burn-outs. This article takes a systemic view on development teams and introduces the concept of a burn-out system. The goal of the article is to raise awareness for burn-out and stress, gain understanding of contributing factors and exchange ideas on how to improve the situations. Therefore: spread your word and your experience!
By Markus and Rahel *)
*) About Rahel Vils. Rahel co-founded the online recruiting service TestingTime. She is a passionate UX and Visual Designer and, with her Agency Virtually Handmade, she turns complex web projects into user friendly applications. She also engages in building up the UX community by organising the UX Brunch.
In a thought experiment – this started at the UX Brunch in Zürich (2019) together with Rahel and evolved over time to the current state presented at the UX Summit in Vienna, the online UX meet-up with the Austrian community in 2025 and a talk at the UXPAlooza conference in 2025 – we put Rahel into the hot spot of a burn-out system and observed and analyzed a burn-out system in full action. The thought experiment is based on the team squeezer and the burn-out machine game. Especially playing the latter helped gathering many of the war stories that made up Rahel’s case. You find the latest at the bottom of the article.
Burn-out and burn-out systems
Burn-out (e.g. see wikipedia) is the effect of quite a complex interconnection of factors. There are different approaches to deal with burn-out: (1) a healthy environment to work and live in, (2) personal resilience to cope with difficult situations and if it comes to the worst, (3) therapy to recover from a burn-out.
While therapy and personal resilience are important tools, this article is about a healthy work environment and even more specific, about a systemic view of the work environment. And that is where the concept of a burn-out system comes in.
A burn-out system is a system of collaborating persons set up in a way, so that some individuals in the system are investing more and more energy until they burn-out.
In the heart of the burn-out system is a reinforcing cycle. The reinforcing cycle is primary created through cleverly crafting a constellation of unmanaged and generally misunderstood conflicts. Such conflicts may stem from bad job design, incompatible individual values, inadequate external influences, too difficult tasks, unfair evaluation of individuals, and more.
To activate the vicious cycle, a bit of pressure is needed. This pressure will first stop individuals from thinking too much about what they do and why. It then uses the negative impacts introduced to increase the pressure. In the most dangerous state, the survival strategies of the individuals are activated.
How to burn-out UX professionals – an example
At the UX brunch, the participants were able to witness a burn-out system in full action, drawing our host Rahel into a vicious cycle of overwork and frustration.
It all started with very exciting news: an important client of Rahel’s fictuous company had ordered a new software package. The project team – consisting of Rahel as UX expert, a leader and a couple of engineers – was starting their work on building and delivering the software.
The first two days, the team invested in a kick-off meeting where they laid the ground for the coming development. We happened to meet Rahel in our regular UX circle, just the day after this kick-off.
M: “Hi Rahel, you look excited. How are you?”
R: “It’s just great! The project kick-off was awesome. The client wants the best possible user experience. We are finally able to do thorough user research. And even better, Thomas, one of our engineers, has offered to support me in the UX activities.”
The start of the project was a success and the team was eager to begin. The participants of the UX Brunch could have witnessed a role model of how one builds a great piece of software. Alas, I was tampering with the situation and fabricated a burn-out system. This system was not really visible yet. Just to hint at it: How ambitious were the goals? Had the team a realistic perception of the challenge? And what influence had the VIP status of the client?
To see more of the burn-out system, we had to turn the wheel of time forward, just a few weeks, not more. We met Rahel a second time in the company’s cafeteria where she just grabbed a cup of coffee.
M: “Hi Rahel, you look upset. Something the matter?”
R: “No no, all’s right. I’m just a bit disappointed. The project is not going as I imagined it to.”
M: “What did change?”
R: “There have been new features we have to do. And as we want to make the deadline, I had to cut on user research.”
M: “And now you are disappointed that the quality of your work will suffer?”
R: “Yes. But even more so I’m frustrated that we make the same mistakes all over again. We are always so eager to please the customer that we cut down on the user experience even though it leads to big flaws in what we deliver.”
So here they were, the first noticable effects of the burn-out system. At the UX brunch, we had a closer look a three effects:
(1) The project team tried to deliver more for the same deadline. This meant less effort per item to deliver and the need to increasing working speed. The first thing the team did was to stick to what they knew and throw everything else off board.
(2) The pression on Rahel rose. Even though there was more work to do, the expectations regarding user experience did not change and especially not Rahel’s own expectations. Rahel had just limited options to achieve it.
(3) The cut on UX activities also signaled a drift of priority in the team. Rather than achieving a great user experience, the team strives to make the client happy with features. User experience became optional, a side note.
The team changed the rules of the game and these new rules started working on the team, making the situation much more dangerous. Another couple of weeks later, it was late afternoon, we happened to meet Rahel in the elevator for the third time.
M: “Hi Rahel, care for a coffee or a tea?”
R: “Like too, but I’m really short on time. I have to finish the mock-ups asap.”
M: “Can’t you do that tomorrow?”
R: “No way. We were just looking how to speed up things so we can cope with the grown scope. Thomas will not be able to help me any longer. He has to focus on the development. And, even more importantly, the team decided to put some investigative work aside and focus more on getting things done. Therefore, I need to finish the mocks earlier so they can start implementing.”
M: “You are taking up an impressive speed. The UX concept is ready then?”
R: “Mostly. We were obviously not able to test it, but I’m confident it will work. And for the missing parts, I will just have to rely on my experience. It will do.”
M: “Thus creating the mock-ups is more important than finishing the UI concept?”
B: “It is much more urgent. If I cannot deliver detailed mock-ups of the user interface to the developers, they will create just anything. But the blame will still be on me. Well, I have to go. See you.”
Rahel was in an awful situation, we all felt with her. The team was struck by that nagging feer of failing the deadline. It made them urge forward and take the most outrageous short-cuts. These short-cuts were bound to back fire.
To our horror, the activities regarding UX had been reduced to creating high fidelity mock-ups of the user interface. And as an after effect of the optional UX activities, Thomas was assigned back to where he was really needed: developing software.
Rahel’s priorities had to shift yet again and they shifted to fullfilling her job – we all did notice the survival logic kicking in – which is to specify the user interface for the developers.
As everyone in the team activated their protective shields, heat in the team did rise. And being optional, Rahel was the perfect scapegoat whenever something got too tight. The vicious cycle I fabricated was fully operational.
At that moment, at the UX brunch, we decided to again take jump forward in time for roughly two more month. We met Rahel for the fourth time. It was seveninsh in the evening, we were at the local train station on the way to have a nice team dinner. Rahel apparently just was on her way home from work.
M: “Hey Rahel. We’re going to grab some food for dinner. Do you want to join us?”
R: “I’d rather not. I’m exhausted and I just want to go home and fall into bed. I just did nothing but work for the last few days.”
M: “How awful. What is the matter?”
R. “The devs couldn’t finsish a few things in time becaue I overlooked some cases and did not include them in my mock ups. I had to redo them basically from scratch. And the devs will be mad about the amount of changes they need to do.
M: “Does this happen often, that you have to redo stuff?”
R: “Sadly, yes. I know exactly how the UI should look like but I do not have the time to bring it to paper in the needed level of details. It would delay the project even more. And at the same time, I have to look ahead as well and work on the stuff devs need to do in the near future.
M: “What do the developers think? ”
R: “Oh I don’t know. Somehow nobody is happy with my work. I know that the UI has conceptual flaws and that the mock-ups I deliver have gaps. But what can I do? I have no idea where I could take any more time from.”
The shit hit the fan and Rahel was in the midst of it. There was no common goal in the team, anyone was just eager to safe their skin. It did not matter whether the functionality built made any sense or whether the target audience would get something useful.
Rahel was just a supplier of mock-ups. The workload was enormous and even evening and week-end shifts did not suffice to cope with it. And no matter how hard she worked, she would always get the blame. At this stage, it was just a matter of time until Rahel would burn-out.
Therefore we stopped the thought experiment, rescued Rahel from the burn-out system and turned to the question that needed our attention: How by all means did this happen? How did this devious burn-out system create such a huge pressure on just one person? How can we change this?
How to burn-out UX professionals – an analysis
As already mentioned, the danger of a burn-out system is rooted in the reenforcing cycle that heats up a situation.
The components of the vicious cycle are:
| Perceived margin | Someone perceives a situation as tight and threatening and starts spreading the word. |
| Changed behavior | The individuals change their behavior to cope with the seemingly tight situation. Inner drivers, well trained behaviors, and survival strategies kick-in. |
| Reduced performance | The changed behavior introduces defects and lowers overall performance. |
| Heated up conflicts | As progress is slowed down, the situation becomes tighter and conflicts heat up. |
| Blaming | Some persons in the system get the blame, the situation becomes threatening. |
Every time we met Rahel, the team was in a different stage of that vicious cycle of the burn-out system:
| 1 | 2 | 3 | 4 | |
|---|---|---|---|---|
| Overall team goal | Impress customer with great UX | Satisfy customer with features | Deliver features | none |
| Measures taken by the team | promise attractive package | Extend scope Accelerate development | Do short-cuts | survive |
| Rahel’s personal goals | Do UX as it should be done | Do UX as good as still possible | Deliver required mock-ups | survive |
| Team spirit | Enthusiasm | Disappointment | Resignation Frustration | Mobbing |
The Bermuda triangle of software development
The whole thing seemed to go wrong when the scope was extended. The team did not adjust the magic triangle (scope, team, time). So the team had more on their plate than they could tackle. They had to drop something and the first thing to go were the new things, i.e. the UX activities. Together with this, the team goal shifted unnoticed and disalignment between personal goals and team goals became significant. Rahel for example either had to reduce her UX ambition or take on even more UX responsibility. She did the latter.
The team ignored a couple of basic rules:
- When you add new tasks to a project either you remove some other tasks or or you add more resources, i.e. time or people. A word of caution: adding people needs extra time and effort from the team, if the situation is well heated up, this will usually make things worse.
- When time is tight, do not work faster, work cleverer. Get creative and figure out what your really have to deliver to be successful. And invest into getting more effectiv doing just that.
Goals diverge under pressure
When the team extended the scope a crucial thing happened. The team, besides Rahel, silently adjusted their mission from delivering great user experience to delivering many features. The goals of Rahel and the rest of the team drifted apart.
With this, the burn-out system managed to single out one person from the group: Rahel. There is now a critical conflict between Rahel and the rest of the team. The more Rahel insist on the great user experience, the more this conflict will separate Rahel from the team. She now works “against” the team as she pursues other goals. Rahel becomes the obvious scapegoat to take some blaming.
The trap: UX professionals deliver user experiences
When the team decided to rush forward, Rahel fell into the trap I layed out for her when I designed the burn-out system. She stuck to deliver great user experiences even so the team switched to delivering features. I counted on her ambition or maybe professional pride or even conviction, that a great user experience matters and is worth an extra effort.
When the burn-out system was fully installed, Rahel was forced by the burn-out system to put her energy into delivering high fidelity mock-ups to the team. By delivering the high-fidelity mock-ups, she reenforced that she will do the user experience and the others shall not bother. However, based on a flawed concept, little user research, no time for testing, and not even enough time to do it properly, the mock-ups she made were far from perfect.
The flaws she introduced made the team do extra work, so the team pointed more and more to her. Rahel herself felt unhappy about her work, but lacking time, she was powerless to change it. Rahel also felt left alone by the team, she had to fight the battle for the users all by herself.
In this diffcult situation, Rahel took the one approach left to her, she worked harder. Thus she made even more high fidelity mock-ups, introduced even more flaws, got blamed even more, felt even more powerless and alone.
Some more basic rules got violated:
- If a team wants to create a great user experience, everybody in the team has to take responsibility for it.
- When you want people to take responsibility for UX, the team must also play an active part in defining and executing the process of creating it. Creating high-fidelity mock-ups is an excellent way of excluding the rest of the team.
- When a process leads to defects, halt it and change it. At any rate, do not execute it even faster. Neither blame those executing it.
The trap part two: the assembly line
The assembly line is a important principle in production, where thousands or even millions of pieces with constant quality must be produced efficiently. Such assembly lines are well balanced and the overall throughput is optimized. To put it very simply: the slowest station defines the speed of the assembly line.
The goal shift and the behavior change from Rahel and the other team members resulted in a workflow team setup which is very similar to the assembly line. Customers fed in their requirements to Rahel, she made the mock-ups and handed them over to the team for implementation.
The dangerous thing about such a workflow setup in software development is, that the speed is usually not defined by the slowest station and the throughput is not optimized. In Rahel’s case we can assume that both developers (“we need the mock-ups now or we cannot finish the features in time!”) and customers (“Can we have it this way?”) added pressure on Rahel. Rahel was quickly overflooded with requests from customers and developers. No wonder she made the most outrageous short-cuts! And every defect in her mock-ups came back with more work. So she sped up – and introduced more defects!
So remember this very simple logic: Whenever you split up work on a feature to different disciplines (e.g. business analysis, development, visual design, testing) or different layers (e.g. UI, back-end, database, interfaces) you create an assembly line where one station is constantly overloaded and others underloaded. The underloaded station will increase the pressure on the overloaded station. If the overloaded stations starts to hurry up, they will introduce defects, become slower and get the blame!
Side note: Agile teams and upfront work
Given that the team followed agile principles they tended not to investigate too much up-front. However, with current design processes, achieving a great user experience needs significant up-front effort where the team explores different ideas and approaches. It seems quite likely, that neither team (besides Rahel) nor customers saw any benefit of doing such up-front work. Therefore they started the development without a clear picture of what they wanted to achieve and Rahel had no time to develop a sound concept.
Root of evil – hidden conflicts
There are many situations where the traps above would not have had such drastic effects. However, the burn-out system designed here had some key characteristics and conflicts. Lets quickly review them and start with some aggravating factors:
- Missing know how respectively the low maturity in the team about how to achieve a great user experience.
- UX was Rahel’s responsibilities
- Nobody saw a need for up-front UX activities like user research and validation.
- Everybody expected Rahel to deliver mockups.
- Rahel’s inner drivers (see below) which made her work harder when things got tight.
- The developers disposition (and survival tactics) to leave the requirements stuff to someone else, i.e. Rahel.
The heart of this specific burn-out system were the following three conflicts:
- The too tight project frame, aka Bermuda Triangle of software development. Once the team thought the project frame was too tight, the vicious cycle started.
- A conflict of values between Rahel and the rest of the team made Rahel stick to the original goal while the team switched to another: It separated Rahel from the rest of the team.
- A structural conflict between Rahel and the customer and the rest of the team stemming from the workflow setup: It put Rahel into overload.
Did you realize when reading through the three conflicts above that there is something missing with the first one? Namely, conflicts are always between persons, that is part of the definition. Can you name the persons who have a conflict? Was it between the customer and the team? There is an obvious conflict of interest between customer and supplier: customers want big value and suppliers great margin. But did this conflict really matter in this case?
The important thing to understand is, that even without the customer asking for more, this situation would have escalated. Endeavors like creating software are too complex to foresee every possibility. Something will hit the development team. Somebody may take ill, something may prove more difficult than expected, some feature may have been forgotten and much more. Any of these events could have caused a tight project frame and thus start the vicious cycle.
Therefore: is the Bermuda Triangle really a conflict or is it just the symptom of much deeper conflicts? And why was the project frame so tight? Was it really tight? Or did it only appear so?
The fascinating thing is: WE DO NOT KNOW! Neither did Rahel nor the rest of the team! But how can a team resolve conflicts if they do not understand them? The blunt answer is, they can’t. And the measures taken to resolve this crucial conflict will most likely backfire!
#1: Work on hidden conflicts – stop the cycle of the burn-out system
And this is exactly the point. We often find such situations where everything feels tight. People just feel the pressure coming from someone and thus they just put the blame on those who should have done a better job. They do not understand the conflicts and the constraints that keeps the situation so tight.
Have a look at the following key conflicts and what finally helped the team to disarm the burn-out system:
| Key conflict | Successful approach |
|---|---|
| To replace an existing system, too many features were needed | The team (including the UX professional) invested creativity and energy in finding simpler and easier solutions for the features. |
| A company needed to act fast on the market. | The team invested more time into getting to know the customers and what they really needed on the market so they could figure what a good reduced product would be. |
| The project responsible promised too much to management and business. | The team dedicated a lot of time in understanding business, managing the expectations, and building exactly the essentials to support the business processes. |
| A system needed to be ready for a specific event. | Rather than building the software for all coming events, the team provided just the support needed for that event and extended it later. |
| A team was convinced the customer would not be happy with what they were able to deliver. | The team invested time so they understood the customers’ real problems and why a simple solution was just the right thing. |
| A client promised a five percent bonus if the supplier team would meet a deadline. | The team had to focus on what was really needed for the deadline and to make sure that the client would accept the package. |
#2: Plan for the pessimistic situation, not the optimistic
Maybe it is best to start with the assumption that your are in a burn-out system. Thus take the time to understand the conflicts and the constraints of the setup and immediately take action to change them to be more favorable. Whenever you are on the verge to say that some person should have done a better job, stop this line of thought, dig deeper.
A possible way is to create a when-things-get-tight plan together with the key stakeholders. When done, throw away your original, idealistic plan and make the when-it-gets-tight plan your plan A. Your plan B is the when-it-comes-to-the-worst plan. This plan tells the minimum deliverable with the maximum time and costs so the business case is still worth investing in. If you’re forecasting tells you, that you cannot meet the when-it-comes-to-the-worst plan, either kill or cure the project.
#3: Safety net – a strong team
A weak team where members are blaming each other will not be able to handle a burn-out situation. Especially the leaders in a team can work for strong team properties:
- A common goal and commitment what the team wants to achieve together, this also includes the target user experience.
- shared values of how to work together and a feeling of responsibility for the product and the experiences the team creates.
- a culture of respect and helping each other
- a culture where curiosity for others special field is rewarded and the walls around the gardens of specialization (like user experience and user interface design) are torn down.
As a very first starter, listen to how the people in the team use the words we, they, I, and you. Whom do they include in the team (we), how strong is the group compared to the individuals (We versus I), does a specific person belong to the group (we versus you), and who are the The Others, i.e. the opponents (they). Need an example?
- We – the team: “It takes too much time until we have those high fidelity mock-ups with a good enough quality. What can we improve?”
- I – a team member: “There is no way I can finish the mock-ups in time. I cannot possibly work any more.”
- You – the outsider: “The mock-ups are not good enough. You need to fix it.” Or even more pronounced: “We could not start the story as you did not finish the mock-ups yet.”
- They – The Others: “The mocks-ups they deliver are not good enough. I can’t understand what takes so long to update a few screens?!”
Quite illuminating, isn’t it? Maybe a discussion about who needs to take responsibility and how everyone in the team can contribute might help.
#4: Accelerators – inner drivers and other behavior
Get to know yourself and be watchful for one of the following five inner drivers:
- (“be strong”) Do you need to be invincible and able to do it all by yourself, getting help would feel like a failure or cheating?
- (“be perfect”) Are you not happy until the result is perfect, not even the tiniest flaw is allowed?
- (“work hard”) Are you increasing the working hours to evenings and weekends, are you trying harder the tighter it gets?
- (“hurry up”) Do you feel pressure to work as fast as you can, that there is never enough time?
- (“please others”) Is the well-being of others more important than you and do you shy away from conflicts and resolving them because others could be hurt?
All of those drivers are important: It is not a bad thing to work hard, to deliver high quality, to be quick, to do things independently and to make others feel great. However, in some situations, such drivers have a big impact in the vicious cycle of the burn-out system. In Rahel’s case, the inner driver work hard kicked in very noticeably. If you know your drivers, you can learn to counteract!
#5: The sniper from outside – keep an eye on the incentive systems
Beware of the incentive system in your company. Companies generally have incentive systems where personal success is a key requirement for getting a career going and they put that into individual goals. There however is a simple rule of thumb, a heuristic truth, so to speak:
Individual goals foster burn-out.
Actually, setting goals and trying to achieve them could be a good idea. The thing is that we were told to be SMART with our goals, but nobody really seems to be able to set helpful goals. So instead we set counter-productive goals. By the way the more modern flavor of OKR is handled none the better.
Want an example? The following is a goal some AI proposed as a good example for a software developer, so why not take it? We’re going to see loads of that soon anyways! “Complete the development and testing of module X by the project deadline of October 27th, according to the specifications outlined in document Y.”
Now lets assume things are a bit tight (they always are) and that the developer in question thinks that achieving the goal is important for some reason. So what does this developer do?
- Help others in the team? No time!
- Finger pointing at business analyst, product owner and UX professional? Great idea! Requirements are never exact enough anyway and this puts the blame one someone else.
- Participating in a workshop to improve teamwork? Waste of precious time, not if it can be omitted.
Any resemblance to real developers or the developers in Rahel’s team is just coincidence
The thing about such incentives is that they introduce very hard to solve conflicts into the team, exert pressure on individual members and provoke actions, like blaming, that fire up the devious cycle of a burn-out system.
While I’m at it, I can also provide some goals for UX designers. For example to enhance prototyping skills the AI proposed to “set a goal to create high-fidelity prototypes for at least two major projects within the next quarter, using tools like Figma or Adobe XD.” Well done, the thusly incentivized UX designers will now create those Figma screens whether it makes sense or not. Rahel?
Knowing the incentives working in a team is very insightful. And maybe things can be changed if the team starts a discussion about it? Some incentives are a mare’s nest, other might need quite some discussions so that individual goals can be achieved while keeping a strong team and not creating too much pressure for those in the hot spot of the burn-out system.
BTW: if you are a leader and do set goals: Why don’t you stop doing this silly stuff and concentrate on what really is valuable: like helping your colleagues do to a great job in the teams they work in?!
Your next step? Discuss stress and stressors in your team
Persons caught in a burn-out system have usually not the mental freedom to step back and see the burn-out system neither the flaws in the team. Thus if you happen to be one of those who can step back, take up the responsibility: rather than blaming the weaker ones and feeding them to the burn-out system, raise the issue and start to create a stronger team. For all others: the moment you think that someone – this could also be you – should be blamed, take this as a sure sign that a burn-out system is operating. Thus take a break, a deep breath, step back and start searching for the burn-out system.
By the way: understanding the generic concept of burn-out systems may actually help others to reflect on their situations, spot the burn-out systems and disarm them. So spread the word.
Slides from the UX Summit at the Technikum Wien, they are in German:
UX-in-a-burn-out-machineSlides from the UXPAlooza conference, September 19th 2025. These slides are in English.
2025-09-Avoid-burn-out-look-out-for-burn-out-systems