The device is not the user – the user is

Flicking through some conference notes this morning I noticed a quote from an event I attended last year. My notes are poor so I cannot attribute the quote. It was the 2016 version of this event. If you are responsible for it, or you know who may be, do let me know and I will attribute accordingly.

Here is what this wise person said about developing for mobile.

Think of a mobile phone as a customer, as a person, not as a device.

Reading this again, it struck me as blindingly obvious yet very helpful – a hallmark of much good advice. Short. Simple. Direct. Thank you.

As with most consideration of UX matters, a quick check of my own behaviour and expectations helps confirm the approach. There is also the simple fact that (most) devices do not work independently. They are the tools of the user. As tools, they are applied to a purpose, to the purpose of the user. Whilst consideration of how the device or the OS and software handles our content is crucial, it does not necessarily support the intent of the user.

I have been hung up on the challenge of rendering and presentation across devices and platforms in the past and have overlooked the user intent as a result. This is not an easy problem to solve. As always (and as I remind myself) the start point must be the user need. What is trying to be done? The device and presentation is, at least, secondary. As machine learning marches on, it is still useful to remember that there are organisms behind the machines.

What is, perhaps, importantly different about our mobile phones is how we personally attach to them. They are part of us and we imbue them with our selves as we use them. This brings a mobile phone interaction closer to us than with other devices. Close enough for us, as service providers, to pay extra care and attention. A dumb response on the phone feels dumber and more brutal than via the laptop browser I reckon. More care needs to be taken.

We also have some more particular needs on our phones. Time may be more pressured or more scarce, at least. We may not be sat attentively waiting to bathe in the wonder of that content. Standing, on the bus, in the supermarket, walking the dog. These are modes that require simplicity as well as brevity. At the very least,  they require choice. These are not device constraints they are the context of the user.

That context can be remarkably well defined on a phone as well. The amount of data available will vary from native to mobile app to mobile browser and from provider to provider. This data can describe a great deal about the user behind the device. To my mind any data we have needs to be handled responsibly. It needs to be put to good use or not gathered at all. The more data we hold form a device and it’s owner/user, the more utility and value we are responsible to offer. That’s what I expect on my phone, anyway.

Design for users not for learners

This thought has been rattling around my mind for some time now. Possibly for years, in fact. It was nudged to the front by a recent debate about the merit of user needs analysis versus learning needs analysis. The LNA acronym is a foundational feature of the L&D world. It is a given. Thus, not having one feels like a high stakes risk.

To be clear, the debate I was part of did not consist of any denial of an LNA. The conversation turned around how helpful one is without broader understanding of user needs. To be even clearer, the context of discussion was the best route to researching a digital learning experience. Knowing what folks need or want to learn is crucial – universal agreement in that one. Also a universally emerging realisation hung in the air that is is not enough.

LNA is necessary but not sufficient. I think this was our conclusion. We need to know what the learning needs are but more than that, we need to know why. What does the learner need the learning for? Learning itself is rarely the goal. It is a route to another destination. Often a requisite route but not the whole deal. Think of the ocean of ‘How to..’ videos on YouTube. They are not there for the sake of learning. They help us get stuff done.

This is where a solid and proper user experience analysis offers a stronger foundation. UX, properly considered, will discover, analyse and define the entire experience that satisfies a user need. Hopefully, only one need. Or, one at a time. Moments of learning and knowledge acquisition will be in there, amongst other elements. Things like, discovery (with it’s own foundation, search), reading, watching, listening, communicating, writing, producing, clicking, swiping, sharing, commenting, saving, to name a few, are also likely to be critical to a helpful experience. These may or may not be learning moments but the learning will not happen without them. The learning will not happen without a well designed and focused whole experience – a problem solved or a need met.

Knowing how these tools and behaviours fit together will start to shape a good UX outcome. What the content is and how it can be used is likely to shape a good learning outcome within that. I think (still thinking see) that learning design (and learning designers) needs to extend its reach and start to take UX design into account. This is what is fashionably called design thinking these days. As with any good fashion, this discipline or method or way of thinking has been around for 20 years or so by now. Only more recently has it been packaged to seem like a trend. I am too old to be fashionable but old enough to recognise the value of this method throughout my (digital) working life.

