Yesterday I received an email from the New York Times in which they told me, “Our records indicate that you recently requested to cancel your home delivery subscription.” They proceeded to use a phrase that bears an uncanny resemblance to something I told a girlfriend who dumped me when I was 15: “We do hope you’ll reconsider.”

Here’s the problem: I canceled my subscription 3 years ago. No big deal though, mistakes like this happen all the time. I hit the Archive button and forgot about it. But this morning I woke up to another email from the Times, this one with the subject line “CORRECTION: Important information regarding your subscription.” One of the paragraphs read as follows:

This e-mail was sent by us in error. Please disregard the message. We apologize for any confusion this may have caused.

I find passive voice non-apologies like this frustrating and insulting - worse than the original mistake, because it somehow manages to avoid taking responsibility for what happened. And it looks like I can finally move on from the idea that I’m the only one who feels this way. Here’s Clinton Forry:

“This e-mail was sent by us in error.” -New York Times email. I’ll just sit here and wait for an apology for that use of passive voice.

”” Clinton Forry (@wd45) December 28, 2011

And John Holdun:

JUST ONCE I’d like a big company to omit their “We apologize for any inconvenience this may have caused” in favor of a “Sorry.” ”” John Holdun (@johnholdun) December 28, 2011

In Subscribing to The New York Times, a post about the paper’s subscription pricing, Khoi Vinh alludes to a recurring pattern in their email communications:

In the run up to my subscription expiring, the company had been sending me promotions that were urgent in their warnings but exasperating in their vagueness. Each email was unequivocal about the number of days that remained in my subscription, but the renewal rates were only hinted at.

“Urgent in their warnings but exasperating in their vagueness.” That’s a great description.

This is a big deal. Content Strategy has become mainstream, and more and more businesses are finding out that it’s more effective to talk to their customers like real people (and get to the point quickly). Yet too many old school companies continue to speak to us in that patriarchal tone, assuming that since they clearly know what’s best for us we’ll just go ahead and click that “Buy now” button (if we can find it, because we’re not that smart you see). That’s why the Times didn’t just say this in their “apology” email:

Yesterday we made a mistake and sent you an incorrect email about your subscription. We’re sorry about that. You can delete the email.

The problem is that we’re starting to notice when we’re being talked down to. This has very real implications for marketing, where traditional slogans like “Your savings start here!” and “Unbeatable service!” lose their power to pull the wool over our eyes if they’re not backed up by something real. I recently lamented the laziness of the slogan “Everything you could ever want. And more. For less.” I wondered what it would cost for some happiness and a toilet made out of solid gold, because if you take that slogan at face value I should be able to get that, right?

The lesson to companies is simple: We’re smarter than you think. Be honest about the product or service you provide, and just say “sorry” when you made a mistake. We’ll love you for it.

I know I shouldn’t write meta-posts. I really enjoy reading such posts by the writers I follow, but for some reason it feels presumptuous of me to do the same. But hey, it’s the end of the year and no one is reading anything anyway. So I thought I’d let you know about two things that have been on my mind about my writing here.

Disagreeing

I enjoy arguing. But I mean that not in the way most of the Internet means it. I mean it in the way the Dictionary means it:

Give reasons or cite evidence in support of an idea, action, or theory, typically with the aim of persuading others to share on’s view.

I don’t just enjoy writing such arguments, I also enjoy reading them - particularly if someone is making an argument against one of my opinions. But I really dislike mean-spirited fights online, so much so that I’ve had to close comments on a couple of posts this year because things just got too rowdy.

After particularly contentious fighting in the comments section of a post I usually vow to stick to writing non-controversial stuff, but before I know it I’m back to arguing (again, in the sense of “giving reasons in support of an idea”). I finally realized that I should just run with that instinct and not try to censor myself. But from here on out I’m going to set very specific rules for myself on how I’m allowed to argue. And for that I turn to Paul Graham.

In his brilliant post How to Disagree, Paul goes through what he calls the “Disagreement Hierarchy”, or “DH”. I’m not going to restate what he said - you should definitely click through and read that post. I’ll just say that my commitment to myself (and to you) is that I will always argue/disagree at levels DH5 or DH6 of the Disagreement Hierarchy. As Paul says, it results in better arguments and happier people:

