Lessons from Ignoring Warnings: Titanic and Corporate UX Failures

Lessons from Ignoring Warnings: Titanic and Corporate UX Failures

If people would have known about the Titanic hitting an iceberg and sinking to the bottom of the ocean on her maiden voyage what would they have done differently? Would they have gotten on board? Would the captain have many more men on the lookout for those icy mountains while they were trying to extinguish the fires below deck?

Of course, they would have. That ship hitting an iceberg, even if they were passing through the iceberg-heavy waters of the North Atlantic ocean, is a sheer coincidence. A million to one chance. On her maiden voyage…

But what if someone would have warned them beforehand?

What would you tell the people who built the Titanic? Would you convince them not to sail-out? Because of the danger of icebergs? Would you yell it out on that promenade in Southampton? Chances are you’d be dragged away by the police. Not too dissimilar from what happens in compnies.

***

Three times in companies I have played the UX sage. I have championed UX logic to stakeholders who told me they knew better. Better than user feedback, better than me.

I yelled “research over gut feeling” through the halls of buildings only for it to fall on deaf ears, and for me to get frustrated or dragged out ‘tarred and feathered‘.

This is what Cervantes’ Don Quijote must have looked like to the people of his day as he chased his windmills.

But truth be told, nobody knows the future. Not you, not me, not even the ‘user’. Nobody knows what will happen when it will happen and how it will play out. We are all just combining different sources of information that offer just enough certainty for us to make a decision.

In his farewell speech, Jeff Bezos said that he believes in the power of wandering.

“All of my best decisions in business and in life have been made with heart, intuition, guts… not analysis. If you can make a decision with analysis, you should do so. But it turns out in life that your most important decisions are always made with instinct and intuition, taste, heart.

Maybe the best thing is to let it happen. Have the high-hats at the White Star Line draw their own conclusions when the ‘unsinkable’ sinks? And you will have your plan ready.

Because that is what I think is your best strategy.

If you really believe that something bad will happen if they don’t listen to you then let it happen and be prepared for when that proverbial sh*t hits the fan. Have your plan ready and offer it to the people in charge at the appropriate time.
That may work.

And until then… however difficult, let them figure it out for themselves.

With special thanks to Matthew Syed for writing the book ‘Black Box Thinking’.

User-centered design: principles and practices for better experiences – DRAFT

User-centered design: principles and practices for better experiences – DRAFT

This is the real flow of a User-Centered design process. Mighty pretty isn’t it?

I redesigned this based on a similar one made by Joan Lumanauw (https://www.slideshare.net/JoanLumanauw/ux-lesson-2-user-research – see slide 34).

But what does ‘user-centered’ mean though? To me, it means building your product around the user’s needs. The ‘user’ being the person you are designing the product for so that they can interact with your company and whatever it is that you want them to purchase, download, or leave behind.

It means finding out as much as possible about that customer without being intrusive and without asking them.

Wh

Bridging the gap: balancing agile and UX design without sacrificing quality

Bridging the gap: balancing agile and UX design without sacrificing quality

The Agile/SCRUM and UX design combo

If you have ever been the (only) designer in a team that works with traditional scrum, you know that you got stuck in the sprints sooner or later.

As a designer, you must do research (or outsource it), which takes time to prepare and execute. You are required to make prototypes, which take time to build and test. While you are working on those things, your team cannot move forward. This causes a sticky situation where team members may put pressure on you to finish quickly, or worse, you get sidelined as the team ‘steams’ ahead without you. In both cases, you, the user and the product suffer.

The Agile Manifesto caused this situation. Its 12 principles describe it (https://agilemanifesto.org/principles.html). I won’t read through all of them, but I will show you principle number 4, which goes like this: “Business people and developers must work together daily throughout the project.” The product owner represents ‘Business people,’ and the developers are, well, the developers. No designer is mentioned in any of the twelve principles.

So, bad news, right? Not necessarily.

I have worked on numerous projects. Large and small. New design and redesign. Large teams and small teams. The reality is that each project is different. Each team is different. Every company has its own character. Some are outright feature factories, and others do top-notch user-centred work. The truth is that there is no ‘one size fits all’ when it comes to synchronising design and scrum. Agile was never made for that. But this is what you can do:

1. Work outside of the sprints.
You can work outside of the sprints in a so-called Spike. A spike is a time-boxed period where you can do whatever you need to do without slowing down the rest of the team. When you are done (the time is up), you can send the value you got from your research back to the team.

2. Work two sprints ahead of the rest.
It is easiest to get done. Assuming your sprints are two weeks long, that will give you four weeks to do some user research and put together a solid report with recommendations.

3. Base your information on desk research web analytics and best practices.
Dicey. A poor man’s solution. A catch-22 but still a lot better than gut feelings, which I have also seen happen at prestigious companies. Let the web analyst make a list of the top 250 most visited pages if the website is that large and select from the top 50 or so to understand what people are looking for on the website. Then, get a Hotjar account and observe people walking across the pages. Now you know what people are doing; you only have to figure out the ‘why’. But that’s what user research is for. That is the catch.

Photo: Guillaume de Germain

The rise of data-driven UX: how designers and analysts are reshaping decision-making

The rise of data-driven UX: how designers and analysts are reshaping decision-making

Am I the only one noticing this?

UX researchers and designers, who were once separate from data analysts, are now working together. What great news! When organisations ask for a UX designer now, one of the key requirements is that they be data-driven.

Studies show that data-driven organisations make better strategic decisions, experience higher operational efficiency, improved customer satisfaction, and stronger profit and revenue levels. Recent research even reveals that data-driven organisations are twenty-three times more likely to acquire customers, six times more likely to retain them, and nineteen times more likely to be profitable.

This highlights an important truth: at the intersection of two or more seemingly unrelated disciplines, far more valuable insights emerge than from within a single field alone.

I’ve always been a data-driven designer, though not officially. No one had ever requested that I take usage data into account when conducting research—until now.

What I see happening is a shift away from the reliance on surveys, as we incorporate analytics into our mix of quantitative methods and desk research.

The triangulation of information in user research could look like this:

triangulation

Triangulation isn’t a miracle method; it has its critics. Sure, it increases the likelihood of making informed decisions, but there’s a catch. Surveys have long been criticised for being inaccurate or biased—whether because respondents don’t answer truthfully or because the analysis is flawed. We only need to look at election polls: when are they ever spot-on? And what’s true for surveys also applies to usage data. While there aren’t respondents tailoring their answers to what they think we want to hear, the data is still analysed by humans. Even with machine learning, the process is indirectly biased (take a look at the debate on “math washing”).

Data is math, and math is binary—it proves something right or wrong. There’s no disputing a correct mathematical result. And that’s where things can go wrong.

 Machine learning is math, and its outcomes leave no room for debate or doubt. It presents hard evidence.

This places a lot of power in the hands of data analysts.