"empathy" entries
How virtual reality can make the real world a better place
Can VR become “the ultimate empathy machine?”
.jpg)
Virtual reality (VR) can make the impossible possible — the rules of physical reality need no longer apply. In VR, you strap on a special headset and leave the real world behind to enter a virtual one. You can fly like a bird high above Manhattan, or experience the feeling of weightlessness as an astronaut on a spaceship.
VR is reliant upon the illusion of being deeply engrossed in another space and time, far away from your current reality. In a split second you can travel to exotic locales or be on stage at a concert with your favourite musician. Gaming and entertainment are natural fits for VR experiences. A startup called The Void plans to open a set of immersive virtual reality theme parks called Virtual Entertainment Centers, with the first one opening in Pleasant Grove, Utah by June 2016.
This is an exciting time for developers and designers to be defining VR as a new experience medium. However, as the technology improves and consumer hardware and content become available in VR, we must ask: how can this new technology be applied to benefit humanity?
As it turns out, this question is being explored on a few early fronts. For example, SnowWorld, developed at the University of Washington Human Interface Technology (HIT) Lab in 1996 by Hunter Hoffman and David Patterson, was the first immersive VR world designed to reduce pain in adults and children. SnowWorld was specifically developed to help burn patients during wound care. Read more…
Data, design, and intuition
The O’Reilly Design Podcast: Pamela Pavliscak on designing for happiness.
Subscribe to the O’Reilly Design Podcast, our podcast exploring how experience design — and experience designers — are shaping business, the Internet of Things, and other domains.
In this week’s Design Podcast episode, I sit down with design researcher and data scientist Pamela Pavliscak. Pavliscak is the author of Data-Informed Product Design, a free report from O’Reilly, and will be speaking at OReilly’s inaugural design conference.
Pavliscak talks about the delicate relationship between data and design, and why it’s not an either or proposition, as well as why designing for happiness is good for business.
Here are a few highlights from our conversation:
We like to think in dichotomies for when it’s either data or intuition. I think of it more like archaeology. Archaeology is not always about finding the big celebrities or what the important heroes and personalities of history do. It’s about learning more about the everyday practices of people. You have these clues, these traces left behind. Like archaeology, the science gets more sophisticated. Archaeologists have remote sensing and X-ray guns. Data scientists have algorithms and AI. The big difference is, these people that we’re learning about with data science are still around. We can learn about them in their own words and rely on them to share their feelings and their context. For me, it’s not really an either-or, but more of kind of an improv ‘yes-and’ kind of relationship.
I always suspected that delight, that concept that we have in design, wasn’t the full story of what made people happy. The small moments, the small pleasures certainly factored in, but it really seemed that the patterns fell into this kind of deeper meaning. I would see people for Humans of New York — this is the happiest site in the world for people. Not in the sense that it’s showing happy things, but because it makes people feel connected. It’s connected to a story, and it’s connected to a story that’s not complete. There’s still room for people. Those are the kind of moments that came out.
You’ll find that happier employees are more productive and they find more meaning in their work at the same time. Even way back to the 80s, I found some research on product detachment, and found that happiness and brand detachment are somehow linked together. There’s Martin Seligman’s PERMA, there’s subjective well-being scale, there’s Maslow’s hierarchy, which of course we all know by heart. Countries are applying happiness initiatives to supplement their GDP. We’re learning more about this through behavioral economics and these different models.
Empathy: The designer’s superpower
Scott Jenson on empathy, interaction on demand, and Google’s Physical Web Project.
I recently connected with veteran designer Scott Jenson, who is currently developing the Physical Web Project with the Chrome team at Google. We’ve been talking quite a bit about empathy in the past few months here at O’Reilly, and Scott’s recent blog post, The Paradox of Empathy, caught my attention. I sat down with him to learn more about his thinking around empathy and to talk about his work on the Physical Web Project.
Empathy is part of every great designer’s toolkit
Jenson is often asked for recommendations for learning the next tool, or program. but as he explains, learning how to empathize is fundamental to product design:
When I reflected on what I wanted people to understand, what the core thing was, it wasn’t a technique. It wasn’t a visual style. It wasn’t learning a certain program. The core thing was making sure that you never thought about the product from your point of view, but from somebody else’s point of view. That’s what prompted the [The Paradox of Empathy] post.
He breaks empathy down into four components:
I basically take the whole design process from soup to nuts and break it up into four types of things, what I called understanding, bridging, flowing, and refining, which is a little bit of wordplay, but it was just really trying to say that most people talk about the icons and the buttons. That’s the last category, the refining. What I tried to do was to go back in time to get earlier and earlier interactions with people. So, the flowing is basically just how the whole program feels and what metaphors do you use, and how many steps do they take. It’s the level above the bits. Bridging was about matching the technology to the actual user needs. The most important one, the one that we actually tried to do the most when I was at Frog Design, was understanding, which was just to understand what people were doing, what were they up to, where they were at. In fact, to the point where you’re not even designing a product for them. One of the reasons why I think [The Paradox of Empathy] post got some positive response, was the fact that the first two were so clearly focused on user research.
IBM is banking on design’s ROI
Phil Gilbert on IBM’s deep design roots, change management, and hiring for culture fit.
Companies of all sizes are recognizing that by taking a design-first approach to product development, they can improve profit. I recently sat down with Phil Gilbert, GM of design at IBM, to discuss how he is helping to lead the transformation to a design-first company within IBM. Adopting design as a key corporate asset may seem like a no-brainer, but for a company of more than 350,000 employees, it’s a massive undertaking. IBM hasn’t been quiet about its plans to hire 1,000 designers over the course of five years and embed design in product teams throughout the organization.
IBM’s long history of design
What I was surprised to find when reading about IBM’s latest design plans, is that the giant tech company has design roots dating back to the 1950s. Gilbert shares in more detail:
We started our first design program — and we were one of the first to really apply design holistically at scale — in 1956. In the 1950s and the 1960s and into the early 1970s, we had a constellation of designers around IBM that, quite frankly, has never been equaled.
Elliott Noyes was our first head of design. Thomas Watson Jr. hired him in 1956. He assembled people like Eero Saarinen, Charles and Ray Eames, and Paul Rand. He assembled this team of people, and, essentially, I think the reason it happened then is because humanity was addressing a fundamentally different relationship between ourselves and technology. There was a lot of turmoil and angst as a result. We used design at that time to communicate and engage in a conversation with humanity about that relationship and about our role with technology. We viewed it as a very holistic statement — we communicated it through our products, our communications, our buildings, and we did it through our exhibits at places like the World’s Fair.
Since then, I don’t think there has been as fundamental a change in the relationship between human beings and technology. The move from mainframe to mini-computer, the move from mini-computer to personal computer, the move to client-server computing — all of these things were actually fairly incremental. But I think in 2007, with the release of the iPhone and with the ubiquitous access via mobile devices, I actually think that we’re, again, in a time of real turmoil and change around this relationship of where does technology sit with human beings.
This is a real change, and I think that human-centered design and design thinking as a method to achieve human-centered design is why it’s become so important. Because our relationship with technology is, it may not be as frightening as it was in the 50s and 60s, but it certainly is fundamental. I don’t think we quite yet understand it. I think design is the primary lever that we have to understand that relationship and then to communicate that relationship.
Empathy is a stepping stone to a more important place: understanding
Understanding is what designers should be striving for as the backdrop for products.
Editor’s note: this post originally published on Medium; this lightly edited version is republished here with permission.
About 10 years ago, I worked on a project for a new system for people with diabetes. We talked with many people who had diabetes or who helped educate diabetics. I even wore an insulin pump around for several days. In short, we were building up subject matter knowledge and empathy for the people we were designing for. During this user research phase, many of us (myself included) started to have actual nightmares that we had diabetes. I remember once looking at my toes, wondering if the tingling I was feeling was the onset of diabetes. (It wasn’t — probably just my foot was asleep.) We’d empathized to the point where we really identified with diabetics and their problems, which are considerable. We had so much empathy for them, in fact, that for several weeks, we couldn’t solve the problem. It seemed intractable, given what we knew about the condition and the state of technology at the time.
It wasn’t until we were able to step away from the diabetics’ perspective and become less empathetic that we were able to come up with a product concept. We needed distance — a psychic removal — in order to really assess the problem and take action to change it. In other words, we had to act like designers, which meant we had to be more objective, to sit outside and to the left of the problem space. As this experience taught me, too much empathy can be as crippling as too little.
Empathy is a state of mind, not a specific technique
A design process paved with empathic observations will lead you, slowly and iteratively, to a better product.
Editor’s note: this post was originally published on the author’s blog, Exploring the world beyond mobile; this lightly edited version is republished here with permission.
If I’m ever asked what’s most important in UX design, I always reply “empathy.” It’s the core meta attribute, the driver that motivates everything else. Empathy encourages you to understand who uses your product, forces you to ask deeper questions, and motivates the many redesigns you go through to get a product right.
But empathy is a vague concept that isn’t strongly appreciated by others. There have been times when talking to product managers that my empathy-driven fix-it list will get a response like, “We appreciate that Scott, but we have so much to get done on the product, we don’t have time to tweak things like that right now.” Never do you feel so put in your place when someone says that your job is “tweaking.”
The paradox of empathy is that while it drives us at a very deep level, and ultimately leads us to big, important insights, it usually starts small. The empathic process typically notices simple things like ineffective error messages, observed user workarounds, or overly complicated dialog boxes. Empathy starts with very modest steps. However, these small observations are the wedge that splits the log; it’s these initial insights, if you follow them far enough, that open up your mind and lead you to great products.
Designing for delight
Suzanne Pellican on Intuit’s transformation to a design culture.
I recently had a wonderful conversation with Suzanne Pellican, chief design strategist at Intuit. She has spent the last several years coaching both designers and non-designers on how to think of and use design thinking as a core competency to improve business results and spur innovation.
Design thinking admittedly is a quirky phrase. What’s important is that it places design in a context that non-designers can appreciate. Pellican defines it and its relation to service design:
“‘Design for Delight’ at Intuit is our version of design thinking, and we reduced it down to three core principles: deep customer empathy, go broad to go narrow, and rapid experiments with customers. … Design thinking is the practice of problem solving and is based on those three core principles. That’s the actual skill set, the tools, and the mindset that you have. Service design is actually applying that then, end to end, as you’re thinking about very specific experiences for customers across many channels.
“The way that we do service design at Intuit today, a lot of the effort is in, let’s say, care — so when you think about a care experience for a customer you have to think about the many channels that they can access, including telesales and agents and care or the website or on my articles. You’re trying to think about their whole experience and you’re also trying to think about infrastructurally how could you deliver a delightful experience. That is service design.”
What is DevOps (yet again)?
Empathy, communication, and collaboration across organizational boundaries.
I might try to define DevOps as the movement that doesn’t want to be defined. Or as the movement that wants to evade the inevitable cargo-culting that goes with most technical movements. Or the non-movement that’s resisting becoming a movement. I’ve written enough about “what is DevOps” that I should probably be given an honorary doctorate in DevOps Studies.
Baron Schwartz (among others) thinks it’s high time to have a definition, and that only a definition will save DevOps from an identity crisis. Without a definition, it’s subject to the whims of individual interest groups, and ultimately might become a movement that’s defined by nothing more than the desire to “not be like them.” Dave Zwieback (among others) says that the lack of a definition is more of a blessing than a curse, because it “continues to be an open conversation about making our organizations better.” Both have good points. Is it possible to frame DevOps in a way that preserves the openness of the conversation, while giving it some definition? I think so.
DevOps started as an attempt to think long and hard about the realities of running a modern web site, a problem that has only gotten more difficult over the years. How do we build and maintain critical sites that are increasingly complex, have stringent requirements for performance and uptime, and support thousands or millions of users? How do we avoid the “throw it over the wall” mentality, in which an operations team gets the fallout of the development teams’ bugs? How do we involve developers in maintenance without compromising their ability to release new software?
DevOps keeps it cool with ICE
How inclusivity, complexity, and empathy are shaping DevOps.
Over the next five years, three ideas will be central to DevOps: the need for the DevOps community to become more Inclusive; the realization that increasing Complexity of systems is the underlying reason for DevOps; and the critical role of Empathy in the growth and adoption of DevOps. Channeling John Willis, I’ll coin my own DevOps acronym, ICE, which is shorthand for Inclusivity, Complexity, Empathy.
Inclusivity
There is a major expansion of the DevOps community underway, and it’s taking DevOps far beyond its roots in agile systems administration at “unicorn” companies (e.g., Etsy or Netflix). For instance, a significant majority (80-90%) of participants at the Ghent conference were first-time attendees, and this was also the case for many of the devopsdays in 2014 (NYC, Chicago, Minneapolis, Pittsburgh, and others). Moreover, although areas outside development and operations were still underrepresented, there was a more even split between developers and operations folks than at previous events. It’s also not an accident that the DevOps Enterprise conference took place the week prior to the fifth anniversary devopsdays and included talks about the DevOps journeys at large “traditional” organizations like Blackboard, Disney, GE, Macy’s, Nordstrom, Raytheon, Target, UK.gov, US DHS, and many others.
The DevOps community has always been open and inclusive, and that’s one of the reasons why in the five years since the word “DevOps” was coined, no single, widely accepted definition or practice has emerged. The lack of definition is more of a blessing than a curse, as DevOps continues to be an open conversation about ways of making our organizations better. Within the DevOps community, old-time practitioners and “newbies” have much to learn from each other.
Designers can do anything
Jon Kolko on how empathy, theory, and tactical skills can put the next generation of designers on a path to success.
Design principles are being applied in all aspects of business today — they are no longer limited to graphic design, product design, web design, or even experience design. I recently spoke with Jon Kolko, vice president of consumer design at Blackboard, founder and director of Austin Center for Design, and author, about the skills designers need today and the curriculum formula to help them succeed.
In our conversation, Kolko talked about how a balance of process, empathy, theory, and tactical design skills can prepare designers for success in more traditional design roles and beyond. Kolko is a firm believer in an empathy-based, user-first approach to design. User-first is not unique, but Kolko advocates getting to know the user before even conceiving of the product:
“The switch to an empathy focus is actually really easy. You need to watch behavior, so that means actually watching people do things. We talk about watching people work, play, and live because sometimes the things they do are actually not that utility driven… So, depending on what your product is, you need to start to get to where people are actually doing things. It’s like a hair away from doing an interview, but that behavioral hair makes all the difference because when you conduct an interview, you get retrospective behavior anecdotes that tend to gloss over specifics; they make false estimates and generalizations, and they don’t have that rich nuance and outlier that you can start to build insights around. Those specific insights then go to drive your new product ideas.”