But the greatest benefit of disagreeing well is not just that it will make conversations better, but that it will make the people who have them happier. If you study conversations, you find there is a lot more meanness down in DH1 than up in DH6. You don’t have to be mean when you have a real point to make. In fact, you don’t want to. If you have something real to say, being mean just gets in the way.

Arguing (yes, in the Dictionary sense of the word) is important because we all learn from it. But we have to rise above name-calling (DH1) and skip all the other levels to a point where we do the hard work and disagree in a way that moves the conversation forward. That’s what I hope to do here.

Comments

Oh, comments. I’ve gone back and forth on this so many times. Sometimes I leave comments open, other times I close them. Sometimes I close comments on a post, get called out on Twitter about it, and then open it up again. It’s confusing and it’s causing me headaches. So I’ve made a decision to close comments on all posts, at least for a month or so, or until someone writes a convincing argument on why sites should have comments (please use DH5 or DH6 in your argument).

To me, the most convincing argument yet to not having comments is Matt Gemmel’s post Comments Off. I can’t say it better than he did, so please go read his thoughts on the issue. For me, the biggest reason is what Matt calls the burden of moderation. It takes a really long time to moderate comments, especially if a post gets popular while I’m sleeping and I wake up to 40 comments that I have to read through to make sure no one called someone else an idiot. As Anil Dash said, if your website is full of assholes, it’s your fault, so moderating comments is not something you can just ignore. It has to be done.

I’ve had to get up at 5am way too many times to spend an hour deleting comments and asking people to be nice to each other. That’s time I could have spent (1) sleeping, or more importantly, (2) writing something new. So I’m going to give the no comments thing a go and see what happens.

As Matt says in his post, this doesn’t mean I don’t want feedback. We’ve already established that I enjoy arguing, so I also enjoy reading peopl’s counter-arguments (or support, of course). So like Matt, I also hope to get the following types of feedback:

• A tweet to let me know if you agree/disagree and why.
• A post on your own site using DH5 or DH6 to agree/disagree with something I said.
• An email if you don’t want to say anything publicly.

I will link to responses that are DH5+ and add to the conversation (even if it makes me look stupid for writing something). I’m not turning off comments to discourage engagement disagreement, I’m turning it off to help me sleep better and give me more time for writing (this is a side project, so I need all the extra time I can get).

2012

So those are some of my thoughts about what you might see here in 2012. For bonus points, go read this excellent post on how to make a better Internet, and what to do about things that annoy you. For me, lesson #9 will probably become my writing goal this year:

Stop reading bad writing. Keep writing good writing.

I’m not there yet, but I do enjoy trying. Thanks for coming with me.

I don’t like anonymous sources, but this post by “a former CTO [who] was briefed on Facebook’s advertising strategy” caught a lot of people’s attention last week. This paragraph, in particular, stands out:

What most users don’t know is that the new features being introduced are all centered around increasing the value of Facebook to advertisers, to the point where Facebook representatives have been selling the idea that Timeline is actually about re-conceptualizing users around their consumer preferences, or as they put it, “brands are now an essential part of people’s identities.”

Brent Simmons had a very succinct response to that last quote:

Pukin’

I agree.

John Gruber then linked to a page that Facebook set up to explain how they make money. Facebook says that it now costs over a billion dollars a year to keep the site running. That’s a lot of money, for sure. But it’s a damn shame that advertising appears to be the only viable way for Facebook to foot that bill.

Facebook says that they have over 800 million active users, and that “more than 50% of our active users log on to Facebook in any given day.” So let’s, for argument’s sake, say that about 500 million users visit Facebook every day. If each of those users paid Facebook $2 per year, the revenue would cover the cost of running the site. Just increase that to $3 per year, or 25c per month, and you suddenly have $1.5B revenue per year (or roughly $500M profit, based on Facebook’s rough estimate of their operating costs). Let’s be clear about this: it’s the cost of one coffee per year.

Yes, of course this is naive - it would never happen. Most people aren’t willing to pay for services or content on the Internet. There is an expectation that everything should be free, and that at the same time, companies should respect our privacy and keep The Brands™ away from our personal information. It’s not a realistic expectation - something’s gotta give if no one is willing to pay for anything. But most people don’t think about it long enough to realize that.

A recent article on the Pinboard blog really resonated with me, and by the way it spread on Twitter I know it struck a chord with a lot of others too. From Don’t be a free user:

