Badly Designed Systems Are Just That

Learning to Laugh

Life can be a rather humorous existence, or at least, I tend to laugh at myself more than I berate myself. It is a healthy disposition to have. What fools we have been in too many things, though hopefully we have refused to allow those things to define us.

Consider the pressure to deliver a product that was less than ready for primetime, yet pushed towards deployment by the powers that be. This came after misgivings and concerns that eventually became valid and were proved so too.

An AI-generated infographic on the blog content. (Click to enlarge.)

A Premise That Failed

I found myself testing a premise that did not work. Every time I made an adjustment, I did not see the expected result. When I was asked to put it out immediately, I had one inescapable point: what is not working cannot be deployed. I had a slight window of protest, insisting that until it worked on my system, it could go nowhere.

When I eventually got the working parts to work, I realised my error had been using a similarly named old component when the new one was intended. The urge from one end had beclouded my ability to concentrate. Once I discovered what the issue was, I sternly suggested that people should ease off and wait for my update.

Back to the Drawing Board

The next morning, we saw some results, along with the proof of why the other parts would not work. We had the knowledge, but the architects, in their wisdom and hubris, thought they knew better.

Did I not write about this last month, when I set out why technical authority without social consent produces brittle solutions? The whole process returned to the drawing board, yet once again it missed the essential part of engagement that would take a great concept to a successful deployment.

Then came another issue. I had written a letter to express my frustration at being unable to secure a slot for a review. The website presented a user experience you barely wanted to relive once, let alone many times over a couple of weeks.

An Unwinnable Lottery

As I recorded all the issues that fed what had looked like an unwinnable lottery for access, I clicked on another link within the interface, only to find that a slot had already been booked on my behalf, though I could find no record of being informed of that appointment.

I did, however, find one message that allowed the rescheduling of an earlier slot; but I attributed that to another booking I had received a few days before. What was missing from the information exchanges was any indication of what each message particularly pertained to.

When Systems Forget the User

How much better it could have been if they had not assumed they were the only ones communicating with you, and that the possibility of multiple appointments scheduled within a short timeframe might exacerbate the confusion about what was what.

This discovery meant my letter of frustration did not have to be sent. It was also a relief that the said slot had not passed, as the alternative arrangements made would not have been realised for almost three weeks.

The Wry Smile

Essentially, badly designed systems are just that: badly designed, no matter how they seem to work. The end user is simply left with concerns, frustrations and misgivings, entirely out of the frame of what affects them the most, because they are not properly considered as part of why, and for whom, the system was designed.

Then, for each of these episodes, when things are not as bad as they once seemed, there is a wry smile, some mirth and laughter, and even that urge to step out for a walk for having been so worked up earlier.

A Gemini Notebook AI Podcast on this blog

Authority Without Consent

The Weight of Fallibility

Hubris is one of those traits anyone should do well to avoid. Regardless of one's expertise, ability, and confidence, we are prone to error, mistakes, failings, or just the slightest miscomprehension of a situation.

This is not to second-guess the premise; rather, it is simply that an awareness that we may not be entirely correct, and hence fallible, can be a humbling realisation. It shows us the extent of what we intend in our self-belief, and how reality challenges it.

A Rollout Not Ready

Recently, I met the weight of imposition from on high: a process I was neither confident in nor happy to deploy. Developments within the last week have now brought into stark relief that what appeared to work on a single device, with a different kind of user profile, was neither ripe nor ready for a global rollout.

One could snidely suggest that this was a fact posited many times before but ignored because the proposer's office implied an all-knowing mien that would brook no questioning.

Well, it all returned to the drawing board as we identified the kinks in the solution. A new solution has since been proposed that is radically different from the original and contains elements that give one the jitters.

Consequently, we are back to the original arguments of fanciful ideas that appear to work in isolation but require a different mindset when set for a global deployment.

Authority Without Consent

What this episode really lays bare is a simple truth: technical authority without social consent produces brittle solutions. A design may be elegant on paper and hold together in isolation, yet the moment it meets the messy reality of many hands and many machines, it fractures, not for want of cleverness, but for want of ownership.

There is, of course, a counter-argument that imposition is sometimes necessary, and that endless consensus can stall a decision indefinitely. I would not dismiss it. But there is a world of difference between the people who run the environment, who understand its issues and problems intimately, and an architect parachuted into a situation who consults no one, believing they already know everything necessary to fix things.

We appreciate that things need to improve, and we would welcome ideas, insight, inspiration, and implementations to put matters right. The question is whether there is a better way for this to go forward without proper engagement. I would suggest there is not.

What an Architect Should Be

An architect should not be like a bull let loose in a china shop, nor should they be a cowboy riding a three-legged horse. My view of an architect is someone who listens and observes intently, appreciates and understands, then suggests rather than imposes, carrying people along rather than rubbing them up the wrong way.

When you break the social element of engagement that helps take ideas to implementation, whatever concept is in the plan is likely to fail. This is not because people have refused to do it, but because the prospect is not owned by the people who would eventually manage it.

If you are an architect, ensure that this is not one of your flaws. Get the builders onside before you take your grand scheme to town, selling castles in the air that no one can reach, even if they could fly.

A Gemini Notebook AI Podcast on this blog