If you want a quick summary of my “Why We Fail” book in the form of two AI-generated voices discussing the seven main types of customer experience failure, then this podcast episode is for you.
-
Don’t Say You Weren’t Warned
I asked Google’s AI what it thinks Google will be in 10 years, and the answer was HAL 9000, but blue.
-
Star Trek Is Now A Design Lesson
This recent Klarna story is fascinating:
The fintech firm Klarna is severing its relationships with two of the biggest enterprise software providers in favor of automating its services with AI. And the company says it could potentially eliminate more.
Klarna co-founder and CEO Sebastian Siemiatkowski recently explained the rationale in a conference call, the financial outlet Seeking Alpha reported. Klarna is no longer using Salesforce, a platform that aggregates and packages sales and marketing data for businesses. The company has also removed the HR and hiring platform Workday from its tech stack
The skepticism in the article feels valid. But let’s pretend for a moment there’s something here. How might they “shut down Salesforce”? I imagine they could move their their data elsewhere, sick an LLM on it, and then query it. “Show me customers with purchases under $1MM.” And “Add a note that we followed up with Pat Peterson at Vandalay yesterday about the integration…”
From a design perspective, it feels like replacing the layouts and navigation of Salesforce with queries (and if you’ve ever used or tried to design for Salesforce, that’s not necessarily a bad thing). When I imagine what that might feel like as an experience, one of the few touch points I have is Star Trek. Their AI was pretty badass, but they also had a bunch of screens they referred to silently. The Enterprise software designer must have had some principles that dictated when they needed screens and when they could rely on spoken queries. And now that we’ve reached this point where people are ditching their screens for AI (or considering it at least) we’ll probably need those guidelines soon enough.
As homework, I pulled up Make It So: Interaction Design Lessons from Science Fiction by Nathan Shedroff & Christopher Noessel. Brilliant people as they are, they already reduced these lessons to clear guidelines, for example:
Lesson: put information in the channel it fits best
Should a bit of system information be conveyed through audio or spoken language? Though every piece of content needs to be considered in its particular context of use, a good rule of thumb is to put peripheral information in peripheral channels. Since Captain Kirk could feel confident that his communicator was on when he heard voices coming from it, and off when he heard nothing or got no response, the double beeps that signal opening and closing communications can be considered peripheral and can be signaled as system sounds instead of a voice that would convey the same information. Conversely, if the system needs to convey that 10 seconds remain before the whole place is gonna blow, it could be conveyed as a rising tone, but the information is important enough that the discreteness and omnidirectionality of language is required.
-
Johnny Smith Learns the Cornet
Having learned to fly from pilots he befriended, Smith enlisted in the United States Army Air Forces in the hopes of becoming a military pilot. He was invalidated from the flight programme because of imperfect vision in his left eye. Given a choice between joining the military band and being sent to mechanic’s school, Smith opted to join the military band. Smith claimed that they gave him a cornet, an Arban’s instructional book, and two weeks to meet the standard, which included being able to read music. Determined not to go to mechanic’s school, Smith spent the two weeks practicing the cornet in the latrine, as recommended by the bandleader, and passed the examination.
-
Balancing intellect and natural instincts
If this was a strong idea in 1897, it’s 100x more true now…
Henry Childs Merwin explores the concept of being “close to nature” and contrasts it with the effects of excessive civilization. He argues that being close to nature involves engaging directly with natural forces and maintaining primeval instincts such as pugnacity, pity, and pride. Merwin suggests that civilization often dulls these instincts, leading to an over-reliance on intellect and reason, which can paralyze action and dilute moral impulses.
Merwin emphasizes the importance of retaining a balance between intellect and natural instincts, citing historical examples and literature to illustrate his points. He notes that societies and individuals who maintain this balance achieve the greatest deeds and produce the best literature. Conversely, those who become overly sophisticated and detached from nature lose vital instincts and become ineffective.
On Being Civilized Too Much By Henry Childs Merwin
Summary courtesy ChapGPT
-
We always need a Plan B
“‘The pessimists left Germany, the optimists ended up in Auschwitz.” The lesson from the Holocaust, he says, is to be on your guard. “We always need a Plan B, even today.’”
-
The Momentum of a City is Proportional to its Density
I’m stating the obvious, I know, but having lived in Hamburg for a year and then returning to Manhattan, especially midtown, reminds me of the energy that propelled my career when I was younger: the masses of people crammed into giant buildings, filling the wide sidewalks, filling every space available.
It’s not necessarily a good thing. Hamburg is a balance between the advantages of modern life and the needs of humans: many more green spaces, almost no very tall buildings, an emphasis on quality rather than efficiency.
-
Doctorow on Real (Climate) Innovation vs Silicon Valley Nonsense
“Silicon Valley is the land of low-capital, low-labor growth. Software development requires fewer people than infrastructure and hard goods manufacturing, both to get started and to run as an ongoing operation. Silicon Valley is the place where you get rich without creating jobs. It’s run by investors who hate the idea of paying people. That’s why AI is so exciting for Silicon Valley types: it lets them fantasize about making humans obsolete. A company without employees is a company without labor issues, without messy co-determination fights, without any moral consideration for others. It’s the natural progression for an industry that started by misclassifying the workers in its buildings as “contractors,” and then graduated to pretending that millions of workers were actually ‘independent small businesses’.”
-
Why Machine Learning Scares Us
So it turns out that the flavor of AI that is finally reaching the mainstream is the large language model. And we’re uncomfortable with it not only for the obvious reasons that there’s a machine acting eerily like a human, but also because we can’t explain precisely how it’s doing what it’s doing. And in that sense it’s like our own brains, and by extension so much about our universe. We’ve developed staggeringly complex science and simultaneously can’t explain how we think or where the universe came from or even make general relativity and quantum mechanics play nice together. This general situation has been unsettling for a long time, so we invented gods to explain the universe. But the gods didn’t make AI.
An image created for me by DALL-E
-
Passwords Are Now Outdated
There’s a lot to be said about how to secure our online information while providing a good experience; hasn’t anyone written this book yet? In any case, I think a good, uncommon, guideline would be:
Do not use human memoryTo remember and recall takes work, and I’d rather not expend my precious attention and cognition on computers. And, human memory is fallible. Most passwords break this guideline, but we now have biometrics and password managers to provide security without relying on memory and it’s time our security practices catch up to the technology.
Two-factor authentication, similarly, feels like a lazy, flawed approach which requires too much human work.
-
My Critique of the RGT Start Up Sound
In this video I listen to the sound as it’s used in real life, talk about what the sound is intended to accomplish, and then give it a sound score. And then I try to improve on it.
RGT is a great, freemium service that’s fun for cycling indoors. It connects to your bike and let’s you cycle through one of several virtual worlds along with other people. If you’ve heard of Zwift, it’s similar.
-
Track Buying Not Spending
When I designed software for personal finance, I thought a lot about helping people simplify and understand their cash flow. One method I created is an exceedingly simple way to track spending on projects that my wife and I have been using for years.
Most people track their money by tracking their spending. On the computer, there are websites such as Mint or You Need a Budget that will track everything you buy down to the cent, help you categorize every one of those expenses, and track it all on a regular basis.
We think that’s insane. Well, maybe once in a while it’s good to do a financial checkup to revisit where you’re spending your money. But really, all that time tracking expenses could be better spent making money or enjoying life.
Here’s the secret to how we do it: Instead of tracking spending, we track buying. We do this with our Things To Buy List.
Why don’t we track spending? We don’t track spending on fixed costs like our mortgage or the water bill since those 1) don’t change much and 2) need to be paid whether we like it or not. Any large expenses we’ve saving for, from retirement to the kids’ college education, is automatically deducted from our account. What’s left is money we can use for incidental expenses such as home projects, and for this task we want to track our buying. Tracking stuff we want to buy is also more fun than tracking money that’s already left us!
To track what we buy, we start by creating a list of things we want to buy. We’ll do this someplace digital so that it’s easy to share, re-prioritize, and cross items off the list. We use a wiki, but you could use a Google Doc, a shared to-do list, or a paper list on your refrigerator. Here’s what the top of our list actually looks like right now:
Then, as we have time to work on these projects, we’ll look at our checking account to see how much extra money is there and use it to buy things starting at the top of the list.
That’s it. That’s our entire method: Check the account, buy the stuff, and occasionally update the list.
Could a Things to Buy List work for you?
-
Which methods and resources should we deploy when users are suffering?
In the field of user experience design, we research users and often talk about the user pain points we’ve observed. When I use pain here I don’t mean inconveniences, as when I can’t find just the right streaming music playlist to match my mood. I mean tasks that emotionally hurt, such as knowing you need to file a timesheet by a deadline but you can’t figure out how do that with the enterprise timesheet software you’re forced to use, to the point you are cursing the software.
The phrase “pain points” implies discrete things or points in time. But in some cases users are interacting with a system on an ongoing basis and that pain is continuous. Usually when someone is in pain for an extended period we call it suffering. When it comes to our bodies we make this distinction between minor pain and suffering all the time. A minor pain we tolerate and wait for it to go away. When we’re suffering we go to the doctor.
When designing for users of software, differentiating between minor pain and suffering helps me make different choices about how to design solutions.
One consideration is how long to spend designing a solution. If we reduce either the pain or the time someone is in pain then we reduce the suffering. But this can involve a trade off: we can design an amazing solution that removes all users’ pain, but that could take a lot of time. We could design something and release it to users quickly, but it might only relieve part of their pain. Or we might find a middle road where we alleviate the worst pain first and then gradually alleviate the rest with subsequent releases.
Mathematically we can phrase it like this:
Pain x Time = Suffering
This tradeoff also helps me think about using the appropriate design methods. Let’s say for example that the scope of my problem is large, perhaps helping the U.S. government create a better way for residents to understand and file federal taxes. I would need a design methodology that can encompass many types of users, information, and interaction, such as service design. If preliminary research revealed that the most user suffering is in knowing how much to pay in estimated taxes, then I might focus on that problem. In order to alleviate that particular suffering quickly I would need a design methodology that helped me rapidly find a solution, such as Lean UX.
I’ll stretch this analogy further to illustrate how I think of allocating resources based on design needs. Near where I grew up is a large hospital system that offers patient care on different time horizons. One, the hospital has an emergency room to triage critical patient needs. Two, it has doctors who can provide scheduled, annual checkups. Three, it has specialists who provide larger procedures such as surgery. And four, it has research labs where it can develop new cures.
Now imagine there’s a tragic accident nearby. The hospital could allocate more resources to the emergence room to handle demand. Alternately, imagine a new disease is causing a pandemic; the hospital could allocate more resources to the research labs for find a cure.
Similarly, my team allocates resources depending on the kinds of problems our users have. One, we embed designers in agile feature teams to quickly alleviate critical user suffering. Two, we perform proactive testing to track how usability has changed over time. Three, we occasionally dedicate a team to a large change, such as an information architecture change. And four, we do research to arrive at overall design patterns such as infinite scrolling vs pagination. Our job titles and work assignments are fluid enough to respond to (constant) change.
All that to say:
- I try to be open to all methods and try not to see all problems as nails I can hit with my favorite design method hammer.
- When there is clear user suffering, I factor time into my choice of design method to alleviate suffering quickly.
-
This Blog is Almost Old Enough to Drink in America
Recently the web turned 30 years old, and I realized that this blog was started almost exactly 10 years after the web, making it 20 years old this month. And maybe that makes it a good time to start blogging again? Not really.
Although I am losing faith in Medium and Facebook as places to share my thoughts, and it’s comforting to know I have this place that’s all my own to do as I please, free of ads and unpleasant people. Let’s write and be pleasant!