What if a little site you love doesn’t have a business model? Yell at the developers! Explain that you are tired of good projects folding and are willing to pay cash American dollar to prevent that from happening. It doesn’t take prohibitive per-user revenue to put a project in the black. It just requires a number greater than zero.

In Facebook’s case that “number greater than zero” is $3 per year (have I mentioned that it’s per year!?). But the non-geek world just don’t think about these things. They don’t think about designers and developers who create apps and need to be compensated for it to keep a service alive. They feel that 99c is too much to pay for an iOS game. They freak out every time Facebook moves some things around, still blissfully unaware that they are not Facebook’s customers, they’re just the product being sold to advertisers. All they want is their free Facebook so they can “inbox” their friends about tomorrow’s party. “Pay for this thing?”, they say. “Screw that - it’s not my problem how you keep the site up. Oh, by the way, just remember that you have to respect my privacy and you can’t show me any advertising.”

It’s terribly frustrating.

I fear we’ve painted ourselves into this free corner, and the only way out is to sell our identities to The Brands™. Steve Jobs alluded to this in his negotiations with the New York Times when he refused to give them access to user information Apple collects in the App store. From his biography:

If you don’t like it, don’t use us. I’m not the one who got you in this jam. You’re the ones who’ve spent the past five years giving away your paper online and not collecting anyone’s credit card information.

We created this culture. We’re the ones who have been giving stuff away for free for the past decade, not collecting anyone’s credit card information. We’ve conditioned users that everything should be free, always. This gives advertisers the upper hand in any negotiation, because they know that their way is the only way that most sites can make money.

Why is this such a big deal? Relevant, contextual advertising isn’t bad, right? Not in moderation, no (see The Deck). But when ads become the only way out and advertisers are the ones calling the shots, users suffer. Also, as a matter of principle I firmly believe that it’s better to pay the makers of things directly than through some convoluted ad system.

We can’t really blame Facebook for choosing this path of least resistance. It’s the hand they were dealt by the culture we’ve created. But I remain hopeful that new services will charge for what they do so that we can slowly begin to define our own identities without The Brands™ trying to tell us who we are.

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.

Hello, I’m a Product Manager

Introducing a Product Management layer into an organization that’s used to working without it is tricky. If you do it wrong it can become a political nightmare and end up ruining your chances of shipping anything good. You might have the best of intentions, but there is always the danger that the only thing people will think when they look at a Product Manager is, “Hey, I used to be responsible for that, jackass!”

We certainly didn’t make this transition perfectly, but I believe the key is to make sure that you talk to as many people as possible about what their organizational issues are, and how they think it can be done better. You have to take the time to explain the benefits of having a Product Team that takes responsible for strategy, vision, and execution of a product (and takes the fall if it fails). And then, most importantly, you have to make the development process fair[1].

We now have a team of Product Managers who are responsible for delivering measurable business results through product solutions that meet both market needs and company goals. They work closely with their teams to develop the strategy and vision for their products. They ensure that designers and developers are included throughout the process. And most importantly: they make sure we ship.

The Intergalactic Product Force

One concept we introduced that I think is worth talking about is the Product Council[2] - a formalized way to deal with prioritization.

The Product Council is made up of the heads (VPs) of every department in the organization: Engineering, Marketing, Support, Category, etc. We have a weekly meeting where we discuss the current product roadmap and priorities. We ask ourselves, Are we still working on the most important things? If something more important comes up, we prioritize it higher in the roadmap, and something else shifts down. If w’re happy with the direction, we do nothing. If a new opportunity arises we ask ourselves, Is this more important than what w’re working on right now? Or is this something we should work on next? If so, what moves down in the priority list?

From here, I communicate any changes to the Product Team, and we discuss this to make sure no one missed anything. But then — and this is important — the Product Manager has complete autonomy and ownership over the implementation of his or her roadmap. The Product Council sets the priorities (with input from all parts of the organization), but the Product Managers work with their development teams (and others) to set the timeline, the implementation details, the design, everything.

Ther’s more to it, but in the interest of brevity I’ll stop there. This process has three main advantages:

