A very useful contribution to the debate surrounding the usefulness/harmfulness of net promoter score. Jeff Sauro transcends the often polemical nature of the debate, by analysing actual research on the effectiveness of net promoter score.
The news still isn’t all that great for proponents of net promoter score. But at the same time, it’s not quite as bad as its detractors make out.
Kudos to Jeff Sauro for doing some actual research on this.
I’m always in two minds about whether people should use work-based techniques on personal problems. I have heard of people using Trello boards at home to organise tasks, which sounds as nightmarish as it sounds sensible. I’ve even heard of people running scrum-style weekly planning meetings with their family, which definitely sounds overboard to me.
But I do like the look of some of the ideas here. For instance, I’m keen to map out out my life in weeks.
And I already know that affinity mapping can work great at home and for other stuff.
When we did the MoRun in November, Lauren and I made an affinity map to decide which of two runs to enter. My gut feeling told me another run would be better. But writing down all the pros and cons of each race, and grouping them, made it clear that my gut feeling was actually wide of the mark.
An enjoyable and informative history of user experience. Some familiar themes, but not entirely your standard take. A reminder that people have been doing something like user-centred design for longer than we sometimes think.
…UX is not really a new thing. It might seem new to your organisation and its design process, but in fact it’s been emerging since before the dawn of the internet, back in the 80s, and people have been looking to solve similar problems for almost 140 years.
Or, more accurately, stopping it being weird. This refers to the problem that most psychology research is conducted on people that are western, educated, industrialized, rich and democratic.
Tim Kadlec considers the implication this has on our understanding of how people use the web.
We’ve known for a while that the worldwide web was becoming increasingly that: worldwide. As we try to reach people in different parts of the globe with very different daily realities, we have to be willing to rethink our assumptions. We have to be willing to revisit our research and findings with fresh eyes so that we can see what holds true, what doesn’t, and where.
McKinsey report on how to engage employees.
People who find meaning at work are happier, more productive, and more engaged. Four practical interventions can help make the search more likely to succeed.
I am struck by how two of the four interventions listed are fundamentally about understanding your users better.
Talk with employees about who their customers are, and encourage each employee to connect with one.
Build regular, face-to-face interactions with customers into existing processes, stimulating employees to learn who is most affected by their work.
Help people grasp the impact of their work
Invite customers who have had the best—and worst—experiences with your products to talk with employees in person so your team can see how their work affects customers.
Another reason why user experience is worth it.
More on the need for (UX) designers to consider ethics in everything they do.
I urge you to consider your own design priorities and choices in the same way that responsible physicians do when they take the Hippocratic Oath, saying “first, do no harm.” So, I ask the UX community at large: what is an equivalent code of ethics for our discipline?
On the tendency of security approaches to rely on somehow educating users on this complex problem.
I’ve read dozens of studies about how to get people to pay attention to security warnings. We can tweak their wording, highlight them in red, and jiggle them on the screen, but nothing works because users know the warnings are invariably meaningless. They don’t see “the certificate has expired; are you sure you want to go to this webpage?” They see, “I’m an annoying message preventing you from reading a webpage. Click here to get rid of me.”…
We must stop trying to fix the user to achieve security. We’ll never get there, and research toward those goals just obscures the real problems. Usable security does not mean “getting people to do what we want.” It means creating security that works, given (or despite) what people do.
The same could be said for usability of any kind — but it seems especially vital in this case.
A good list of don’ts when you’re trying to set up an effective user experience function.
In particular, the pitfalls of “cargo cult usability” could do with being more widely understood. But I also enjoyed this point about being too insular.
Newly formed UX teams have a tendency to quickly turn inwards and focus heavily on their own practices, tools and methods: heads down, working in a vacuum, doing great work that doesn’t actually influence anything. As a result, we hear frustrated stakeholders say things like: “I don’t involve the UX team because they always seem too busy”. We’ve even heard UX team members themselves complain that, “We’re so busy and so mired in the day-to-day that we don’t have time to work alongside the development team.”
This reminds me of the (hilarious but true) story of the Staffordshire UK bus company. In 1976 it was reported that the buses on the Hanley to Bagnall route were not stopping to pick up passengers. People complained that buses would drive right by long lines of waiting passengers. The complaints prompted Councillor Arthur Cholerton to make transport history by stating that if the buses stopped to pick up passengers it would disrupt the timetable!
Jared Spool tells the story of a bookkeeper who became frustrated using Google Sheets because it didn’t have a double underline function.
To keep [usability] testing simple and under control, we often define the outcomes we want. For example, in testing Google Spreadsheet, we might have a profit and loss statement we’d want participants to make. To make it clear what we were expecting, we might show the final report we’d like them to make.
Since we never thought about the importance of double underlines, our sample final report wouldn’t have them. Our participant, wanting to do what we’ve asked of her, would unlikely add double underlines in. Our bias is reflected in the test results and we won’t uncover the missing expectation.
He suggests interview-based task design as a way of finding these missing expectations. Start a session with an interview to discover these expectations. Then construct a usability test task based on that.
I recently ran hybrid interviews and usability tests. That was for expediency. I didn’t base tasks on what I’d found in the interview. But it’s good to know I wasn’t completely barking up the wrong tree. I plan to use this approach in future.
A really enjoyable piece on the history of smart home devices, and how Google Home and Alexa aren’t such new ideas. The video is well worth a watch, particularly because it demonstrates 1970s technology from Pico Electronics in Glenrothes! It’s amazing to see it work so well.
The point of Thomas Baekdal’s piece here is to demonstrate how trends aren’t new, but they emerge over a long period of time. It reminds me a bit of Gartner’s hype cycle, and a recent Nile webinar about how to employ foresight to understand emerging trends. Not to forget the Nielsen Norman Group research demonstrating that intelligent assistants still have horrible usability problems.
Another call on designers to think more widely when they are working on digital products. Khoi Vinh saw a Nielsen Norman Group report on best practice on websites aimed at children — but he felt the report focused too narrowly on usability.
I don’t dispute the findings at all. But it’s disturbing that the report focuses exclusively on usability recommendations, on the executional aspect of creating digital products for kids. There’s not a single line, much less a section, that cares to examine how design impacts the well-being of children…
We’re moving past the stage in the evolution of our craft when we can safely consider its practice to be neutral, to be without inherent virtue or without inherent vice. At some point, making it easier and easier to pull the handle on a slot machine reflects on the intentions of the designer of that experience.
This is a very strong piece by Erika Hall, raising some seriously good points and questions about where user experience design is, and where it needs to go. It is well worth reading the full piece, and me pulling out a quote cannot do this justice. But here are some selections I particularly liked:
If good design entailed good business, women’s clothes would come in a wide range of sizes with usable pockets and our social media feeds would unfurl in reverse chronological order with an unremarkable absence of Nazis.
While most of the designers I know are far from objectivists, design as it is currently practiced is tantamount to Ayn Rand’s radical selfishness. We design for the experience of a single user at a time and expect that the collective experience, and the collective impact, will take care of itself.
It’s much more pleasant for designers to talk about empathy in one room and MBAs to talk about profits in the other and have marketers in the middle like an injectable filler.
This is exactly the sort of article we need to be seeing more of.
Gerry McGovern tells the story of trying to persuade a digital team of what they needed to fix.
“It would be nice to fix these problems,” one person said. “But the team needs also to be able to do exciting things. We need to be able to innovate.”
Unfortunately, people at work often place too much emphasis on their own enjoyment. But our work only has meaning if it is providing value to someone.
Work shouldn’t be exciting. There’s a job to do.
An excellent article from Jared Spool on the difference between proactive design and reactive design — and the importance of making your work more proactive.
Reactive UX design is just what it sounds like: reacting to a problem in the moment. “Oh, can you fix this?” “Help! Users are complaining this is too hard! What can we do?”
Without also having proactive UX design efforts, the design team is only fixing problems caused by decisions the product team has already made.
Interestingly, he also makes the point that it is easy for design teams to get sucked into doing reactive design, because it becomes comfortable for teams to do:
They like the wireframes and usability tests.
They believe this is what design work looks like. They believe design work always happens at the end of the process.
How do you stop yourself, as a user researcher, biasing the results? An important topic for user researchers to consider. (It’s also an excellent excuse to re-tell the story about Clever Hans, the horse who everyone thought could count, until they realised he was simply reacting to subtle, unintentional cues from his trainer.)
I recently undertook some usability testing, where I was asking people to complete tasks that I didn’t know how to complete myself. This meant I was less likely to bias the participant. But it was a strange experience for me, and it made me less certain about how to conduct the test.
The crusade against PDFs has been one of my constant hobby-horses over the years. It has also led to some of my toughest battles in my work.
Users hate PDFs, because it makes it harder to use content. But content owners love PDFs, because it makes it easier for them to create content. It is the ultimate in user-hostility. “Who cares about the users? PDFs make my job easier for me.”
So it was great to see two trusted sources reiterate the importance of getting rid of PDFs, within days of each other.
This has also reminded me of a small project I promised I would do, but never got around to — to publish my dissertation as an HTML webpage. The idea was to demonstrate how versatile HTML is, even for things like technical or academic writing. Maybe I’ll return to that this autumn.
I really like this idea of crowdsourcing, and making available to the community, a set of readability guidelines based on evidence.
I see many content designers spending time talking – arguing – about points of style when often accessibility and usability show what we should do.
What if there was one place where we, as a community, shared knowledge and created a style guide that was accessible, usable and – if we wanted – evidenced?
We could then spend time on the things that matter more to our organisations.
Why are digital assistants almost always given female-sounding voices?
While stakeholder preference might sound like a perfectly good reason at first, it hides an ugly reality. To make this clear, let me tell you a story about a talented young woman who I managed. She designed voice features for our clients’ prototypes. Although she created a voice that was meant to be genderless, the client kept referring to the voice in feminine terms. In other words, he heard what he expected to hear.
…BMW learned the hard way that female voices aren’t always the right route to take when German drivers of its 5 Series vehicles complained about “taking directions from a woman.” Yes, really.
Results from a study of users of Pandora has quantified the effect of shoving adverts in users’ faces. As part of the experiment, a section of users were served fewer ads than normal, and another section were served more ads than normal.
…after 1.5 years of being exposed to the experimental conditions, people did use the service more, the fewer ads they were served. At the end of the experiment:
- The low-ad group listened for 1.7% more hours weekly than the control group.
- The high-ad group listened for 2.8% fewer hours weekly than the control group.
I got out of bed and, in roughly an hour, hammered out a kind of primer on UX/UI design, which I’m publishing below. It’s a very unformed, rambly screed that I won’t pretend is at all definitive or even fully accurate. In fact it’s still basically a first draft; I literally typed it out in bullet point form, as shown below, a trick I used in order to absolve myself of the responsibility of writing a fully articulated essay.
Despite Khoi Vinh’s self-deprecation here, I think this is an excellent attempt at explaining what design is. For those who are frustrated about having to explain that design isn’t (just) about making things pretty, this blog post provides an excellent introduction to why — as well as helpfully explaining why this perception exists in the first place. Not bad for an hour’s work.
The University of Edinburgh Website and Communications team has recently been heavily involved in a pilot project to improve the journey of prospective online learning students, from investigation to offer. Read about our user research approach and how we ensured project outputs met the needs of users.
Chris How’s tips on doing better interviews. This is essentially a text version of his session at UX Scotland, which I wrote about on the University of Edinburgh Website Programme blog.
Some more follow-up to the UX Scotland conference, which I have published over on the University of Edinburgh Website Programme blog.
I set myself the challenge of writing a summary of each session I attended at UX Scotland, as a way of forming my own thoughts on each topic, and to make sure to follow up on everything I wanted to.
This resulting blog post is long. But I am sharing this on the basis that others might find it useful and seek to learn more about these topics, as I did.
My colleagues and I have gathered together our thoughts on our highlights of the UX Scotland conference.
I am also in the process of writing up some further thoughts on most of the other sessions, which I will publish to the University Website Programme blog soon.
But in the meantime, find out about my top three sessions, and the things I intend to put into practice as a result of attending the conference.
Interesting on the similarities and differences between user experience and service design.
Service Designers generally approach digital as one of a number of interconnected touch points. They will usually figure out how all these touch-points work together as a cohesive ecosystem, before handing the design of the specific touch points over to experts.
UX Designers usually approach the problem from the other direction. They start with the core digital experience before exploring the connective tissue that joins their touch-points together. Service Designers tend to have a broader but shallower focus, while UX designers go narrower but deeper.
Excellent piece by Wojtek Kutyla on why UX needs to get out of its comfort zone, and an excessive focus on technology — and the temptation to make binary declarations.
We are all reasonable creatures and we know how to seek rationale when we’re dealing with daily tasks. If we’re hungry, we’ll ask ourselves: “What do I want to eat? Eggs? Avocado? Or a burger?”. If we’re planning to buy a new car, we’ll consider it carefully, basing our ultimate choice on how functional the vehicle is and whether we can afford it.
Yet, when faced with a design problem in a professional setting we’d often go for a solution that does nothing else but fulfils a set of requirements based on assumed values communicated by stakeholders. All too seldom we’re doubting their choices and ask “what’s the rationale — where did this come from?”. Perhaps we should start doing that?
Most customer relationships don’t stumble because something went wrong. Your best customers know that mistakes happen.
It’s what happens next that can cripple the relationship.
I would be tempted to agree with Seth Godin here. But it actually reminded me of the recent incident with Ghostery.
Ghostery is a browser plugin that is supposed to protect your privacy online. But on Friday, when attempting to email its users about GDPR, they accidentally leaked the email addresses of hundreds of their users by CCing them into the email — the most basic and facepalm-worthy data breach of all.
I once briefly used Ghostery. But I uninstalled it after I found it kept on crashing my browser.
My response in this case was to find it deeply ironic that Ghostery should fail at the one thing they were meant to do. It’s true “you had one job” stuff, this. So I deleted my Ghostery account entirely.
Perhaps if my prior experience with Ghostery had been more positive, I would have been more lenient.
Enterprise software is notoriously bad — and that’s bad for business.
A poor user interface sends a message to employees that their time and commitment have little value, and that — just as my engineer colleague believed — the problem is their own fault. Then leaders wonder why their people don’t innovate or embrace change…
There’s a lot of good stuff here, so I had some trouble picking just one thing to highlight. Read on to see why actually watching people try to use your design is vital.
This is the final blog post in my short series about the user research I led on for the API Service at the University of Edinburgh.
This post covers the second half of the research, where we brought focus to the detailed picture developed in the first phase, and began to prioritise the issues to help the API Service team direct their ongoing work.
We know that poor usability can lead to disastrous consequences. Think to the recent case of the accidental missile alert in Hawaii.
This is a more rigorous, academic investigation into the negative consequences of poor usability in electronic health records. The study even suggests that bad usability may have caused deaths.
Some 557 (0.03 percent) reports had “language explicitly suggesting EHR usability contributed to possible patient harm,” and among those, 80 caused temporary harm, seven may have caused permanent harm and two may have been fatal.
This article is a bit of a sales pitch, but I enjoyed this research into how intuitive the Dewey Decimal Classification is.
I have recently been involved in a project with the University of Edinburgh UX Service to conduct user research for the API Service.
In one of the workshops we ran, we wanted participants to work with empathy maps to give us an insight into their experiences.
This post on the University Website Programme blog outlines how I introduced workshop participants to the concept of empathy maps, with an example around my own experience of buying milk.
Buying milk is a simple task that most of us carry out on a regular basis. But this example showed how using an empathy map can reveal a surprising amount of detail about the behaviours and feelings someone goes through when completing a task.
An exploration of the risks surrounding undertaking user-centred design. For me, the lesson is to put the same sort of effort into designing your research and your interactions with your users as you would into the product your research is for.
I have been leading some user research for a project at the University of Edinburgh to develop API Service. This post on the University Website Programme blog outlines the steps we went through in the first phase of the research. This included interviewing developers, running workshops, and developing personas and journey maps.
This has been a successful and rewarding project. It has been particularly interesting for me to do some UX work that wasn’t necessarily to do with a website. There will be a couple more blog posts about it to come.
Philip Hunt on how bad Twitter’s user interface has become.
When Twitter started out, it was such a simple concept. Just straightforward status updates; no real interaction. (When I joined Twitter, @ replies didn’t even exist yet.)
Over time it has added more and more features — replies, retweets, quote retweets, threads. Seemingly it has not been thought through properly.
If you spend a lot of time on Twitter, you catch onto these user interface quirks pretty quickly. But new users must find it so intimidating. So it is little wonder Twitter struggles to attract and retain new users.
A belter of an article on why it is difficult to persuade people to undertake user research:
Research is simply asking questions about how the world works. And asking questions about how the world works threatens established authority.
I especially love the section “Bad research is good theatre”:
Focus groups look like how people imagine research looks. In a special room, controlled. But just because you have a 2-way mirror doesn’t make it anything more than a tea party. Actual ethnographic research happens where the people you’re studying do the thing you want to learn about. It’s often unsatisfyingly messy and low tech.
Fake research makes people money, and it makes people in charge feel good, but it’s useless and potentially dangerous to a design project.
So how do you get decision-makers to see the light? Understand them as people, like a good UXer should!