The Entropy of Intent

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
  • 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.

In (further) praise of personas

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.

UX & The Weight of Expectation

I’ve been thinking increasingly about the importance of user expectations in planing an effective user experience.

The greatest asset we have in going to meet the challenge of the user’s mental model is simply knowing it exists in the first place. A huge part of user research concerns itself with the needs of the user, but it’s important not to let this spill over into a hapless quest for what the user wants.

Don’t Give Me What I Want

User requirements are one of the basic tenets of user experience design. We know however that if the user got everything they wanted then we would almost certainly have a very messy interface to contend with, one overflowing with superfluous functionality and options. In short, what the user wants is often at odds with that they truly need.

This points to a very particular approach to user research.

In my own experience when the opportunity exists to talk to users in person the line of questioning should monitor the distinction between wants and needs very carefully. When talking through a particular system with a user group, the type of question I try to avoid is “what do you want to see on this page?”.

Love Me, Love My User

A quick aside here – people are amazing. Watching them in action on a website or an application is possibly the single greatest education a UI designer can have. They won’t always do what you expect them to do or what you want them to do. They will however do what they feel they need to do in order to achieve a goal. And that, of course, can be endlessly frustrating for designers.

In research as in life, framing a question can be as important as the question itself.

An open question such as “what would you like to see on this page?” (as a crude example) will garner very different responses from “what would you expect to see on the next page?”. The former can lead to some serous flights of fancy, where the entire web as we know it has to be re-engineered to match the heady goals set for what the site has to provide. Expectations are so much more important than perceived need.

Let Me Down Easy

When engaging with stakeholders, the same types of enquiry can help to keep a sense of promise to a minimum. “What do you want…” infers a degree of promise about what will be delivered. So much of stakeholder engagement is about inclusivity, giving people a platform to make contributions to a process that values their input. To over-promise in these situations is to mislead participants as to what will be done with their feedback. “What do you expect?” carries with it less of an overt sense of promise, and more one of discussion.

What’s New, Pussycat?

And what, you may ask, of innovation? If we only deliver in line with expectations, how does anything new enter the mix? Clearly, delivering “to expectations” is a lowly objective for any project. However, delivering what users expect is an imperative. The point is that we are not constantly seeking to reimagine the web. The time for reinventing conventions is gone. Lord knows we saw enough “innovative” – some might say wacky – attempts at elements such as navigation systems pre-2002. We have been left with a web that, generally speaking, conforms. And there is no shame in that. Most of our consumer products do the same; even the iPod delivered innovation in a very familiar package, building on the form factor that products such as the Walkman had created. Everyday innovation almost always arrives in tandem with the familiar. And delivering based on expectations does not preclude the element of delight.

Conclusion

Users do not like the unanticipated, but they will react positively to a system that simplifies a task. Strive for innovation of course, but be careful how you define it. And make no mistake – managing expectations is possibly the single biggest task faced by UX practitioners. As techniques such as responsive design gain traction, the issue of expectations grows ever more complex. In user research, assume nothing… and expect the unexpected.

Adapting to responsive

Responsive web design has reached the grand old age of two and remains the single most important shift in design and development for the web since the advent of CSS.

Broken record

I have written previously about the dangers of dogmatic approaches, emphasising that we should move in the direction of responsive design increasingly and methodically. RWD is not however a be-all-and-end-all. It is not a magic bullet for multi-device deployment. Responsive images remain a challenge, advertising doesn’t sit well with a fluid layout and, regardless of how simple the approach is pitched as, the creation of a credible responsive solution takes significantly greater time than a single-resolution site.

Here comes the future

And yet it should remain the goal. We are clearly impelled to move to responsive as an industry standard. Some of the loftier commentary recommending multiple versions of websites appears frighteningly blinkered in its naivety. We are headed only one way in the medium to long term.

One foot in front of the other

However an all or nothing stance on RWD is an equally retrograde move. Speaking as a (ahem) “seasoned” designer, shifting to an adaptive approach has been an essential stepping stone in understanding RWD as a whole. Is it better to learn responsive as standard? Of course. For any new designers starting out: take this route and don’t look back. For those who have been around the block a few times, coming to terms with full responsive as a new way of approaching projects is to put it simply, difficult. I have yet to meet a designer in industry for any amount of time with a different view.

Money, money, money

I work in a commercial organisation and to remain viable in a commercial environment, we need to deliver effective outputs that surpass expectations – within a budget. Recently we’ve committed to producing adaptive sites as standard and deviating from this only where individual projects demand it. Not committing to fully responsive for the moment, our rationale is that doing something is better than doing nothing; not letting the perfect be the enemy of the good.

It’s not what you do..?

As I have said before, we’re getting there and should enjoy the journey. But whether it is acknowledged or not (and it isn’t) there is a purist agenda at work in some corners of the industry. Challenge some of the more vociferous opinions and there is usually a conciliatory climb down, but the inference remains: if you’re not producing fully responsive work, you’re falling short. My problem with this is simply that it places technique over results. The means do not justify the end. There are a number of responsive sites featuring what I would regard as unacceptable design anomalies at certain sizes, and they should not be given a pardon simply because of the way they have been constructed. An adaptive approach may yet be more condusive to better overall design on certain projects.

Conclusion

To repeat myself (again), why create divisions where none exist. We’re all on our way. Those who fail to come to terms with the changing landscape in web access are condemning themselves to history. For those who are moving forward, there is more than one way to do so.

A sense of completion

Throughout a career primarily as a visual designer, I’ve always struggled with the judgement of when a piece of work is “done”. In graphic design, the urge to continue adding, embellishing is almost overwhelming. Maturity and of course experience influence better decision-making, but inevitably you find yourself mentally revisiting each project many times in the months after it’s supposedly ‘finished’, thinking of better choices you could have made, better directions you could have taken, better refinements you could have insisted on.

The craftsman’s eye

I often find myself looking at things that my dad made during his life, his joiner’s skills manifesting themselves in seemingly flawless dovetail joints and perfect angles, and outputs consistently fit for purpose.

The end is not nigh

Producing work that is deployed in a digital context brings with it a frustration, a yearning for a sense of completion where you know that something is simply done. This is something that has dogged me throughout my working life to date, whether I realised it or not. The quest for completion led me to acquire technical skills I never believed I would want or need, in what I now believe was the hope that they would bring me a clearer understanding of “finished”.

In short: I’m older now

What this drive for completion has meant for me is a quest for metrics, for data – measurable factors. In joinery, a glance through seasoned eyes can likely offer all the reassurance required to know it’s a job well done. Call it a search for meaning if you will, but moving deeper into UX thinking has brought me closer to the answer; knowing the right questions were asked, the right conclusions were reached and the right recommendations were made is as close as I believe I’m going to get. That sense of satisfaction is what drives me now – a far cry from the “cool” factor that motivated the younger me, an empty quest to mimic the latest ego-centric design trends.

So…

And yet, no matter what nostalgic gloss I might put on it, I am sure Dad would have been able to see in his work where improvements could have been made. It is both the blessing and the curse of the craftsman – the belief that the next project will be closer to elusive perfection that never comes.