Sticky is (still) a good thing

The phrase “sticky website” feels like something of a throwback to me. I remember first hearing the phrase and debating it as a product objective when I worked in the search industry. At the time Ask Jeeves (yes, I am that old) was popular and well used but not habitually used. Search was and still is a staple benahviour for online users and a vital tool to making sense of the choices available. In this regard, a lower frequency of use search engine has a weakness to address. And so it was for Jeeves. It was a familiar and high reach product but only a habit for the few. (The search advertising industry did, however, support a very profitable business as a result).

That frequency of use metric was drummed into me early in my career in online services as result. A small increase in frequency could have a dramatic impact on the profitability of the business. Ever since, I have regarded frequency, loyalty and depth of use as critical signs of the health of a product. How often your users return (daily, weekly or monthly), how many of them come back over the period and how much they use your service (whether searches, page views, orders, applications, message or whatever per visit) are vital in assessing how useful you are to them.

We spent quite a deal of time, money and effort at Jeeves in various marketing campaigns to persuade users that the product was the equal of the competitors or, at minimum, worthy of consideration, versus them. The best of these efforts did increase reach and nudge users to gives the Butler a try. Rarely did we retain those users, however. They would try but then return to Google. The proof of the pudding being relevance, speed, accuracy and simplicity. No advertising effort could mask those experiences relative to the engineering power of Mountain View. They did not stick.

That stickiness goal is still crucial, I think and the stickiest services are those that are useful. They reward repeat and frequent use. This is one good test of the “if we build it they will come” model. That may be true (if very unlikely). Will they, though, stay around and come back soon and often enough to return that building effort.

Stickiness equates to utility more than anything else. Be wary of a primary goal to engage users. Being engaged is rarely a primary user need. I suspect that our attempts to engage users often mask the fact that there is a weak primary interest in our offer. Being useful or interesting is much more fertile ground. From that foundation, it will be much easier to be engaging, if engagement is needed at all.




The whole UX and nothing but the UX

Some recent workshop sessions and user (learner?) research with a client have made me wonder about a possible wrinkle on the smooth baize of UX thinking in the corporate world. In the wild public world of product design and delivery, we are free to design our best solution to user challenges and make it available. We do have to offer that product in the messy and compromised digital world we inhabit and fight like crazy to win attention and draw traffic/downloads/sign ups. Other than that struggle we can carve a purposeful proposition and make the most of it. Where similar or related services exist, a distribution deal or conversation might be available to mutual benefit.

In the corporate world, the landscape tends to be filled with larger less well defined features. Often these phenomena (for they are rarely products or tools as a user would recognise them) mark a departmental territory and purpose, rather than a potential problem solved for a user. Often too, they carry the purpose of a system and a process designed for the benefit of the organisation and not pointed at resolving a user need. An LMS, an intranet or a finance system, in its many and varied incarnations, often appear in this form. As a user we have to negotiate them, navigate through them and hope for survival at the other end.

From a users point of view their relationship to your own product may not be clear. The same language, labelling and content may well appear on them.  If you are in the learning game then the boundaries could well be blurred. User guides, comms campaign material, policy documents and the like can rightly be the answer to a “finding something out” question. The product they are available in may not be discernible or of interest to your user. This presents a tricky challenge.

A proper investigation of user epxerience needs to account for the whole experience of a system or product. This needs to include the possible, or likely, confusion of arriving at your carefully crafted content through the confusing boulders around it. That is part of the epxerience of fulfilling a learning need. It is part of the whole user epxerience and should not be ignored.

Lobbying the owners of these other products to change them can be a complex and wearing experience in some organisations. Where it is simple and close at hand, it may still not be a priority for resource or time. Do give it a try though. I doubt that the owners of these services have much genuine UX data to hand or are aware of possible and real confusion. Failing that, stick closely and clearly to what you are about.

One option we always have is to make our own services and products crystal clear in their purpose form the very fast click or swipe. Define that purpose and stick closely to it in all iterations. Even in muddy and ugly surroundings, your users will respect you for the clarity you show them. They will know, quickly and clearly, what to expect.

The mess around our products and content is part of the reality of the UX and it is our responsibility to respond to it, irritating though that may be.


