- The Poisoned NUL Byte, 2014 Edition (Project Zero) — from Google’s public security efforts, this detailed public description of how an exploit was constructed from a found vulnerability. They’re helping. Kudos!
- Myths About the Coming Robot Economy (Eric Sofge) — the entire discussion of the so-called robot economy, with its predictions of vast, permanent employment rates and glacial productivity gains, is nothing more than a wild guess. A strong pushback on the Pew Report (PDF): Frey and Osborne’s analysis is full of logical leaps, and far-reaching conclusions drawn from cursory observations about robots that have yet to replace humans.
- Content for Sensitive Situations (Luke Wroblewski) — People have all kinds of feelings when interacting with your content. When someone’s needs are being met they may feel very different then when their needs are not being met. How can you meet people’s needs?
- Urban Villages (Senseable City at MIT) — People who live in a larger town make more calls and call a larger number of different people. The scaling of this relation is ‘superlinear,’ meaning that on average, if the size of a town doubles, the sum of phone contacts in the city will more than double – in a mathematically predictable way. Surprisingly, however, group clustering (the odds that your friends mutually know one another) does not change with city size. It seems that even in large cities we tend to build tightly knit communities, or ‘villages,’ around ourselves. There is an important difference, though: if in a real village our connections might simply be defined by proximity, in a large city we can elect a community based on any number of factors, from affinity to interest to sexual preference. (via Flowing Data)
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.
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.
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.”
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?
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.
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.
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.”
You need to understand users to create engaging experiences that add value.
“[Jeff Sussna says in his blog post Empathy: The Essence of DevOps]: ‘It’s not about making developers and sysadmins report to the same VP. It’s not about automating all your configuration procedures. It’s not about tipping up a Jenkins server, or running your applications in the cloud, or releasing your code on GitHub. It’s not even about letting your developers deploy their code to a PaaS. The true essence of DevOps is empathy.’
“Understanding the other people that you work with and how you’re going to work together more effectively — that word ‘empathy’ struck me and it made me connect the world of DevOps with the world of user experience design.”
In the design community, empathy is at the heart of delivering excellent user experiences. Read more…
Putting ourselves in the shoes of the user is key to building better systems and services.
In this podcast episode, Tim O’Reilly talks about building systems and services for people, keeping a close eye on the end user’s experience to build better, more efficient systems that actually work for the people using them. Highlighting a quote from Jeff Sussna, O’Reilly makes a deeper connection between development and the ultimate purpose for building systems and services — user experience:
“[Jeff Sussna says in his blog post Empathy: The Essence of DevOps]: ‘It’s not about making developers and sysadmins report to the same VP. It’s not about automating all your configuration procedures. It’s not about tipping up a Jenkins server, or running your applications in the cloud, or releasing your code on Github. It’s not even about letting your developers deploy their code to a PaaS. The true essence of DevOps is empathy.’
“Understanding the other people that you work with and how you’re going to work together more effectively. That word ‘empathy’ struck me and it made me connect the world of DevOps with the world of user experience design.”
From tiny satellites to young programmers to reasoned paranoia, here are key talks from OSCON 2014.
Experts and advocates from across the open source world assembled in Portland, Ore. this week for OSCON 2014. Below you’ll find a handful of keynotes and interviews from the event that we found particularly notable.
How tiny satellites and fresh imagery can help humanity
Will Marshall of Planet Labs outlines a vision for using small satellites to provide daily images of the Earth.