{"version":"https://jsonfeed.org/version/1","title":"Aaron Gustafson: Content tagged empathy","description":"The latest 20 posts and links tagged empathy.","home_page_url":"https://www.aaron-gustafson.com","feed_url":"https://www.aaron-gustafson.com/feeds/empathy.json","author":{"name":"Aaron Gustafson","url":"https://www.aaron-gustafson.com"},"icon":"https://www.aaron-gustafson.com/i/og-logo.png","favicon":"https://www.aaron-gustafson.com/favicon.png","expired": false,"items":[{"id":"https://www.aaron-gustafson.com/notebook/links/digital-exclusion-in-healthcare-how-to-change-it/","title":"đź”— Digital Exclusion in Healthcare & How to Change It","summary":"Fantastic talk from Sareh on assumptions we make about our users and how those assumptions exclude people who have different lived experiences than we do.","content_html":"
Fantastic talk from Sareh on assumptions we make about our users and how those assumptions exclude people who have different lived experiences than we do. Her focus is on digital healthcare, but is applicable to everything.
https://www.youtube.com/watch?v=Zi1NXGgsM3s
I love her calls to action as well!
Related talk: Delivering Critical Information & Services
","url":"https://www.aaron-gustafson.com/notebook/links/digital-exclusion-in-healthcare-how-to-change-it/","external_url":"https://www.youtube.com/watch?v=Zi1NXGgsM3s","tags":["accessibility","empathy","inclusive design","industry","user experience"],"date_published":"2023-01-27T17:17:39Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/how-to-talk-about-disability-sensitively-and-avoid-ableist-tropes/","title":"🔗 How to talk about disability sensitively and avoid ableist tropes","summary":"The way we discuss people’s capabilities and disabilities is rife with ableist language and concepts. This piece from NPR offers a starting point for talking about disability without being offensive.","content_html":"The way we discuss people’s capabilities and disabilities is rife with ableist language and concepts. This piece from NPR offers a starting point for talking about disability without being offensive.
","url":"https://www.aaron-gustafson.com/notebook/links/how-to-talk-about-disability-sensitively-and-avoid-ableist-tropes/","external_url":"https://www.npr.org/2022/08/08/1115682836/how-to-talk-about-disability-sensitively-and-avoid-ableist-tropes","tags":["accessibility","empathy","inclusion","society"],"image":"https://media.npr.org/assets/img/2022/08/04/disability-pride-2_wide-74b7894c08644da3fec8f18dba71225001d24c74.jpg?s=1400","date_published":"2022-09-09T21:38:28Z"},{"id":"https://www.aaron-gustafson.com/publications/articles/what-interests-you/","title":"đź“„ What interests you?","content_html":"In my entry to this project, I offer some advice around how to build empathy through conversation.
","url":"https://superyesmore.com/what-interests-you-eb06c12d5ecd6475e6db7ebbeda0ce12","tags":["empathy","inclusion"],"date_published":"2017-04-15T00:00:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/planning-adaptive-interfaces-the-workshop/","title":"✍🏻 Planning Adaptive Interfaces: The Workshop","summary":"For the last few years I’ve been running a workshop alternately titled “Planning Adaptive Interfaces” or “Beyond Responsive”, depending on the conference. It’s been one of my favorite workshops to run for a number of reasons, but before I get into that, let me explain what it is and how it works.","content_html":"For the last few years I’ve been running a workshop alternately titled “Planning Adaptive Interfaces” or “Beyond Responsive”, depending on the conference. It’s been one of my favorite workshops to run for a number of reasons, but before I get into that, let me explain what it is and how it works.
I think we all recognize how much Ethan’s seminal article “Responsive Web Design” (and his follow-up book) shook up our industry. It changed the way we look at visual design and kindled (or in some cases re-kindled) an interest in catering an experience to mobile devices. But simply incorporating responsive design’s three core strategies—fluid grids, flexible media, media queries—is not the goal; meeting our user’s needs is. Responsive design is not an end in itself… it’s just the beginning.
We need to embrace the heterogenous nature of the Web—myriad connected devices with vastly different screen sizes (if they even have screens), network connectivity, and capabilities in use by countless individuals, each with their own special needs—and craft experiences that will work anywhere at any time. We need to build robust systems that adapt in ways far beyond aesthetics. I designed this workshop to explore the rich variety of use cases that often get overlooked in the course of building web projects and to show how we can begin considering them as early as possible.
When I was starting out, I gave “workshops” that basically amounted to a half-day or (worse) a full day for folks to listen to me blather on about one topic or another. People liked them, but I wouldn’t call them fun. And, in hindsight, I question how much value people got from an extended survey of what’s possible without the opportunity to put that knowledge to use. Workshops should encourage attendees to get their hand dirty.
I kick this workshop off with a relatively brief discussion of the considerations that we should be aware of—beyond screen size and pixel density. I also provide examples of how to adapt interfaces so they rise to meet our customers’ needs. Then I throw out a list of common interface patterns—modals, tabs, etc.—and turn the floor over to the attendees, asking them to build small teams that each examine a single pattern in detail with these considerations in mind. They then spend the rest of the workshop planning out how that interface would adapt to consider factors like accessibility, screen dimensions, device capabilities, JavaScript availability, and so on. All the while, I circulate among the groups, asking and answering questions, pressing them to go a little further with each iteration. Some teams sketch, some prototype, and all spend a lot of time debating, which is awesome!
I leave the last hour or so for a group discussion of what each team’s accomplished. It gives them a chance to talk through their approach, what they learned, what their pain points were, and how they overcame them. Not does it celebrate their work, but it helps the other attendees discover novel ways to approach these common UI constructs.
It’s been a blast and I have learned so much from the teams I’ve coached. Each workshop is completely different because each group of attendees is completely different. I’ve run it with groups ranging from 12 to 120, for internal teams at large companies to mixed audiences from all over the world. Everyone who has attended one of these workshops has brought a unique perspective and helped us all get better at our jobs. That’s been one of the best parts of this experience for me.
If a workshop like this sounds up your alley, I’ll be giving it a few more times in 2016. Your next opportunity will be at EnhanceConf in London in early March. Later in the year, I’ll be giving it as part of Sparkbox’s Build Right: Maker Series. I’d love the opportunity to work with you if you can make it!
","url":"https://www.aaron-gustafson.com/notebook/planning-adaptive-interfaces-the-workshop/","tags":["conferences","progressive enhancement","responsive web design","pattern libraries","empathy","Adaptive Web Design"],"date_published":"2016-02-21T23:56:05Z"},{"id":"https://www.aaron-gustafson.com/notebook/apple-support-honeybadger/","title":"✍🏻 Apple Support: Honeybadger","summary":"My iPhone fell clumsily out of my pocket when I was sitting down in the kitchen the other day. I was crestfallen.","content_html":"My iPhone fell clumsily out of my pocket when I was sitting down in the kitchen the other day. Thwack! It fell face-first onto the tile from my seated position a mere 18 inches up. Of course the screen cracked. Protective case be damned, the cracks spread across the screen like a spider web cast from razor blades.
I was crestfallen.
Thankfully, apart from the very finger-unfriendly hellscape the screen had become, the rest of the phone completely functional. If I was careful where and how I swiped, I could do pretty much anything I needed to. And I did exactly that for a few days while I looked into my options for fixing it.
It was an iPhone 6 I purchased right when they came out, so a warranty repair was not an option. And I don’t see the point of paying for phone insurance or Apple Care1, so I was on my own to cover the cost of the repair. No biggie; it was my fault for putting it in the loose pocket of my pajama pants anyway.
I began researching my options:
Apple offers screen repair for $109, which isn’t too bad, but that takes a few days to ship the phone back and forth. They offer an expedited option where they just send you a new phone, but at $299, it seemed silly.
I contacted the local authorized Apple repair center to see if they could do the repair, but it turns out that they would just be sending it on to Apple anyway, so it seemed like my best bet would be to go back to the source. After all, who could know better how to replace a broken iPhone screen (and digitizer, since they’re fused) than Apple Support?
I chatted with an Apple Support rep about doing the repair and confirmed that the repair would cost $109. The rep told me, however, that they would need to authorize my card for $299—the out-of warranty replacement cost—in case they discovered other damage to the phone. I agreed (it was my only option) with the understanding that Apple would run some diagnostic utilities to determine what (if any) additional issues the phone might have.
A day or two later I got the mailer to send the phone to Apple, I shipped it to them and waited. They confirmed receipt of the phone the next day and, two days later, I got an email saying the phone was en route back to me. I was thrilled with the quick turnaround!
Then Kelly asked me why Apple had charged us $329. I said I wasn’t sure. The authorization was for $299, but the repair service was only supposed to be $109 (plus tax and shipping, naturally). Perhaps they billed the whole amount and then returned the unused portion in a separate transaction. We decided to wait and see what would happen.
The next day, a phone arrived. I say a phone because it was not my phone. Apple Support had sent me a refurbished replacement phone and charged me the full replacement cost. Why? “After thorough diagnostic testing, it has been determined that a replacement iPhone (enclosed) is necessary.” Vague.
I was curious what their tests had revealed. What gremlins were lurking in my heretofore fully-functional device? I decided to investigate with another support rep and was not thrilled with what I found.
Note: I spent the next few hours in a chat session with two different reps at Apple Support. Both were incredibly friendly and did everything in their power to help me get to the bottom of why my screen repair had turned into a complete replacement. Credit where credit is due.
In the conversation with the first rep, Josh, I made it clear that the phone was working perfectly before I sent it to them. It merely needed a new screen/digitizer. I offered that I was disappointed to see that they’d replaced it without explaining what would require that level of remediation and without giving me the option to have the phone returned to me as-is. From the beginning, he clearly saw where I was coming from:
Oh good grief, I’m really sorry you’ve had to deal with this. That’s not at all what we want from this process.
After a few minutes of doing some research, he came back to me:
So basically from what we’ve been discussing, the service center does run a plethora of tests on the phone once it’s sent in. That’s to be sure that it’s working properly in all ways, rather than just the screen repair itself, though trust me, I do fully understand that the only thing you wanted was the screen to be repaired, so I’m just compiling all of the data to see what happened.
A few minutes later…
[I]t’s looking like basically what ended up happening was there were tests that were run which will test the phone for a bit of additional damage than the tests that were run. From there, they look into what will give you the longest lasting phone, basically so that you don’t run into an issue with what their diagnostics tests detected down the road, and then need to pay again for it to be repaired.
I replied
[That]assumes I plan to keep the phone long enough for it to become an issue… I appreciate them looking into potential issues, but making unilateral decisions about how to proceed is not good customer service in my opinion. Letting someone know what the issue is and how much the repair would cost is just common courtesy. Even my car dealership does me that courtesy.
Josh was right there with me:
Exactly, which I know is not always a proper assumption, and I can entirely agree. I’m even still looking into additional data for you. I really don’t like how this was handled, so I’m seeing if I can come across anything additional on the matter.
He asked if I knew of any other damage to the phone and I told him that it was always in a case and I was not aware of a single other issue with the phone, cosmetic or otherwise.
He was completely empathetic:
I’m really sorry about this whole thing, Aaron. It’s looking like some sort of damage was found with the phone, which is what caused that price to be charged, rather than just the screen repair, so ultimately they decided that it would give you a longer lasting phone to replace it, so that way you wouldn’t have to deal with the hassle of having additional issues down the road. Honestly, I cannot express enough how much I understand the situation, and especially at least being informed or asked if that can be done. That’s just why the full out of warranty/replacement charge has to be held initially, is so that they have authorization to run those tests, and if needed, replace it, rather than just repair it. I’m so sorry that the process wasn’t elaborated to you, and that they didn’t at least let you know of what was going on.
I reiterated that someone really should have asked if I wanted the additional work done. I understand Apple’s “heart” might be in the right place, but they failed to do what I had hired them to do. They didn’t consider my wishes or expectations in their process at all. Nor did they give me an opportunity to decline the replacement and get my broken phone back.
Josh pleasantly informed me that by agreeing to the repair, I was out of luck:
[Replacement]was actually authorized to be used when you initially setup the payment. When the full $299 (plus taxes and shipping) was held from your card, that was authorized that if needed, it could be used for the repair if additional damage was found. Since it was found, they used the remainder of that money to replace the phone instead.
I countered:
I understand that you required the $299 + tax in order to start the repair, but that was my only option if I wanted you guys to do the $109 screen repair. Like I said, had I suspected anything else was going to be done to the phone, I would have taken my chances buying a replacement screen and doing the repair myself. … I typically replace my phone every other version, so I would have limped along with the broken screen even rather than pay the full replacement fee.
Josh, to his credit, was still on my side:
Right, trust me, I fully understand, or alternatively we could have taken it into the local Apple Authorized Service Provider, which would have been able to diagnose the phone as well in order to determine what had to be done, and then give you a price right then and there. … I’ve actually covered cracked screens in cling wrap so that I didn’t need to risk furthering the damage, or hurting myself. I can also fully understand the process of not expecting that there was any further damage, since you were able to sue the phone just fine, and that’s why you ended up getting it setup that way.
Ultimately, however, it didn’t really matter:
Basically, again, as much as I wish there was something that could be done on the matter in order to basically reverse what happened, it’s just not possible. Since it was authorized when it was initiated, and I do see where the previous advisors let you know that the full charge would be taken if additional damage was found, but if the only damage found to the phone was the screen cracks, then all but the screen repair fee of $109 plus taxes and shipping would be reimbursed. It’s just that additional damage was found, which is what caused that full charge to be taken.
After a bit more back-and-forth, Josh recommended I file a complaint with Apple (I have), said he would make sure the process was reviewed internally, and connected me with a Senior Advisor, Alexander, to help me get a few more details regarding the “damage” that prompted the replacement. I thanked him for his time and for his empathy toward my situation.
The next few minutes involved getting Alexander up to speed with what had happened. He was equally helpful:
Okay, I know how a sudden cost like this $299 can be concerning, especially when you don’t feel adequately informed on the situation. I can certainly clarify anything and get this figured out with you though.
Then he dropped the bombshell:
So the main bit of information that I want to address is not that the phone was replaced to address issues that may arise down the road. In this case, a screen replacement was attempted and did not yield a functioning device. When that occurs, our only option is to replace the device. I do see from your chats with Michelle and Teresa that they advised this was the procedure that we have
Wait. What?! They didn’t find any problems. In replacing the screen, the tech bricked the phone.
No, not at all. Just that they were unable to have a fully functioning unit after a screen replacement. That does not mean that the tech bricked the phone or messed up when replacing the screen, it means the phone was not able to work after the screen was replaced.
Um, sounds to me like they bricked my phone. Alexander tried to clarify, but was ultimately saying the same thing:
While the issue was only a cracked screen, that does not mean that the screen can be replaced and yield a functioning device. Unfortunately we can never know if a screen replacement will work until we try.
So… iPhones are only occasionally repairable. In other words, it’s a crapshoot. Comforting. No one had mentioned that they could brick the phone when attempting to repair it:
I was never advised that the repair could yield a non-functioning device. This is even more strange than I expected.
Alexander towed the company line:
I’m looking at the chats you had with us when setting up the repair, and both advisors did say how it could be $299. I also don’t see anything from either one that says the depot would reach out to you if the repair price was not going to be $109. I’m really sorry that this happened to you Aaron, but this is how our process works and everything looks to have been done correctly here. … I see them saying that they will attempt to replace the screen and if that works it would be a $109 repair. If there were additional issues, it would cost more up to the $299 max for a full replacement unit.
I clarified that they had said it could cost more. There’s a difference between “could” and “would”. I mentioned that I could have just kept the broken phone and upgraded with AT&T and spent less money. Alexander didn’t miss a beat:
That certainly was an option you could have taken Aaron, and I do sympathize with not taking that option to end up paying more than you expected. I really wish the repair process was clearer for you, and I can only advise that you leave some feedback about the repair process to us at Apple Feedback. I don’t see any mention in these chats of the depot contacting you if the cost would be more nor an advisor stating that would be the case.
I stuck to my guns:
I agree they didn’t state that would happen, but I think in the repair world it’s pretty common. … Explicitly stating that would not happen might be a good thing.
Alexander conceded that the process was less than ideal:
I don’t disagree, but that does vary from place to place and device to device. Our procedures are in line with most of the mobile phone world on this though. I will certainly leave some feedback for those advisors to be more clear about this process when a repair is set up though.
We talked for a few more minutes, but it was clear I was out of options. I could file a complaint with Apple (and have), but I am skeptical they even pay attention to that stuff. I know they don’t chime in on their own forums. My only other option was to share my story with you, in hopes you might avoid a similar situation.
So consider yourself warned: If you send your phone to Apple for something as simple as a screen repair, they just may brick your phone and charge you for the convenience. Oh and the replacement phone only has a 90-day warranty. Hooray!
This is the first device I’ve broken in more than a decade of (ab)using expensive smartphones. ↩︎
In more than a handful of conversations lately, it’s become quite clear that we, the web development community, are prioritizing our own convenience and our own time over that of our users. With our industry’s focus on “user-centered design”, you might find that hard to believe, but it’s true.
Here’s one example. In reaction to my post on why I think CSS variables are a bad idea, SASS core team member Chris Eppstein had this to say:
https://twitter.com/chriseppstein/status/567756897105620992
Fundamentally, I agree with his sentiment: A preprocessor should not be a requirement for authoring CSS. Thankfully, it never was; you can build amazing things using only hand-authored CSS. And if you find a preprocessor helpful to your process for one reason or another, great. But using a preprocessor never has been (nor should it ever be) a requirement.
But Chris was not railing against preprocessors. Instead, he is echoing a sentiment held by many people in the preprocessor community. He feels CSS is not as powerful as it could/should be and he hopes that one day soon preprocessors won’t need to exist because CSS will have all of the features they offer. Like variables.
I used to feel that way. I used to want variables… and mixins… and functions… and loops… and declaration block-level inheritance. But I’ve changed my mind.
Don’t get me wrong, I love these constructs. I use them nearly every day in the SASS I write and I am incredibly thankful for the hard work that has gone into their creation and maintenance. Chris alone has probably saved me several weeks worth of work over the last four years through his contributions to SASS and Compass. I definitely owe him a beer (or three).
Ok, so if my issue is not with the idea of programmatically generating styles, why would I not want these to be part of CSS, the lingua franca for design on the Web? Well, it’s pretty simple: Converting all of these constructs into something that is actionable by the browser takes time and processing power. Someone has to pay that cost and I wouldn’t feel right passing that cost on to my end users if there are better options.
This is a topic I bring up often in my conference talks and workshops: Every decision we make affects the user experience in some way.
When we add another JavaScript library or plugin, it’s no big deal from our perspective. We tend to have fast connections and faster processors. For our users it’s another story: It’s one more thing to request. One more thing to download. One more script to parse. One more thing holding up page rendering. One more reason to leave our site and seek out a competitor who actually values their time.
When we hide an img
in the small screen version of our responsive design using display: none
, the cost to us is quite minimal. It’s just one little declaration. What’s the harm? But the cost to our end users is quite significant: Longer load times, slower performance, and (in some cases) in real dollars if they are on a metered data connection. And they don’t even get to see the image they paid for!
When we decide to build a site using a front-end JavaScript MVC framework, it can make the development process go so much faster for us and we can reduce our need for a robust back-end infrastructure. I mean everyone has JavaScript these days… the browser is the new VM. But when we do this, our users suffer because we don’t give their browsers real HTML. Instead we force them to download a hefty framework so we can move all of the processing we would normally handle on a much faster, dedicated server to their questionably-capable machine instead. Oh, and if the browser encounters an error while parsing or executing the JavaScript execution, they don’t get anything at all. Welcome to the Modern Web™!
When I look around, I see our community spending a lot of time coming up with new tools and techniques to make our jobs easier. To ship faster. And it’s not that I’m against efficiency, but I think we need to consider the implications of our decisions. And if one of those implications is making our users suffer—or potentially suffer—in order to make our lives easier, I think we need to consider their needs above our own.
So yes, I would love a world where preprocessors are unnecessary, but I would much rather spend a few seconds (or even a few minutes) transcompiling my SASS into CSS in order to save my users even a few milliseconds. It’s the same reason I optimize my images, minify my JavaScript, use Gzip, and lazy load design and experience enhancements only in contexts where they provide a real benefit.
Our users should never foot the bill for our convenience. We need to put their needs above our own.
","url":"https://www.aaron-gustafson.com/notebook/who-should-pay/","tags":["web design","progressive enhancement","empathy","performance"],"date_published":"2015-02-19T04:35:06Z"},{"id":"https://www.aaron-gustafson.com/notebook/we-need-more-empathy/","title":"✍🏻 We Need More Empathy","summary":"For a while now I’ve been beating the “empathy” drum (notes), trying to get folks in our industry to understand the importance of creating connections with the people for whom we build software, websites, etc. After all, we design and build tools to solve the needs of actual people, not some generic “user”.","content_html":"For a while now I’ve been beating the “empathy” drum (notes), trying to get folks in our industry to understand the importance of creating connections with the people for whom we build software, websites, etc. After all, we design and build tools to solve the needs of actual people, not some generic “user”.1
It’s tough to connect with other people and we often fall into the trap of designing products for us and people like us. Jeffrey Zeldman characterizes the problem perfectly in his recent post:
If we keep throwing only young, mostly white, mostly upper middle class people at the engine that makes our digital world go, we’ll keep getting camera and reminder and hookup apps—things that make an already privileged life even smoother—and we’ll keep producing features that sound like a good idea to everyone in the room, until they unexpectedly stab someone in the heart.
Empathy is difficult when we are surrounded by others like us. We need to be surrounded by different people. Certainly gender and ethnic diversity is incredibly important here, but so is diversity of experience. As Jeffrey astutely points out, diversity in the room where Facebook’s “Year in Review” concept was given the green light would have—I have to hope—helped create some safeguards to keep some of their actual customers from being reminded of tragedies they experienced this year.
In all likelihood, the worst thing they probably discussed was an embarrassing hookup being celebrated, but I’ve had several friends lose children and loved ones this year, other friends battling serious illnesses, and still others who have suffered losses of different sorts. All bore their souls on Facebook in the past year and this feature has brought it back and, in some cases, celebrated these tragic events in a very uncanny and dispassionate way.
And Facebook isn’t the only company to blame for this sort of thing. Pretty much every social network suffers from similar issues. Reading the comments on the various press accounts of this story have revealed similar problems at LinkedIn, Google+, Twitter, and others. We can and need to do better.
In order to address these issues, we need to flex our empathetic muscles. We need to create connections with people who are not like us. People who live in different neighborhoods. People who come from different countries. People who require alternate means to accessing our sites and services. We need to see that the world is full of differences.
Life is full of great joy as well as great tragedy. When we acknowledge diversity of experience and actually embrace it, we become better designers.
I don’t mind the aggregate “users”, but “user” is too clinical and distanced for my tastes. Terms like “the user” keep us from connecting with the people who actually use our software and when we are disconnected from our users, we will not do a great job of solving their problems. And solving problems is the whole point of design. ↩︎
I gave this PechaKucha talk on how empathy came to be a central part of my work and life.
","url":"","tags":["accessibility","career","empathy","equality","inclusion","inclusive design","mentoring","personal","philosophy"],"image":"https://www.aaron-gustafson.com/undefined","date_published":"2013-12-13T23:00:00Z"},{"id":"https://www.aaron-gustafson.com/speaking-engagements/designing-with-empathy/","title":"📢 Designing with Empathy","summary":"In this session, I explore why empathy is a good thing, how empathy empowers creativity, and how we, as a community, can inject more empathy into our work.","content_html":"Every decision we make affects the way real people experience our products. We’ve all heard the rallying cry for user-centered design, but even those of us who ascribe to that ideal often fall back on our own biases and instincts when it comes to making decisions about how people experience our content and our services. Sadly, this often means we make decisions we think will be good for our “users”—that anonymous, faceless crowd—rather than actually trying to understand the perspectives, surroundings, capabilities, and disadvantages of the actual people who we are here to serve.
In this session, I explore why empathy is a good thing, how empathy empowers creativity, and how we, as a community, can inject more empathy into our work.
","url":"","tags":["empathy","equality","design","user experience"],"image":"https://www.aaron-gustafson.com/undefined","date_published":"2013-04-08T14:00:00Z"}]}