When I saw this image on Comical Concept I first found it funny. And then I realized how scarily true it is. It reminded me of a couple of paragraphs from Sherry Turkle’s book Alone Together:

But online, you’re slim, rich, and buffed up, and you feel you have more opportunities than in the real world. So, here, too, better than nothing can become better than something – or better than anything. Not surprisingly, people report feeling let down when they move from the virtual to the real world. It is not uncommon to see people fidget with their smartphones, looking for virtual places where they might once again be more.

It is not unusual for people to feel more comfortable in an unreal place than a real one because they feel that in simulation they show their better and perhaps truer self. With all of this going on, who will hold a brief for the real?

As a constant user myself, it would be hypocritical of me to go on a rant against social media. But I do worry about how this story plays out. What happens when we get so attached to the online places where we “might once again be more” that we get tired of being with the people around us?

Jakob Nielsen explains why saying “but it’s cheap!” is not a good excuse for the Kindle Fire’s bad user interface design:

The difference between user interface design and hardware specs is that better usability is derived from one-time expenses for user studies, design iterations, and coding – whereas beefier hardware (say, adding a camera) is a repeated expense for each additional unit manufactured.

This means that even cheap devices can have great usability because the cost of better research and design is amortized across millions of devices. This is why usability has stupendously high ROI for any big project.

I also like John Gruber’s take on the hardware/software distinction:

[T]hat’s the advantage of software over hardware. You can omit an essential feature and then hustle to get it into your first major update. Good luck adding volume buttons to your Kindle Fire.

Does this mean it’s ok for the first version of the Kindle Fire to have a low-quality UX? Here’s Nielsen again:

I understand why Amazon might want to ship a poor product in late November rather than a good product in February: they want to catch the holiday shopping season. Whether the extra sales are worth the brand damage from a low-quality user experience is difficult to judge.

Amazon has a history of doing this kind of thing. The first Kindle eReader was not a great product, and it didn’t get good reviews. But they kept at it and turned it into something truly great.

This points to one of the main differences between Apple and Amazon. Apple waits until an experience is as close to perfect as possible before they ship. Amazon gets something out there as soon as possible, but then – and this is important – they don’t just move on. They keep working at the product until it reaches an experience they’re happy with.

Both companies are very successful despite their different philosophies on when to ship a product. It proves that we should get over this idea that everyone should just copy everything Apple does. There’s more than one successful business strategy.

I’m sure the Kindle Fire will follow the same trajectory as the original Kindle eReader and become a great device. Eventually. Still, let’s not kid ourselves – the current one isn’t great.

Sometimes, you don’t need glitz; you need plumbing.

That’s Charles Arthur in Goodbye Delicious, hello Pinboard, explaining why The Guardian is dumping Delicious as their social bookmarking service. Let me ask you a question. Which of the following two screen shots is prettier?

Delicious:

Pinboard:

Delicious, right? Now let me ask you another question. Which site is more useful as a social bookmarking site? It’s ok, I’ll answer for you: it’s Pinboard.

Pinboard’s aesthetic^[1] is fairly bland, but the  sparse, table-like layout is the best way to organize the vast amount of information you collect on the Internet. The aesthetic fits the purpose of the app. But wait, there’s more. It lets you import from Twitter, Instapaper, and Google Reader (well, back in the day when Google Reader still supported public sharing). It has browser bookmarklets that work effortlessly. It integrates smoothly with a variety of RSS Readers. Sorry for the cliché, but it just works.

Meanwhile, Delicious has become slow, it has constant availability issues, and the aesthetic keeps getting more extravagant. This actually reduces its utility by obscuring the app’s core features. Social bookmarking is about two things – tagging the things you’re saving, and searching for those thing later on. That’s it. The new Delicious owners are apparently trying to turn it into something more, but whatever that something more is, I’m not buying.

Anyway, back to glitz and plumbing. As I’ve mentioned before, great aesthetic design builds trust, increases engagement, and elicits the appropriate emotional responses to a brand. But glitz is something else. Glitz is about making things shiny without asking what the thing should look like to fulfill its primary purpose.

Social bookmarking is Internet plumbing, not glitz. I now use Pinboard, and highly recommend it.

1. Time for the obligatory disclaimer. Yes, Design is about problem solving, and it includes elements such as User Research, Interaction Design, Content Strategy, Visual Design, etc. Here I am referring only to the aesthetic layer of the Visual Design component. ↩

John Barber writes about the problems with reading on tablets in Books vs. screens: Which should your kids be reading?:

The hyperlinked, text-messaging screen shapes the mind quite differently than the book, according to Wolf. “It pulls attention with such rapidity it doesn’t allow the kind of deep, focused attention that reading a book 10 years ago invited,” she says. “It invites constant change of attention, it invites multitasking. It invites, in other words, a kind of triage of attention.”

