The Principle of Least Astonishment and how it relates to outcomes-thinking
Just because it can be done should always be balanced with should it be done. Thinking about what you are trying to achieve holistically can help detect when these are in conflict.
It’s common for there to be tension in relation to qualitative aspects of the experience people have interacting with the organisation’s products and services. This has long been seen in areas such as the quality of customer service experiences or the degree of friction in the user experience.
More recently in the study of ethics, the articulation between what can be done and what should be done has been a well-articulated framing of the need for a more holistic consideration of the consequences of the choices we make.
Today’s example is one from the user experience side of things, we will see how the Principle of Least Astonishment (sometimes known as PoLA or also as the Principle of Least Surprise) is an example of balancing what can be done with what should be done. But first, let me share an anecdote which may illustrate what breaking this principle means in real terms for a user.
I had an amusing and slightly embarrassing experience recently. I’ve been doing a little bit of consultancy recently through some Technology consultancy firms here in New Zealand for various of their customer companies.
I onboarded on to one consultancy and as I was setting up the systems they provided access to I was asked if I might have some use for a very handy AI-powered note-taking service. As I knew there were likely more interviews and other sessions I may need to conduct as part of the engagement, I said yes, a hasty choice I would soon regret.
Less than an hour later an invite to this additional tool came through and once my account was set up I stepped through the onboarding wizard for this tool. It asked a few simple questions about how I intended to use the tool which I answered and within a few seconds it was set up and I went on to configure the next few tools the consultancy offered. A very smooth onboarding overall, I was impressed.
The next day some invitations for meetings on Friday came up, a few of which I accepted - some I intended to join on the day if I could, in between getting some important errands I wanted to clear off my plate before work began the following week. This was a good chance to meet with some peers ahead of jumping into work on the client engagement the following week.
I attended the first meeting, one on OKRs which of course caught my interest, and I was surprised to see the transcription software I had onboarded to a day earlier had also logged onto the meeting! I figured I must have triggered it accidentally in my haste to join the meeting between other activities. I made a mental note to look into why this happened in the evening after my errands.
I joined another meeting an hour later and this time I didn’t see the bot so it reinforced my theory I had accidentally triggered the bot and I would need to spend some time to work out how to ensure it didn’t happen again. If it wasn’t joining every meeting I could go to my appointment in the city and solve it later.
There were a further two meetings in the afternoon I couldn’t join as I was still completing errands through into the evening when I finally got back home. I relieved my wife and mother-in-law to care for my son so they could attend to their own Friday night commitments. I entertained my boy and then got him ready for bed.
Once my son was off to sleep I thought I would take a moment to investigate the issue. To my surprise, I discovered the bot had attended four meetings that day! This was the first semi-official day of work and meeting my new colleagues so it wasn’t without some embarrassment.
For the first of the meetings I had accepted but couldn't actually attend, the bot attended without me, and from the transcript, I could see it and I were a brief (and very respectful, in fact, someone very accurately had surmised what had happened) topic of conversation. It had taken great notes on the substance of the meeting on a topic I was keen to catch up on, so there was a silver lining.
This brings me to a few issues with what happened:
It is not yet common or accepted practice for artificial agents to attend meetings in your absence. In fact, there are lots of features of the tool I later discovered which give you the option to provide attendees 24 hours of notice that a transcription agent will be attending a meeting with you.
It is also normal practice across all major video meeting software to have a very blatant warning and notification when the meeting will be recorded. Bots attending without you with the express intent to record everything are not where we are at as a society no matter how helpful that can be.To have a very brief question in an onboarding sequence which enables turning on this behaviour is a great example of violating the Principle of Least Astonishment which will be the focus for the remainder of this post.
Holistic thinking and the Principle of Least Astonishment
I did not expect this behaviour of the bot and, whilst I can appreciate the technical accomplishment, it seems a bizarre level of capability to enable for a first-time user of the software.
A decent percentage of users, when doing any onboarding sequence, are likely to be completing that sequence amongst potentially many other onboarding steps across multiple tools.
For instance to onboard with the consultancy I signed up for email, calendar, chat, video conferencing, timesheeting, wiki, transcription service and more.
The questions in the wizard should work from the set of expectations users are likely to have when beginning to use the software. For instance, when beginning to use a transcription service I might expect to have the option to run the transcription over a recording.
A stretch from there might be the option for a very intentional selection of meetings to bring a bot into - and this scenario may stretch the friendship in terms of the bounds of what a first-time user can expect.
What completing breaks all expectations is that any answer to an onboarding wizard might turn on a bot to join every single meeting you will have, without any meeting by meeting authorisation step, and dutifully take notes in every single one.
It’s the software equivalent of turning up to work one day wearing Google glasses with the recording light flashing all day. It certainly would set the tone of relationships if this was something you did on your first day of work!
Anyway, fortunately, it appears to be a very understanding group of people on this particular occasion but I can imagine in many other situations the consequences could have been more dire.
As software professionals, we have a responsibility to go beyond solutions and act without thinking of the consequences of what we design and put out into the world.
To combat our doing-centric world of software development, I’ve found that higher-level goals which describe the key tenets of what an organisation is trying to achieve are helpful guardrails. If our goal is to provide both a safe and useful capability for our users, functionality which risked the reputation of the users might be reconsidered.
In this case, I am not suggesting the capability should not exist at all (although I am not, not saying that either - I haven’t thought about it enough to have a view). I certainly do think it’s fairly irresponsible for this to have been able to have been enabled upon onboarding.
In a future post I will look at some example organisation goals, which if in place, may have triggered some consideration of the trade-offs the user experience and ultimately may have resulted in a different design.
Have you had an experience with software which violated the Principle of Least Astonishment? Share your experience in the comments.