• It gives the management team complete transparency into what the Product team is working on, and it allows for anyone to make the case for a change in priorities. Why this kind of transparency is so essential is a subject for a different blog post, but in short, it takes away a vast majority of the politics you see in many organizations, and it frees up the teams to do what they do best — execute.
• It prevents scope creep. Nothing can go on the roadmap without something else moving out or down. As anyone who ever worked at a large organization knows, this is an absolutely critical part of a successful development cycle.
• It gives the Product Manager and their teams what they need to be successful: direction and autonomy. As Jocelyn Glei says: “Give your team members what they need to thrive, and then get out of the way.”

Hello, I’m a User Experience Designer

I knew that we needed to build a great team if we were going to follow a user-centered approach to identifying and addressing the main issues on the kalahari.com site. But building a team takes time and money, and it’s hard to justify a large headcount request before you’ve proven that you can have a real impact on the business.

So we started small. I fulfilled the UX Design role, and we hired one visual designer since that was the primary need at that stage. Then we got stuck in. On a site of this size, and with the pressure we had to make improvements quickly, we decided on a dual approach:

• Make some initial and obvious changes to the visual design to improve hierarchy and the general aesthetic.
• At the same time, work on a long-term UX strategy to address some of the more fundamental user experience issues on the site.

The goal was to show quickly that we know what we are doing, and then use those successes to build out the team further and attack the areas where we can have the biggest effect on conversion rates.

Building a roadmap

We started this process with a small team of three Product Managers and two Designers, so we didn’t initially have the luxury of user research and a long period of product discovery to build out a roadmap. Instead, we went offsite for a day and built a customer experience map for our different user journeys. It was a great way to focus on what the core experience is that we need to improve.

We also went a bit further. Based on a heuristic evaluation of the site we annotated each of the steps in the user journey with obvious improvements we could make. This gave us a flexible framework for the year, and guided our roadmap throughout.

We decided early on to realign, not redesign. Our approach was to make relentless incremental progress as opposed to doing a 6-9 month project with a big bang release[3]. Our goal was to release every 3-4 weeks, depending on the size of the project.

In our first two releases we took care of some basics. I won’t bore you with the whole list, but here are the highlights:

• Released a new header and footer.
• Shifted from heavy reliance on orange to a more muted color scheme that allows products to draw more attention.
• Removed several links in the header and footer that didn’t get much use.
• Increased the visual hierarchy of Search.
• Decreased the visual hierarchy of several non-important features.
• Introduced a formal button strategy (primary=orange, secondary=silver).
• Moved from liquid width to a 960px 16-column fixed width design (including the ability to do single-column or two-column designs - every page used to be three columns).
• Started to separate CSS from HTML (better late than never, right?).
• Started to build a UI component library.

These changes had exactly the desired effect. User response was immediate and universally positive. In combination with some good specials, traffic started to increase. And most importantly: we were able to start growing our team to add designers, a researcher, and a front-end developer. Game on.

We spent the rest of the year systematically working through our customer experience map, starting with the most important areas where improved UX can have the biggest effects (Registration, Checkout, Product Details Page, etc.). Our process grew organically and ended up hitting a good stride towards the middle of the year:

• Define the area we’re working on, and define what success looks like (what are the metrics we’re trying to improve?).
• Work in small teams of PM’s, Designers, and Developers to sketch out new flows and develop wireframes.
• Test wireframes with users, utilizing the RITE method so that the outcome is improved designs, not PowerPoint decks with recommendations.
• Refine the designs as they evolve into high-fidelity visual designs (with more user testing as required), and deliver high quality HTML and CSS as the final output.

The outcome is a site that is drastically different from where we were a year ago, with real improvements in the success metrics we set for ourselves (% conversion on registration, checkout, and other flows). The changes include not just the main site, but also a brand new mobile-optimized version, as well as some significant changes to our Marketplace for 3rd party sellers. Here’s just one sample of our Checkout redesign, including one of the initial wireframes[4].

Old Checkout:

New Checkout:

Initial wireframe:

Final design:

Three more things

My biggest regret about this year is that we couldn’t do more. We made some great improvements to the site, but it is still so far from where it needs to be. And I know everyone on the team feels this way. We set out to build a culture of quality above all else, and it physically hurts when you have to make compromises and do something that’s counter to that culture. Before you jump in and say that there’s never an excuse to compromise, let me remind you of something Erin Kissane said in What I Learned About the Web in 2011:

If a single idea has followed me around this year, from politics to art and work to friendships, it’s been this one: “it’s more complicated than that.”

