I’ve been blown away by the reaction to this annotated Dunning-Kruger graph. Simple thoughts that resonate with a lot of people. I’ve learned a lot just through posting this.
Around 15 years ago Flash technology was in the ascendancy. One of the odd conventions to emerge at the time was the ‘Flash intro’. Very often, to build your anticipation for the website awaiting you, you would be entertained with what was essentially an opening title sequence. And if you were really unlucky, on the other side of it was a website fully rendered in Flash.
What you wanted was content; what you got was an extended journey through a designer’s ego trip (and yes I should know, I was one of those designers). The basic premise of a Flash-built website was that tricking out the interface would make for a better user experience. That assumption turned out to be wrong.
With Siri, Alexa et al entering our lives, our interfaces now have personalities. If a digital misunderstands our requests we are likely to learn about it through a witty quip. TV ads featuring virtual assistants often make a particular show of droll one-liners emanating from the device.
But as Neilsen Norman Group research shows, voice interfaces are falling far short of user expectations. It seems that priorities need to be reassessed.
A little less conversation
As part of a project last year I began designing for command line interface. With no previous experience, a terminal window or console can be a daunting place. Initially I was puzzled why user prompts and feedback in this world were so clinical and abrupt. Why would command line users not want to be addressed in a more human fashion? The answer lies in task efficiency.
Command line interface evolved from single-line dialogue between two human teleprinter operators. Over time, one end of the human-human dialogue became a computer, and the conventions remained. These interfaces provide users a more efficient method of performing tasks. In short, command line users are just like the rest of us: that is, trying to perform a lot of tasks in as short a time as possible, without surplus dialogue or clutter getting in the way.
This method of working is totally in keeping with our tendency towards ever more concise communication. Email is on the wane due to the long, unwieldy threads it encourages. The rise of chat apps such as Slack is due in large part to the tendency towards more concise messages. We’re making less mobile calls, opting instead for text messages using abbreviations, acronyms and emojis.
Many rivers to cross
As designers we are not always trying to mimic a conversation. We are creating an exchange which delivers for the user as efficiently as possible. To re-cast all human-computer interactions as conversations is to misunderstand our relationship with machines and devices.
The obstacles to success with voice UI are many. Users need to think more than once about the commands they give. They are required to speak in a manner that often isn’t natural for them. Even relatively simple queries may need to be broken down into smaller questions before reaching anything like the right answers.
When barriers are placed between a user and the outcomes they want the end result is predictable: they will simply opt out. A report from The Information suggests that only 2% of Alexa speakers have been used to make a purchase from Amazon in 2018. Additionally, 90% of the people who try to make a purchase through Alexa don’t try again.
We are still some distance away from the dream that voice UI promised. Perhaps this is voice’s Flash period, where the user needs to work hard to access the content they want. And I’m willing to bet that most frustrated users would be willing to trade every ounce of their virtual assistant’s sassy responses for just a little more efficiency.
The fact is that voice UI is still pretty hard work, no matter how hard Siri or Alexa try to entertain us.
With the publication of his article ‘A Mathematical Theory of Information’ in 1948, a visionary mathematician and engineer named Claude Shannon all but established information theory, outlining in his paper the building blocks of digital communications.
His work introduced a contextual definition of ‘entropy’, addressing the reliability of data transfer, the conveyance of information from a source to a receiver. If ‘Shannon entropy’ was low, then the predictability of the information content was said to be high. Shannon has been credited with laying foundations that ultimately led to the creation of the world wide web itself.
“The fundamental problem of communication,” Shannon put forward in his publication, “is that of reproducing at one point, either exactly or approximately, a message selected at another point”. He was – and is – of course absolutely right.
However the specific challenge that Shannon was referring to was one of technology, and the need for purity of signal and removal of distortion caused by interference such as compression of data. The irony is that, in a web that is a legacy of the work of pioneers like Shannon, information entropy is less likely to be as a result of technological factors, and more a simple failing of human communication.
To put it more succinctly – it doesn’t matter how perfect data transfer is if the data itself is wrong.
In this post from last month, (echoing this piece from earlier in the year) Jeremy Keith opines that the web has drifted away from its original vision. It is lacking, states Keith, “because we shaped it that way, either through our own actions or inactions”.
A deterioration of vision or purpose due to human-related factors – the entropy of intent.
This same decay can manifest itself at a granular level in design and development projects; a deterioration of what was originally desired, intended or agreed, dissipated across meetings, through processes, sign-offs and the myriad communications that take place between various parties as a project progresses.
The idea of ‘entropy of intent’ is not referring to, for instance, constraints being applied to features or narrowing the scope of the project (both of which can actually be hugely positive moves). It may however manifest itself in other seemingly innocuous ways such as: poor copywriting; ineffective navigation and wayfinding; needless functionality. Anything in fact which distorts the communication of ideas and concepts between the source (the project team) to the receiver (end users).
Protecting intent doesn’t come under project management; it isn’t the client’s responsibility, nor specifically that of the design or development teams. Responsibility exists both within and outside the traditional project roles. More than anyone though, I believe it falls to the UX function to keep a project true to its original purpose, which will generally be more all-embracing than the minutiae of conversions, KPIs and metrics.
Without question it takes a huge amount of effort to even articulate the central intent for a project never mind maintain focus on it. One key contribution that UX design can effectively make is firstly to identify and agree core guiding principles, and then to keep those principles in play right through to delivery. But it is a monumental challenge.
I’ve been involved in projects over the years where mere delivery was celebrated. Something that began with high aspirations and apparently clear goals became something to simply get finished and tick off a list. This is not necessarily anyone’s fault. What it means is that somewhere along the way the original vision for the project has become secondary to other priorities – sometimes this may be just getting it ‘out the door’.
Help is at hand, unsurprisingly from a fantastic and supportive UX and design community:
- Any project comes with a brief, albeit one that might be vague or unfocused. Creating a vision though is just as important. This article from UX Magazine offers some excellent advice on creating an effective, singular vision
- Dan Lockton’s excellent Designing with Intent toolkit can assist in making conscious decisions about purpose
- It may be the user’s intent, rather than the project’s, that requires clarification. UX Matters published The Importance of Knowing User Intent some time ago, documenting how this can be identified, which in turn can feed into the vision for the project as a whole
- Dan Klyn has spoken on defining what “good” means on a project and outlined the use of Performance Continuums. I highly recommend his talk, which can be listened to on the UX Thursday website, with accompanying slides available on Slideshare
No project will ever embody perfection. But neither should every project fall prey to a lack of stamina or will to create something if not great, then truly effective for the organisation funding it and the people who will ultimately make use of it. Following the critical early stages of a project, when it is often easy to feel that the difficult decisions have been made and all the big battles already won, the war of attrition against entropy is only beginning.
Peer networking in the design community is thankfully not the rarity it used to be. Where there were onceinfrequent events based around an occasional high-brow lecture or overly self-conscious ‘networking opportunity’ (ugh), thanks to any number of driven and enthusiastic individuals we now have conferences, unconventions, informal meet-ups and increasingly relevant and compelling talks.
Industry peers aside though, our professional communications take place with a number of other key groups: colleagues, clients and end users. It’s worth considering how we handle these conversations.
A couple of years back the excellent UX Bookclub Belfast covered ‘How to Use Your Eyes’ by James Elkins. Each chapter delivered a brief but compelling insight into the expertise of others. By deconstructing (amongst other things) a culvert, an oil painting and the Periodic Table, the book revealed hidden mechanics and meanings, inspiring admiration for those whose contributions you might not otherwise consider.
Had there been a chapter devoted to the makeup of a graphic user interface or how a web browser renders HTML, no doubt most in the web design industry could have articulated something to inspire similar, admiring reactions from readers outside our sphere of activity. Indeed, expertise is (or should be) the minimum price of entry into the increasingly crowded Service Industry Club. A key question to consider then, is: how do we convey our knowledge to those we most need to engage with?
It just works
Almost everything we interact with or consume is the product of others’ technical mastery; their input is largely invisible, allowing us to go about our day without having to consider theories, systems or production processes. We care about these things, only in the sense that they just work without insight on our part.
The same goes for most experts we come into contact with. Be it a doctor or a car mechanic, we appreciate it when these people frame problems and solutions in the simplest possible simple terms, revealing more detail only when we request it.
In UX design, and I’d suggest pretty much every other design discipline, expertise should manifest itself in simplicity. Or to rephrase that, the science we incorporate into what we produce should be invisible to a non-expert; and we should be able to communicate our expertise while remaining intelligible to the listener.
Too often we trip over ourselves to prove our competence rather than communicate it effectively. In many ways our ability blinds us. We should not berate the client for, as designers are so fond of saying, “not getting it”. Others do not see as we do. We are the ones who have the responsibility of making sure clients “get it”… whatever “it” may be.
So perhaps the truest test of our competence is how simply we can share it. When we discuss a project’s challenges and potential solutions with a client, make it simple to understand. Communicate like a true expert.
I felt this piece from UX Matters – Are Personas Still Relevant to UX Strategy? – and the string of great comments that follow it warranted a post here, based on personal experience forged in rigidly commercial environments.
To my mind, personas introduce a much needed human aspect into what can otherwise be a soulless, technical process that leads to an anodyne web site, app or web strategy. Rarely is the case for designing for people put as strongly as during a persona building exercise.
Personas also help to communicate strategy to otherwise sceptical stakeholders. When they are executed correctly, they ring true. They transform the “users” we so often refer to in design industry-speak into the clients and customers that your client recognises; they will know these people.
When it comes to crucial decisions of prioritisation, creating a hierarchy of needs for functionality can be greatly assisted by basing these decisions on the most important customers as a first step, rather than working with an exhaustive list of features or content.
The final, crowning glory of personas is their potential to bestow a lasting legacy. Beyond the life of an interface project, the organisation – your client – now has a valuable insight of their public. They will not be marketing personas (a very different proposition) and done badly, they are nothing but caricatures. But they can provide an enduring reference point for future communications. They inform your client about the people they currently, or aspire to connect with and how they prefer to interact. Above all they can imbue an organisation with the capacity for empathy.
Done right, you will change you client’s perspective for the better, giving them wisdom that they simply did not have before. They will know it and will thank you for it.