{"database": "pelican", "table": "content", "rows": [["ryan", "musings", "## The Origin of Systems\n\nWhen thinking about systems it's easy to think that they have always been\nthere, or been that way. This isn't true of course. The systems that are in\nplace were put there, by people. People that made decisions. Decisions are\nwhat I want to focus on here.\n\nIn general when making a decision about the implementation of a system you\nwould want to engage with the stakeholders of that system. This of course\nimplies that you can identify at least some of those stakeholders.\n\nBut sometimes there aren't any key stakeholders other than regulations, or\nbest practice, or some other nebulous thing that needs to be met. These are\nthe decisions I really want to focus on.\n\n## The Illusion of Success\n\nTake a security system for instance. The basic tenets of the security system\nare that it keeps 'something' safe. If the thing to be kept safe is still safe\nafter the implementation of the security system then the people that\nimplemented the system can claim success. They can look at the evidence that\nsince the security system was put into place the thing has been kept safe.\n\nOf course, it's entirely possible that the thing was never in danger, and that\nthe previous system was doing just fine. In fact, it could be that the\nsecurity system is actually making it harder to keep the thing safe. It's just\nharder to see because all you're looking at are potentially meaningless\nmetrics like. Questions like is the thing safe after implementation of the\nsecurity system don't take into account if the thing was 'unsafe' before? This\ncan lead you to think that the new security system must be responsible for the\nsafety of the thing.\n\nSomething else that can be happening is that the security system has caused\nthe people responsible for keeping the thing safe to work more hours, hire\nmore people,who are oftentimes keeping the security system running.\n\n## Questioning Purpose\n\nThe more we look into a system like this, the more we might ask, \"Why is it\nthere?\"\n\nThere can be a couple of reasons, but I'll focus on one in particular. The\nperson ultimately responsible for keeping the thing safe can show with some\nkind of metrics that the thing is safe with the new security system, whereas\nthey couldn't under the previous system. There weren't any reports or metrics\nthat showed what was going on, which is why the system was implemented in the\nfirst place.\n\nOK ... so that's how some systems can be put in place.\n\n## User-Hostile Systems\n\nWhat about systems that are hard to use, or maybe actively hostile to their\nusers? How do those get put into place? I would argue that the reason we see\nmany user hostile systems in place is because they are decided upon not by\ntheir users, but by their ability to meet regulations, AND their ability to\nmaintain by a support system. The consideration of the user is secondary, or\nmaybe not even thought about.\n\nThink about any Enterprise software you've ever encountered. Would you say\nthat it was a joy to use? Would you say that onboarding was simple, and that\nnew employees loved to use it? My guess would be no.\n\n## Why Bad Systems Persist\n\nSo if the users don't like it, why is it in place? Two reasons:\n\n  1. It meets some kind of regulation (this could be a government regulation, but it could also be a regulation of a guild, or union, or something else)\n  2. It's easy to maintain by the support system\n\nFor any software that meets these criteria you are likely to have users that\ndon't like the software, because they are always an afterthought. The primary\nresponsibility of the software developers of these types of systems is always\nthe regulators, and the support infrastructure.\n\nThe first because they have to keep producing software that is compliant in\norder to be sold with a specific rating or seal of approval.\n\nThe second because if the support team can't easily support it, they're going\nto find an alternative solution that they can support.\n\n## Conclusion\n\nIt's a simple decision of maximizing for the people that enforce the rules\n(regulators) and that make the decisions (support). The users of the software\ndon't matter. At all.\n\nThis is why you will see software for widget processing that could benefit\nfrom bulk operations, keyboard shortcuts, or being browser agnostic and they\njust aren't. The only considerations are: Does it meet the regulations? Is it\neasy to support? If the answers are yes then the users tend to lose out. They\ndon't matter. If the answer is no, then find a competitor that does and move\nover to them, even if the current system is loved by your users.\n\n", "2025-03-31", "the-invisible-decision-makers-why-systems-ignore-their-users", "## The Origin of Systems\n\nWhen thinking about systems it's easy to think that they have always been\nthere, or been that way. This isn't true of course. The systems that are in\nplace were put there, by people. People that made decisions. Decisions are\nwhat I want to focus on \u2026\n\n", "The Invisible Decision-Makers: Why Systems Ignore Their Users", "https://www.ryancheley.com/2025/03/31/the-invisible-decision-makers-why-systems-ignore-their-users/"]], "columns": ["author", "category", "content", "published_date", "slug", "summary", "title", "url"], "primary_keys": ["slug"], "primary_key_values": ["the-invisible-decision-makers-why-systems-ignore-their-users"], "units": {}, "query_ms": 0.7577724754810333}