It’s centrally important to seek simplicity, and especially to avoid making things hard to use or understand. But if we want to make things that are usefully simple without being truncated or simplistic, we have to recognize and respect complexity — both in the design problems we address, and in the way we do our work.

So, yes, I agree with you - you should never compromise on quality. But it’s complicated. You sometimes run into technical and business complexities that force you to say, “We’ll have to do this later.” It sucks, but that’s life.

I’m exiting this year with three major takeaways - lessons learned and re-learned through our successes and failures:

• Love your developers. Too many companies see their developers as “resources” whose only reason for existence is to make The Codes. When you pull developers into product planning and design, everything changes. You build better products, and everyone has more fun.
• User Experience Design is a real thing. I saw way too many dismissive comments about UX this year. If you do it right, it will improve conversion rates and/or make more money. If you don’t believe me, come sign an NDA and I’ll show you our metrics.
• Culture is everything. In one story out of the Steve Jobs biography, Bud Tribble (one of the Macintosh team members) is quoted as saying, “Hey, if w’re going to make things in our lives, we might as well make them beautiful.” You need a team that has a relentless focus on quality. A team that cares enough to fight for moving that button 3px to the left. It’s the only way to find real meaning in your work.

We have a lot of work to do on our site (sorry, did I mention that already?). But I’m happy that we’ve been able to introduce a fair and effective product development process into the organization. We made user experience an intricate part of how we build product. And we now have a 14-person team of brilliant and dedicated Product Managers and User Experience Designers who care deeply about the product.

It was a good year.

---

1. I wrote more about this in The most important characteristic of a good Product Manager  â†©
2. No one liked my “Intergalactic Product Force” suggestion â†©
3. I wrote more about this for Smashing Magazine in The Data-Pixel Approach To Improving User Experience  â†©
4. I’ll spend some time over the break putting together some more before-and-after shots, including stories about the process we followed (if anyone is interested) ↩

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:

Since there is no common standard for version numbers, it’s not easy to tell which of these updates are significant without going into the release notes for each one. I can guess that Google+ 1.0.4.2326 and Skype 3.5.84 are bug fix releases, but I can’t tell for sure. I have a feeling that Wordpress 2.9 is a fairly big release, but is it in the same order of magnitude as Feeddler 1.11? No idea. Especially since sometimes a seemingly big point release turns out to be pretty unexciting:

Jeff Atwood is full of praise for the virtues of continuous software updates, and I agree with him. In The Infinite Version he explains how he stopped caring about version numbers after an experience with Google Chrome:

Chrome’s version number has been changing so rapidly lately that every time someone opens a Chrome bug on a Stack Exchange site, I have to check my version against theirs just to make sure we’re still talking about the same software. And once - I swear I am not making this up - the version incremented while I was checking the version.

From a software development perspective frequent software updates are great - you’re able to iterate rapidly and respond to bugs quickly. However, I think this continuing disregard for sensible version numbers is a mistake. We are missing out on an important part of the customer experience: that excited feeling that goes along with getting something new. For paid apps especially, giving users new features “for free” has the potential to delight them and build long-term loyalty. But how will they easily know that they’re getting something new without the visual cues of well-defined version numbers?

There is probably no easy fix for this. We can’t just send the Internet a memo that this is now how we’re doing things. But I hope that software developers will at least start seeing version numbers as part of their product marketing efforts. It would also be helpful to adopt a simple, rough guide to version numbers:

• x.0 for major redesigns or a re-imagining of the application (such as Path 2.0 and Instapaper 4.0)
• x.y for the addition of significant new features
• x.y.z for bug fixes and minor improvements

If we don’t go deeper than three levels (even if z is a four-digit number) and all developers adopt this basic taxonomy, users will eventually start recognizing the pattern. This will give them the necessary cues to understand and appreciate app updates. They’ll know to click through and read the release notes for x.0 and x.y release, but that it’s probably not necessary to bother with x.y.z releases.

This naturally leads into a discussion about the importance of writing good release notes to go along with a consistent version number strategy, but that’s beyond the scope of this article. I’ll just leave you with an example of an app that sees release notes as part of their”¦ um”¦ “brand experience”?

---

1. Of course, after 1995 all hell broke loose. Wikipedia lists monstrosities such as Windows 95 USB Supplement to OSR2, Windows XP Professional x64 Edition, and Windows Server 2008 R2 for Itanium-based Systems. ↩