At the UX Brunch in Zürich on December 6, 2019 Rahel and I held a presentation and some very engaged discussions on how we as UX professionals ourselves heat-up the burn-out systems we are caught in. Here is a summary including some of the slides of this session.

By Markus und 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.

The presentation is based on the team squeezer and the burn-out maschine game. Especially playing the latter helped gathering the war stories needed.

Burn-out is the effect of quite a complex interconnection of factors. There are different lines of action 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 does not cover these topics. It 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.

Burn-out systems

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 primarly created through cleverly crafting a constellation of unmanged and generally misunderstood conflicts. Such conflicts may stem from bad job design, incompatible individual values, inadequat external influences, too difficult tasks, unfair evaluation of individuals, and more.

To activate the vicious cycle, just 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 five 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 days. 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 threw 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. Just Rahel had limited options to achieve it.
(3) The cut on UX activities also signaled a drift of priority to the whole team. Rather than achieving a great user experience, the team should strive for a happy client. 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. Just eight days 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 take quite a jump forward in time: three month it was. 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

​​Every time we met Rahel, the team was in a different stage of that vicious cycle in the burn-out system.

​​The whole thing started 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.
• If you want to create a great user experience, the whole team must make it their purpose to do so. The more one person takes over the responsibility, the less the others will do.

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 put her energy into delivering high fidelity mock-ups to the team. Worst thing she could have done. By delivering the high-fidelity mock-ups, she basically told everybody in the team, that she will do the user experience and they 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:

• When you want the team to take over 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 exluding 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.
• Stick together as a team. Whenever you or someone in the team starts finger-pointing, stop it and fix it.

Just to summarize the analyis, here is the trap I layed for Rahel when I fabricated the burn-out system:

The burn-out system uncovered

There are many situations where the trap above would not have had such drastic effects. However, the situation created here had an additional difficulty, it was a burn-out system aimed at the UX person.

But what is the nature of that burn-out system?

The first clue is the trigger, where it seemingly went wrong: The customer asked to add new tasks and the team added the tasks to the project without changing the project parameters.

Time and team were given, the deliverable was growing, so the only thing left was to invest more energy. In consequence the individuals instinctively activated protective measures. Those measures implied lower quality and flaws. Removing the flaws needed extra energy. This in turn activated more protective measures. Therefore the team made more short cuts, introducing more and more severe flaws.

The important thing to understand is, that even without the custumer asking for more, this situation would have escalated eventually. Endeavours like creating software are too complex to foresee every possibility. Something will hit the project team. Somebody may take ill, someting may prove more difficult than expected, some feature may have been forgotton and much more. Any of these events could have caused the vicious cycle to start.

The fundamental issue was the too tight project frame. And this was just the hazardous situation I needed to be sure that the vicious cycle would start and that the trap I laid would catch the UX Expert in the team.

The question is, why was the project frame this tight?

For the situation we observed at the UX brunch, the answer is: we don’t know and neither did the team.

And this is exactly the point. We often find such situations where everything is 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. Just, how could a team act successfully without this understanding?

Disarming a burn-out system

Sadly, I do not know of a silver bullet to disarm a burn-out system. Looking at the following tight situations it might get clear why this is so:

• A company needed to act fast on the market. They invested much more time into getting to know the customers and what they really needed than planned so they could figure out a reduced product.
• The project responsble promised too much to management and business. The team dedicated a lot of time in understanding business, managing the expectations of business and management and building exactly the essentials to support the business processes.
• To replace an existing system, too many features were needed. The team invested creativity in finding simpler and easier to build solutions.
• A system needed to be ready for a specific event. Rather than building the software for all coming events, the team provided just the IT support needed for that event.
• A team felt that a customer could never be happy with what they were able to deliver. Investing time so the team understood the customers’ real problems and why a simple solution was a good solution helped.
• A client promised a five percent bonus if the suplier 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.

Every situation is different and so is the best course of action. Here are a few options:

(1) Start with the assumption that your are in a burn-out system. Thus take the time to understand the conflicts and the contraints 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.

(2) Create a when-things-get-tight plan together with the key stakeholders. This plan is a binding agreement about what goes first from the magic triangle when things get tight.

(3) Now you 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 ist still worth investing in.

(4) When your forecasting shows, that you cannot even meet plan B, immediately act and either kill or cure the project.

(5) Maintain your in-out-undecided list. Given your knowledge about remaining effort and risks, you regularly agree with the key stakeholders what you do with the remaining time.

The undecided ones are the ones that will not be done given your most pessimistic forecast but can be done with your most optimistic forecast.

(6) Also a good idea is the our-priorities board. On the wall in your team room, you put up your most important persona. And you put up the one need of that one persona that you’re going to address primarily.

Besides that one need you also show the other personas and needs your are not going to pursue with that highest priority. The tighter the situation, the fewer things are done that do not help the primary need.

Other things to help you in a burn-out system

While disarming a burn-out system is one of the biggest lever, this is not the only one a team should use.

A weak team where members are just fire fighting and blaming each other will not be able to overcome a burn-out system. Work on creating a strong team:

• A common goal and commitment what the team members want to achieve together.
• shared values of how to work together.
• a culture of respect and helping each other
• effective processes and shared know how.
• constantly improve the team, the individual skills and the ability to focus on the essentials.

Still, 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 responsibilty: rather than blaming the weaker ones and feeding them to the burn-out system, initiate the journey to create a stronger team and to disarm the burn-out system. 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 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.