The Silent Subjugation: How we were forced to accept poorly designed software
How we were forced to accept poorly designed software and how to break the cycle
By
Recently our institution announced that the registration system for extra hours will be changed to a new system managed by a third-party company, which in our case was Visma. My initial reaction, as is always with new software, was to be cautiously optimistic. The old system was far from perfect and a change could mean improvement. Sadly that optimism did not last long as I started to try to acquaint myself with the new system.
The interface was unintuitive, cluttered, and uninviting. Furthermore, the guide on how to use it seemed to be for a different version of the software and was completely useless. To perform the very basic task of logging my extra hours, I had to contact our HR department multiple times, only to receive guidance that clearly indicated they themselves were struggling with the system. With every attempt to log in, I felt mentally drained and exhausted, as every suggested fix from HR ended in the same error.
This isn’t an isolated incident. Across industries, poorly designed business software has become the norm, and we, as users, are forced to accept it. These subpar systems play crucial roles in our professional lives and, in cases like this, directly impact people’s paychecks. Whether it’s internal HR systems, bloated enterprise platforms, or public-facing apps, bad software has entrenched itself in our day-to-day work.
The Problem: Apathy and Monopoly
So one arrives to the question of why this is happening? The real reason behind this is simply that the users’ standards have changed so ultimately we could argue that we are to be blamed for feeling frustrated with these soul draining softwares. In the past decade, significant improvements in hardware and cross platform software tools and standards has lead to a significant leap in user friendly UX design.
Further more competition and the free market have lead to developers putting far greater care into developing tools that feel intuitive to use from the get go to be able to gain an advantage over their competitors. And perhaps lastly we should acknowledge the Apple effect, iOS was so beautifully and carefully engineered from the beginning that to this day iOS 1 and iOS 18 share many general features and structures. In the past 10 years our standards have been raised to expect to enjoy using the apps and OS of our devices without feeling any mental drain that one felt when Windows XP froze in the middle of work on a power point, forcing you to restart your computer and begin from the beginning.
The real question to ask then is why this evolution in software design and usability has not translated into the realm of corporate software. First, there is the problem of apathy. Decision-makers often prioritize cost and compliance over usability, entirely disconnected from the daily frustrations of their staff. Vendors like Visma thrive in an environment where long-term contracts, not competition, dictate their survival. Crucially, these companies need only to convince leadership to extend their contracts, absolving them of any need to satisfy end-users or even consider their experience. Once a system is in place, it’s rarely replaced, no matter how dreadful the user experience is. IT departments, burdened by the effort required for migration, resist change, while leadership remains insulated from the suffering endured by their teams. It is this lack of direct accountability that enables such apathy to persist unchecked.
Second, there’s the issue of monopolistic behavior. Many of these systems operate in niches where competition is scarce. Without pressure from rivals, why bother innovating? Customers locked into multi-year contracts have no recourse, allowing software to stagnate, bloat, and crumble under the weight of its own inefficiencies. These systems often go years without meaningful updates, as the companies behind them focus solely on convincing leadership to renew contracts rather than addressing the needs or frustrations of end-users. The result is a grim landscape where mediocrity thrives, and the users thoughts or satisfaction are irrelevant.
The Vicious Cycle of Acceptance
Over time, we’ve normalized this mediocrity. We train ourselves to work around bad interfaces, convincing ourselves that it’s just “how things are.” This learned helplessness is particularly insidious because it shapes the mindset of future developers. By normalizing bad design, we create a culture where flaws become invisible, and the frustration of users is sidelined, perpetuating a cycle of subpar software.
Software developers, immersed in our custom Linux environments and trained in universities to rely heavily on purely functional tools like the terminal, are especially prone to the fallacy of not accounting for the general user’s capabilities. These developers often fail to empathize with everyday users because their training conditions them to prioritize functionality over accessibility. Exposed to these environments, students and early-career professionals may unconsciously replicate their flaws in their own work, further exacerbating the disconnect between software design and user experience.
Breaking the Cycle
What can be done? For a start, we need to demand better. Institutions and companies must recognize that usability is not a luxury; it’s a necessity. Poorly designed software doesn’t just waste time, it demoralizes teams and hampers productivity. A key cause is that leadership often remains untouched by the daily frustrations users endure. They must be pushed, forced, and irritated into considering design the next time they sign contracts with companies providing subpar systems. Organizations should push back against vendors, insisting on usability audits and meaningful improvements.
In parallel, we as users have to resist complacency. We should voice our frustrations, document the issues, and push for change. When given the chance, we must choose tools and systems that prioritize user experience, even if they come at a higher upfront cost.
Developers, too, have a critical role. We must hold ourselves to higher standards, refusing to perpetuate bad design practices. Empathy is key, putting ourselves in the shoes of the end-users and questioning every interaction, not just as someone who spends significant amounts of time in the terminal tweaking Linux environment variables but as normal users who wouldn’t know a dangling pointer if it crashed their entire system. Are we creating something that’s intuitive? Accessible? Respectful of the user’s time and mental energy?
Kill the Beast
There is reason for hope. In the private sector, some companies have made user experience their mission. Slack, for instance, began as an internal tool and became a massive success because it solved real user pain points with elegance and simplicity. When superior alternatives emerge, they force established players to evolve or die. The challenge is getting these better tools into the hands of users who have long been trapped in substandard systems.
This isn’t just about better software; it’s about dignity. As users, we shouldn’t have to endure tools that make us feel incompetent, frustrated, or drained. As developers, we have a responsibility to create systems that empower rather than oppress. Our silent subjugation by bad software ends when we decide it does. As developers, we must kill the old beasts and let something more beautiful take their place. So let’s demand better. Let’s build better. And let’s refuse to accept anything less.