A digital echo of a missing friend

I have paused my work to record a moment of my social media day. It’s one of those moments where technology, data (or the lack of it) and commercial imperatives combine to create an unintended jarring moment.

Over a desk picnic, I was endorsing friends and colleagues on LinkedIn. I am happy to do this and do think it has (modest) value. Faces from the recent and distant past slid across the screen and I clicked or passed on the skills and experience they may or may not have. I like these occasional moments. It encourages me to mentally reconnect with my working past and people I have worked with.

Then a clang and a sigh. The next face to fill the space is long time friend, sometimes colleague and mentor. This is someone who has been instrumental in my understanding of my work, my career and my sense of value. One of those rare and valuable individuals. It is also someone who has recently died.

When I saw his face I experienced two immediately juxtaposed visceral reactions. Firstly, a sad moment. One of those moments of considering that someone has gone. A loss. Then I had a sense of frustration that a whole series of digital identities are out there with little reflection of the recent radical news. It was one of those moments where technology is revealed as a dumb brute. The algorithm turned and produced a really poor piece of data.

Sigh again.

I realise this is a very complex problem to solve It is, by now, an old problem to solve and there are start-ups and projects afoot to tackle our digital legacies. I don’t have an answer. Just a sense of a great deal of progress still to be made for products and services to deal with the most inevitable of needs.


Can stakeholders do UX?

In short…no. Or, not easily. Or…not very well. A stakeholder is not a user. To satisfy a user need you need to focus on the user. By definition, a stakeholder is not a user. They might be able to help but they cannot offer the insight vital to UX success.

In the corporate learning world, stakeholders have a powerful position in most projects. Often they have the most powerful seat at a small table (along with subject matter experts who should not do UX either). Still, they are not users.

Stakeholders are very good at describing what they want users to want. This does not qualify them to define what users actually want, however. Unless they have evidence. Evidence direct from users. Very often they do not.

Before I suffer the slings of accusation about a closed mind, let me expand my thinking. A stakeholder has a vital role in defining a business problem or need. Something that needs to be improved, stopped, or started. Business requirements. These are the stuff of the stakeholder. The business metrics that need to change need to be described and analysed to scope a response. A learning project rarely starts without these inputs. There are enlightened stakeholders with supporting evidence and user insight. This is great and useful grist to the mill of UX testing. It is not the full UX answer though. That must come from users.

Insight on user needs can come from many sources, including: talking to them, surveying them, studying use of products and tools, product usage analysis, social media, feedback links, feedback mail. The significant point (for me) is that it should be unmediated and direct to the product owner. Interpretation and response to user data is what product owners are for. The best of the can translate this into stakeholder friendly stories and evidence.

Last week, during a UX workshop I was facilitating, we talked about “the head office bubble”. A central learning team, talking to fellow head office stakeholders about how best to design a digital learning experience is a familiar scene. Add some more corporate subject matter experts and an elegant, self-affirming bubble is easy to create. We are all hard-working and well-meaning but with no user voice it is not a full conversation.

UI is not UX

A quick note to reflect on user experience – that most illusive of goals. A good user experience, that is. Bad ones are falling from the skies.

When I was on the buyer side of the technology divide, a customer of the technology vendors, I was often told that the user experience of a given system was paramount. I was told that the latest release had a number of design improvements to help users use the system. What these comments invariably referred to were cosmetic design changes, often to the home page alone, of systems designed to manage a process. (I suspect that account directors could tick off an action point on their objectives for the year and move on).

The burden on the user was the same. The process and action required by the user was the same. The start point had been tidied up a little. Often w white background was introduced. Some nicer graphic and typographic touches and some layouts to make it look modern. This is the estate agents trick of photographing the house on a sunny day with no cars parked outside.

A god user interface (UI) is vital to a good user experience. It is a necessary but not a sufficient condition. A good UI alone will not guarantee a happy user. A happy user is the result of the entire experience working for them and supporting them to their goal. If it looks good, great. If not but it still works well than, OK.

So, if your vendor ventures to describe important design changes…beware! Remember to visit the house in the evening too and when the agent is not there. Also, take a few users with you. They are the ones who have to live there.