FEATURED STORY

Empathy: The designer’s superpower

Scott Jenson on empathy, interaction on demand, and Google’s Physical Web Project.

Toolbox_florianric_FlickrI 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.

Read more…

Comment

Embracing failure and learning from the Imposter Syndrome

What you miss with a "get it right the first time" mentality

Masks_Brian_Snelson_Flickr

Download our updated Women in Data report, which features four new profiles of women across the European Union. You can also pick-up a copy at Strata + Hadoop World London, where Alice Zheng will lead a session on Deploying Machine Learning in Production.

Lately, there has been a slew of media coverage about the Imposter Syndrome. Many columnists, bloggers, and public speakers have spoken or written about their own struggles with the Imposter Syndrome. And original psychological research on the Imposter Syndrome has found that out of every five successful people, two consider themselves a fraud.

I’m certainly no stranger to the sinking feeling of being out of place. During college and graduate school, it often seemed like everyone else around me was sailing through to the finish line, while I alone lumbered with the weight of programming projects and mathematical proofs. This led to an ongoing self-debate about my choice of a major and profession. One day, I noticed myself reading the same sentence over and over again in a textbook; my eyes were looking at the text, but my mind was saying, “Why aren’t you getting this yet? It’s so simple. Everybody else gets it. What’s wrong with you?”

When I look back upon those years, I have two thoughts: 1. That was hard. 2. What a waste of perfectly good brain cells! I could have done so many cool things if I had not spent all that time doubting myself.

But one can’t simply snap out of the Imposter Syndrome. It has a variety of causes, and it’s sticky. I was brought up with the idea of holding myself to a high standard, to measure my own progress against others’ achievements. Falling short of expectations is supposed to be a great motivator for action…or is it? Read more…

Comment
Four short links: 28 April 2015

Four short links: 28 April 2015

Mobile Numbers, Robot Growth, Business Town, and The Modern Economy

  1. Defining Mobile (Luke Wroblewski) — numbers on size, orientation, and # of thumbs across mobile users. 94% of the time, it’s in portrait mode.
  2. PwC Manufacturing Barometer: RoboticsPlanned acquisition of robotics systems over the next two to three years was cited by a maximum of 58% -– with nearly one-third (31%) planning to acquire a moderate amount (25%) or many more robotics systems (only 6%). A larger number plan to acquire a limited number of robotics systems (27%). (via Robohub)
  3. Welcome to Business Town — delightful satire. Captain of Moonshots is my favourite.
  4. The Asshole Factory (Umair Haque) — The Great Enterprise of this age is the Asshole Industry. And that’s not just a tragedy. It is something approaching the moral equivalent of a crime. For it demolishes human potential in precisely the same way as locking up someone innocent, and throwing away the key.
Comment

Google’s Physical Web vs Apple’s iBeacon

How proximity approaches compare and a look at the flourishing proximity startup ecosystem.

Register for Sean O Sullivan’s free webcast, to be held on April 29 at 10 a.m. PT.

This is the second post in a three-part series looking at beacon technology and the burgeoning beacon ecosystem.

Beacosystem_webcast_imageIn the first of this series, I covered some of the basics behind proximity, Bluetooth Low Energy, and iBeacon, and walked through some use cases where proximity and iBeacon have started showing up in retail, travel, and other applications.

While iBeacon has arguably galvanised the notion of using proximity in applications and services, it’s not the only game in town.

In this post, I’ll cover one of the alternatives to Apple’s iBeacon, Physical Web from Google, and then I’ll zoom out to look at the flurry of activity in startups in the evolving “Beacosystem.”

First, a small recap on what helped iBeacon gain so much traction, so quickly and helped shape the landscape for a proximity ecosystem to emerge.

Creating an ecosystem

Apple’s iBeacon is a layer, or a “convention,” that builds on the Bluetooth Low Energy (BLE) Standard. Apple has spurred an ecosystem around iBeacon by doing several things, which all feed into each other:

  1. Baked support for iBeacon into its mobile operating system (iOS) so that APIs are readily available for developers.
  2. Included support for background notifications at the OS level, so that push notifications can be triggered in certain situations, but without killing your phone’s battery.
  3. Provided a certification program to enable hardware manufacturers to create iBeacon-compatible hardware. This allows third-party manufacturers to provide iBeacon-compatible hardware of all shapes, sizes, and form factors, At last count, there were more than 50 suppliers of iBeacon hardware.
  4. Enabled every iOS device to be an iBeacon. This has many potential uses, from iPad-based POS systems welcoming you to a store, to the Hailo App letting you know that you can pay by Hailo.
  5. Ate its own dog food, by using iBeacon with their Apple Store App in all their US based Apple Stores.

Read more…

Comment

IBM is banking on design’s ROI

Phil Gilbert on IBM’s deep design roots, change management, and hiring for culture fit.

Ripples_of_Colour_Scott_Cresswell_Flickr

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.

Read more…

Comment

Coming full circle with Bigtable and HBase

The O'Reilly Data Show Podcast: Michael Stack on HBase past, present, and future.

stones_geralt_pixabay

Subscribe to the O’Reilly Data Show to explore the opportunities and techniques driving big data and data science.

At least once a year, I sit down with Michael Stack, engineer at Cloudera, to get an update on Apache HBase and the annual user conference, HBasecon. Stack has a great perspective, as he has been part of HBase since its inception. As former project leader, he remains a key contributor and evangelist, and one of the organizers of HBasecon.

In the beginning: Search and Bigtable

During the latest episode of the O’Reilly Data Show Podcast, I decided to broaden our conversation to include the beginnings of the very popular Apache HBase project. Stack reminded me that in the early days much of the big data community in the SF Bay Area was centered around search technologies, such as HBase. In particular, HBase was inspired by work out of Google (Bigtable), and the early engineers had ties to projects out of the Internet Archive:

At the time, I was working at the Internet Archive, and I was working on crawlers and search. The Bigtable paper looked really interesting to us because the archive, as you know, we used to host — or still do — the Wayback Machine. The Wayback Machine is a picture of the Web that goes back to 1998, and you could look at the Web at any particular time. What pages looked liked at a particular time. Bigtable was very interesting at the Internet Archive because it had this time dimension.

A group had started up to talk about the possibility of implementing a Bigtable clone. It was centered at a place called Powerset, a startup that was in San Francisco back then. That was about doing a search, so I went and talked to them. They said, ‘Come on over and we’ll make a space for doing a Bigtable clone.’ They had a very intricate search pipeline, and it was based on early Amazon AWS, and every time they started up their pipeline, they’d get a phone call from Amazon saying, ‘Please stop whatever it is you’re doing.’ … The first engineer would be a fellow called Jim Kellerman. The actual first 30 classes came from Mike Cafarella. He was instrumental in getting the first versions of Hadoop going. He was hanging around Apache Nutch at the time. … Doug [Cutting] used to work at the Internet archive, and the first actual versions of Hadoop were run on racks at the Internet archive. Doug was working on fulltext search. Then he moved on to go to Yahoo, to work on Hadoop full time.

Read more…

Comment