Such a skill is certainly necessary in the 21st century, she adds. “But it does not have a place in the deepest kind of immersive thought.”

I’ve definitely noticed this in myself. I get fidgety after reading a few pages on my Kindle, wondering what I’m missing elsewhere on the web. I find myself struggling to embrace boredom. It’s not a good trend.

Related: it’s a good thing I just bought this.

David Eaves wrote a great review of Clay Johnson’s new book The Information Diet:

With information, our problem isn’t that we consume too much. What’s dangerous is consuming an overabundance of junk information – information that is bad for us. Today, one can choose to live strictly on a diet of ramen noodles and Mars bars. Similarly, it’s never been easier to restrict one’s information consumption to that which confirms our biases.

In an effort to better serve us, everywhere we go, we can chomp on a steady diet of information that affirms and comforts rather than challenges – information devoid of knowledge or even accuracy; cheaply developed stories by “big info” content farms like Demand Media or cheaply created opinion hawked by affirmation factories like MSNBC or FOX News; even emails and tweets that provide dopamine bursts but little value.

In small quantities, these information sources can be good and even enjoyable. In large quantities, they deplete our efficiency, stress us out, and can put us in reality bubbles.

It looks like a considered, non-alarmist analysis of the problem, with some good practical advice on how to address it. I just bought it – here’s the Amazon link if you’d like to do the same.

When I arrived at kalahari.com in December 2010 the site hasn’t seen any significant UI improvements during the 10+ years of its existence. My job description was pretty straightforward: do something about that.

In this post I’d like to talk about the work our team did over the past 12 months to get where we are today. When I look at the site now I still see so much wrong with it – there are way too many things that we still need to fix. So this isn’t an attempt to hold up our work as some kind of standard. I’m doing this in the interest of sharing our methods and lessons learned with the larger design community. I’ve learned so much from others who have shared their stories that it seems only fair that I do the same. So here’s our journey so far.

Making sense of the landscape

Here’s what kalahari.com looked like on December 1, 2010:

If you stepped through the site back then you probably would have felt as overwhelmed as I did. Where do we start? What order should we do things in? After the first few days of having too much coffee and talking to people all over the organization I realized that we had two primary challenges:

• No formal prioritization or product development process. It was the same situation I’ve seen many times before. Requirements went straight from “The Business” to developers. That kicked off an endless back and forth about what was needed, with only a cursory nod to Design. The “First In First Out” approach to prioritization was also quite common. The result was, well, not ideal. We needed to fix this.
• No formal user experience design. This was no surprise, and it was the reason I took the job in the first place. There was no user research, no content strategy, no interaction design, and no visual design beyond marketing and merchandizing materials. This is the part that really excited me: the opportunity to introduce User Experience Design into an organization that was (to their enormous credit) hungry for it but didn’t know where to start.

So we immediately got to work on both those problems.
(more…)

I love opening the App Store to see what updates are available for my iOS apps. Sometimes I forget to go there for a week or so and as the loading spinner comes up I play a little guessing game – will there be four updates? Seven? Double figures!?

Yes, I know I need to get out more. But I do believe my irrational excitement about something so inane points to an underutilized product marketing opportunity: Software version numbers as part of a delightful customer experience.

Before SaaS and the ease of over-the-air updates, version numbers made sense. In most cases v2.0 came after v1.0, and it was followed by v3.0, or maybe v2.1 for a non-significant update. Companies like Microsoft went a little more granular, but that was usually the exception. 1985-1992 saw the release of Windows 1.01 through 3.1, with only a few point releases in between^[1].

These days, with updates and releases coming with much more frequency than it used to, it’s not uncommon to see an update screen like this one:

(more…)

Marty Cagan argues that splitting the Product Manager and Product Ownership roles into two positions is a mistake:

This approach has two common negative consequences.  The first is that there is no clear owner (neither person takes responsibility for the product), and the second is a common lack of respect or understanding between the two (the “product manager” doesn’t appreciate the technical complexities, and the “product owner” doesn’t appreciate the customer’s pain).

I agree, and I would actually go one step further. I view Product Ownership activities (representing the voice of the customer, interacting with the development team, managing the backlog, etc.) as a subset of the overall strategic Product Management position (product planning, execution, and marketing). I’ve resisted calling my team Product Owners, and prefer to say that they are Product Managers who fulfill a Product Ownership role on Agile projects.

The problem is that splitting these roles into distinct job titles also splits their goals. It’s easy for one to become all about the market, and the other to become all about internal development tasks. Instead, a Product Manager should ultimately take end-to-end responsibility for the development of product solutions that meet user goals and business needs. That’s the job. Managing the backlog and working with developers on specifications are just part of that overall function, not a thing on its own.