Ryan Singer in Identifying conflicts in a UI design:

When I’m working on a UI design I look for things that are wrong. I have to do that because ther’s no checklist of things that are “˜right’ that make a perfect product. You can’t check a requirements list and say “Yep, everything’s there!” and conclude that you made a good design. You have to look at the design itself and hunt around for problems: things that cause friction, things that aren’t clear, things that take too long, things that break expectations.

These conflicts are the heart of design. If we could just pile features one on top of the other, we wouldn’t have to do design. Design is what you do when piling elements onto each other doesn’t work. It’s the process of identifying and resolving conflicts.

This is so true. As the debate about unsolicited redesigns rage on (most recently on ignore the code), I often think about the dangers of pointing out the flaws in designs. I try to remind myself that there are most likely missing details and nuances behind design decisions that I don’t know about. As Rebekah Cox says:

Design is a set of decisions about a product. It’s not an interface or an aesthetic, it’s not a brand or a color. Design is the actual decisions.

That said, Ryan’s article reminded me that pointing out what’s wrong with a design (based on objective principles, not feelings) is the most effective way to figure out what’s right. And that process has to start at home. If we’re serious about relentless quality we have to be the biggest critics of our own designs.

The Wall Street Journal in Deluge of Content on the Web Swamps Yahoo:

As Web traffic explodes, Internet companies are struggling to profit off ads shown next to the articles, videos and other content offered to viewers.

It’s a simple rule of any market. The more information that is created, the more the value is reduced. And despite attempts to woo spending with bigger, bolder and more targeted ads, services that help consumers navigate that content, namely search, remain the big money makers online.

As I (and many others) have written before, it doesn’t look like display advertising is a sustainable business model for media sites going forward (and I think we can agree that it makes for a pretty bad user experience). This puts content creators in quite a predicament: how do you make money from producing content? The WSJ piece points to the central problem here:

“People tell me that content is king, but that is not true at all,” says Rishad Tobaccowala, chief strategy and innovation officer at Vivaki, the digital-media unit of Publicis Groupe SA. “Most people make money pointing to content, not creating, curating or collecting content.”

Although the value of pointing to content is indisputable, we need a better way than display ads for content creators and curators to make a living. And I don’t think we quite know what that looks like yet.

Alex Faaborg for UX Magazine in Debating the Fundamentals: The geographic, temporal and political nature of usability heuristics:

On the surface, usability heuristics provide a simple checklist for making any interface perfect. But what is fascinating about them is the extent to which all of the heuristics are actually in direct opposition to each other, the extent to which they are geographic and temporal, and the extent to which they expose the designer’s underlying political views (at least in the domain of things digital). Usability heuristics present a zero-sum game with inherent tradeoffs, and it is simply impossible to achieve all of the heuristics simultaneously.

This is the best UX article I’ve read in a while. Like most UX designers I live and breathe the usability heuristics, and have always been reasonably comfortable with the tradeoffs, but this article perfectly articulates the complex interplay at work.

But it’s not just a theoretical exploration, I really appreciate the thought put into the practical approach to managing these complexities:

Novice designers memorize the list of usability heuristics and try to employ them in their work. As a more experienced designer, you may have already seen a deeper dynamic at play here. Instead of using heuristics as a simple checklist, try placing pairs of the heuristics against one another in a spider graph.  Achieving every ideal isn’t possible because the pairs exist in direct opposition. Realizing this, the challenge shifts to shaping a design that captures as much surface area as it can, given all the opposing forces.

This is one of those “I wish I wrote that” articles.

There’s a scene in Hot Shots! Part Deux (shut up, we all have our guilty pleasures) where Charlie Sheen’s character (Topper Harley) rescues Rowan Atkinson’s character (Dexter Hayman) from prison. The conversation goes something like this:

Topper: Dexter, I’m here to rescue you. Dexter: You don’t understand. I can’t walk. Topper: Why? Dexter: They tied my shoelaces together. Topper: Bastards!

The joke is funny, of course, (shut up, it is funny!) because of the ridiculous nature of the claim that tying someone’s shoelaces together can somehow stop them from walking around. We look at the situation from the outside and think they’re idiots - don’t they realize they can just untie Dexter’s shoelaces?

I often think of this scene when I hear designers defend their decisions by insisting that users will “figure it out”. I hear statements like “it’s not our fault that they can’t use this feature”, and I think about users with their shoelaces tied together, unable to move. We look at them with pity in our eyes - if they could only see the obvious and untie the knot, they would have no trouble using the site.

You Are Not The User

But of course, that’s not how it works. We think users are stuck because they aren’t untying their shoelaces, while they’re actually knee deep in the cement of poor usability we put them in. We can make T-Shirts that say “I am not the user” and wear them all day long, but somehow we still manage to find a way to blame them when something goes wrong. Not cool.

We will never be able to design web sites that don’t confuse users unless we observe them using our sites, and fix the issues that uncovers. We cannot think like our users - as designers we are simply too close to the product, and way too proficient in all things web. It reminds me of something Douglas Adams once said:

A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.

There is a great post on the Agile Bits blog that talks about the difficulties of designing security systems. In one part they discuss the problem of designing for users and sum up the issue perfectly:

Security systems (well, the good ones anyway) are designed by people who fully understand the reasons behind the rules. The problem is that they try to design things for people like themselves ”” people who thoroughly understand the reasons. Thus we are left with products that only work well for people who have a deep understanding of the system and its components.

Stepping Into Their Shoes

We have to be able to step out of this cocoon of deep understanding, and the only way to do that is to regularly observe users as they make their way through our applications. Whether you take your laptop to a coffee shop and ask random people to give you a few minutes of their time, or set up full-scale usability tests, the payoff of uncovering usability issues on your application is so worth the time. What’s the upside, you ask? Matt Gemmel sums it up really well:

The biggest (and most lucrative) set of customers is ordinary people, without a computing degree or specialist knowledge. These are people with no interest in specific technologies, but only in how easily they can finish today’s tasks without reading the manual. Apple caters to that market; companies who loudly proclaim their device supports CSS3 and MPEG4 and SDHC don’t even understand that it exists.

If we can get into the heads of those ordinary people who use our products every day we’ll be able to meet their needs so much better. I agree with Jeff Gothelf on this one: test everything, regardless of its polish or fidelity:

Increasing your time with customers throughout the design and build process improves the outcome of your project by continually nudging the interface in a more appropriate direction. As an added side benefit, you also begin to build a user-centric culture within the company if it didn’t already exist ”“ a huge plus.

I’ll end with the words of Jeffrey Zeldman in Style versus design, because it articulates so well why this is such an important issue:

Not enough designers are working in that vast middle ground between eye candy and hardcore usability where most of the web must be built.

Most of all, I worry about web users. Because, after ten-plus years of commercial web development, they still have a tough time finding what they’re looking for, and they still wonder why it’s so damned unpleasant to read text on the web ”” which is what most of them do when they’re online.

Let’s realize that the problem is a little more complex than untying shoelaces. Better yet, let’s realize it’s our problem if users get stuck, not theirs. And best of all, let’s allow them to help us fix it.

There was plenty of chatter about RSS over the weekend, mainly because of this “you’re doing it wrong” article on Ars Technica.

Most of the responses I’ve seen are strong defenses of RSS, and I’m happy about that. There has been so much talk about Twitter replacing RSS that I’ve been wondering if anyone else still uses it as much as I do. In fact, because of the iPad and apps like Reeder, my RSS usage is at an all-time high.

Marco Arment argues for a combined Twitter/RSS setup:

I can follow tons of low-traffic sites and keep my reading list more diverse than if I relied only on social links, but other people ensure that I never miss anything great on the high-volume sites.

Ben Brooks has a different use case (more similar to mine) - he subscribes to lots of feeds, but he doesn’t allow the unread count to bother him. He makes a good point about not blaming RSS if you feel overwhelmed:

A tool is a tool. Should I get mad at my car because there are thousands of miles of road I haven’t driven yet to drive? No. If you don’t like RSS don’t use it. If you want to use it but don’t want to have thousands of items, then use it like Marco does. Or use it like I do and check the feeds more often.

But of course, no discussion on RSS is complete until its creator weighs in. Dave Winer blames feed readers (like Google Reader) and their insistence on showing you how many unread items you have, and asks us to separate that from the technology itself:

If you miss five days of reading the news because you were on vacation (good for you!) the newspaper you read the first day back isn’t five times as thick as the normal day’s paper. And it doesn’t have your name on the cover saying “Joe you haven’t read 1,942,279 articles since this paper started.” It doesn’t put you on the hook for reading everything anyone has ever written. The paper doesn’t care, so why does your RSS reader?

These guys all make a very good case for RSS so I’m not going to say too much more about it. I do want to add something I haven’t seen mentioned before though: using folders in your RSS reader to help manage the deluge of information. Here is a screenshot of my folder structure in Reeder:

I have a certain set of blogs that I tag as favorites, and those are the ones I read first. If ther’s time I move on to the others.

Note that I have a folder called “Large tech blogs”. The usual suspects are in there: TechCrunch, Mashable, Ars Technica, Wired… These blogs post a lot, so when the unread numbers get out of control I typically just scan some headlines and then mark all as read. With the big blogs I know that if something is really important, Twitter will tell me.

RSS will remain an important part of my workflow, and since I turn dock unread badges off, I don’t feel like my app of choice is silently judging me.

Setting up folders and actively managing your RSS feeds is hard work. But the payoff is huge for me - I can quickly get a broad overview of what’s going on in the industry without having to rely on the fleeting nature of a tweet coming across my timeline.

I’m a die-hard fan.

(By the way, if you’re interested in following my shared items, you can do so here)

The Harvard Business Review says they have proof that Henry Ford never said “If I had asked people what they wanted, they would have said faster horses.” It’s an interesting piece, but it’s the conclusion I want to quote here:

The real lesson learned was not that Ford’s failure was one of not listening to his customers, but of his refusal to continuously test his vision against reality, which led to the Ford Motor Company’s failure of continuous innovation, resulting in a catastrophic loss of market share from which it never recovered.

Translation: regardless of where your innovative ideas come from, make sure you test those ideas with users and learn from their feedback.

The iPhone might have been one man’s vision, but the way users interacted with the first generation iPhone paved the way for the iPad and the iPhone 4. They tested their vision with a real product, and then learned from it.

Back in 2004 Adam Greenfield wrote down some ethical guidelines for user experience in ubiquitous-computing settings. He starts off as follows:

Principle 1: Default to harmlessness. Ubiquitous systems must default to a mode that ensures their users’ physical, psychic and financial safety.

That might sound a little overly dramatic, but as we’ll soon see, it’s a very important principle for a designer to keep top-of-mind. Adam goes on to say this:

Principle 5. Be deniable. Ubiquitous systems must offer users the ability to opt out, always and at any point. As an absolute ethical imperative, users must be afforded the ability to make their own meaningful decisions regarding their exposure to ubiquitous perception, the types and channels of information such exposure will necessary convey, and the agencies receiving and capable of acting on such conveyance. Critical to this is the ability to simply say “no,” with no penalty other than the inability to make use of whatever benefits the ubiquitous system offers its users.

Now. Think about those principles, and then have a look at the newsletter preferences page for eBucks:

The text in the opt-out line reads:

I’m not concerned with my eBucks balance and I don’t think I should be the first to know about all the latest news.

It’s an interesting content approach taken by eBucks, and one I would argue violates both principles I quote above. They are basically making you feel out of touch (“be deniable”) and a little bit stupid (“default to harmlessness”) if you don’t subscribe to their newsletter. Are they also implying that you won’t be able to view your balance if you don’t subscribe? Probably not, but it can be interpreted that way.

Fast forward a few years after Adam’s article, and we now even have a name for this type of tactic. It’s a classic example of persuasion design:

Persuasion design doesn’t share User-Centered Design’s ethical neutrality. Instead, it makes an implicit but undeniable judgment that certain behaviours are preferable to others.

Persuasion design prioritises business goals above those of the user, and its values are irreconcilable with empathy, the central value of User Experience.

This is just one example, but you can see it everywhere. It might seem innocent at first, but it’s such a slippery slope to the evil of dark patterns. We need to consider the implications very carefully before we employ such techniques.

Frank Chimero on why designers should learn to code:

Design decisions are not only affected by the characteristics of the content being designed, but also the qualities of the format. The best way to understand the characteristics of the web is to speak its language.

Good design and good markup provide structure to content. Good markup is a fundamental part of good design: beautiful on the inside, beautiful on the outside. HTML and CSS give another venue to provide structure to content in the native language of the web, and learning these guides decisions by surfacing the affordances of the medium. Design decisions are affected by both the content and the format, like how a sculptor would make different decisions if she were working with clay rather than marble.

Spot on. The whole post is worth a read, and Frank gives some good suggestions for resources to help designers get started on coding.

A couple of weeks ago our 2-year old daughter threw my wife’s phone in the swimming pool. The resulting journey through the Vodacom customer service labyrinth to replace the phone was frustrating, but it also gave me a new level of understanding and empathy for the immense challenges of providing customer service to hundreds of thousands of people.

This is an article about social media, customer support channels, and the principles every company should establish in their culture to serve their customers better. And (spoiler alert!) I do manage to get a new phone for my wife.

”Umm, So, Our Daughter Threw My Phone In The Pool”

What’s most surprising about getting a call about my wife’s phone suddenly finding itself at the bottom of our pool is how completely nonplussed I was about the whole thing. When you become a parent the kinds of things that upset you change significantly. I think I’ve discovered a pattern: if there is no blood involved, there’s really no reason to get upset. So after establishing that there was no blood involved, I proceeded to the next step - trying to replace the phone.

My wife had an LG Generic (or whatever it was called) on one of Vodacom’s cheapest plans, and the thing has been driving her nuts. She’s had her eye on my iPhone for a long time, so I decided to try to upgrade her. The problem is that I’m not eligible for an upgrade until the end of December. And that’s where this journey starts.

My first step was to walk into a Vodacom store to ask for assistance. This is pretty much the extent of the conversation that took place with the support representative:

Me: “Hi. My daughter threw my wife’s phone in the pool, so I’d like to get her an iPhone please.” Rep: “Your contract isn’t due for an upgrade until the end of December.” Me: “I understand that. I’m saying that my wife’s phone is now wet and doesn’t work any more, so I would like to give you more money by going onto a more expensive plan.” Rep: “It’s against policy to do an early upgrade. That’s why you should insure your phone.”

Imagine that conversation with a “Sucks to be you!” look on the representative’s face, and you’d have a really good idea of how it went down.

Having failed with the first point of contact, I took to Twitter:

The response was very quick, asking me to DM my number so that someone could call me. I sent my number, and a representative called me the next morning. I thought this was getting somewhere, and I was already starting to write this post in my head. My headline (“Social media works!”) needed some work, but it was going to be great.

But not so fast”¦ I told my story to the representative, who looked up the account and told me the same story: “Sorry, it’s against policy.” (At least this time someone was sorry about it). I threw out what would become my standard line throughout this process: “You realize I’m trying to give you more money, right?” But no luck. The conversation ended when the rep told me, “I will ask the upgrades department if there is anything we can do.” Translation: “You’ll never hear from us, ever again.”

After not hearing from the “upgrades department” I sent another DM, and got a call from another rep. Same story. Against policy. “You realize I’m trying to give you more money, right?” Sorry, against policy. I then took it to the next level and told the rep that I will be taking my business to MTN, convinced that this statement would trigger some script alarm somewhere and get me a free ticket to a ride up the “escalation path”. Not so much.

Rep: “Oh. Well that’s not good.” Me: “No, it’s not. Anything you want to do about that?” Rep: “Well, this is our policy. Can’t be changed.” Me: “You don’t want to tell someone that I’m about to take my business elsewhere?” Rep: “I’ll make a note in the system.”

At that point I gave up and decided to wait until I am eligible for an upgrade. That decision lasted about 3 days. I decided to give it one last shot, and tweeted Vodacom’s CEO:

And this is where the story gets boring, in a good way. Pieter Uys tweeted me back (in my first language, which means he looked at my profile and thought before responding). 4 hours later I got a call to say we can do the upgrade. End of story. No questions, no statements about policy. I can do the upgrade = happy customer + more money for Vodacom.

Your Call Is Not That Important To Us

Before moving on to the main point of this article I want to tell another quick story. I’ve been banking with ABSA all my life. I’ve also been unhappy with ABSA all my life, but that’s a story for another day. I recently mentioned ABSA on Twitter and linked to this post. The post got retweeted a few times, and then I got this:

That really interested me. Here is a bank (FNB) that monitors what people are saying about their competitors, and joins the conversation in relevant ways. Notice that he wasn’t pushy, he was merely getting in on the joke. I tweeted back:

I said this would be a short story, so I’ll just say this. One week later someone from FNB was sitting with me, filling out forms to transfer all my accounts from ABSA to FNB. They took care of the whole thing, I didn’t have to fill out a single form. All because of a tweet. And I’m pretty sure ABSA doesn’t even know (or care) that they lost another customer.

It’s All About The People

All customer support revolves around people, processes, and tools.

CRM and community tools like Salesforce, Get Satisfaction, and Twitter give support reps the means to communicate with customers. Processes set guidelines for what those interactions should be like. But all of that is useless unless the people doing the support understand and live out the culture of the organization. The ease of establishing that culture also depends a great deal on the support channel used.

Synchronous, 1:1 support like in-store interactions and phone support is expensive and extremely difficult to manage. Unless you’re Zappos and call yourself “a support company that happens to sell shoes”, most companies don’t have a deeply ingrained support culture. So it’s very hard to filter the right processes and culture through to the 1:1 support channels, since they are generally pretty far removed from “management”. They are therefore very rarely empowered to make decisions that might not follow policy, but would be the best thing for the customer (and the company).

I would argue that my early upgrade situation is a good example of this. That representative in the store should have been empowered to ignore policy and upgrade me on the spot. It’s not her fault that she’s not allowed to do that, it’s just the way it is.

On the other hand, asynchronous, 1:many support like live chat, online forums, and social media platforms are much cheaper, and I would argue also easier to manage from a support culture perspective. You’re able to set appropriate guidelines (more on that later), and in general the people who manage those channels have a much more direct path to different resolution scenarios (and therefore more decision-making power).

All this to say that I am not upset any more about my bad experiences in the store and initially on the phone. Because I recognize how incredibly difficult it is to nurture a true culture of customer-centric support. And to find that balance between empowering everyone in the company to break policy when they feel it’s needed, while still having enough process in place so you don’t give away control of your short-term and long-term business strategy.

I don’t have an immediate solution for this, but I want to write about it because I believe it’s a very real problem that a lot of companies are struggling with. Especially now that social media support channels are getting so much adoption.

Lessons In Customer Service

Even though I don’t have the perfect answer, I do want to spend a little time discussing some recommendations I have for better customer service, based on my recent experiences with FNB and Vodacom.

1. Understand what engagement really means

There is no substitute for authenticity. When Pick n Pay asks what I’m going to be doing today, it doesn’t feel like real engagement. Why would I want to tell a supermarket that? When Vodacom sends me the scripted answer “I heard about the problem you experienced”, that tells me they didn’t really take the time to think about the response when sending it (“Well, of course you heard about it, I sent you a tweet!”).

When FNB joins a conversation in a natural way, or when the CEO of Vodacom responds to me by name - that’s engagement. It’s such a simple rule: read, think, respond like a human.

2. Web governance is essential

Web governance “defines decision-making processes for the web, and sets policies and standards for web content, design, and technology””in a way that respects subject-matter expertise” (from Web Governance: Become An Agent of Change). Defining user-centered standards for every touch point with an organization is enormously important to those who want to succeed, and it’s not getting enough attention at all.

One part of web governance that needs more attention in particular is content strategy, which “plans for the creation, publication, and governance of useful, usable content” (see The Discipline of Content Strategy for more). Among other things it defines the tone and language and underlying principles for talking to customers. Every company should do this before they open their Twitter account or create a Facebook page. (Btw, if you’re in South Africa and need help with stuff like this, talk to Kerry-Anne)

How you talk to your customers makes a huge difference to their experience, and if you don’t define a strategy for it, your community will define you and you’ll have no control over it. That’s not a good place to be.

3. Empower support representatives

I want to come back to this. As mentioned earlier, I recognize how difficult it is to walk the line between empowerment and total loss of control. But I think there are ways to test this out as a strategy without giving the whole house away.

Start with one specific department, call center, or representative. Allow them to make some decisions based on what they feel is right for the customer and the company, and see what happens. If they break some rules/policy, ask them why they did it, and follow up with the customer to see how they felt about the exchange.

This kind of empowerment isn’t a binary switch for the whole organization. Start small, test, and see if it might be possible to build a culture that encourages doing The Right Thing.

All’s Well That Ends Well

My story had a happy ending. But I know there are an enormous amount of customer support stories that don’t end that way. The rise of cheaper, more efficient channels for customer support can make experiences better not just for customers who engage in those channels, but for everyone. We can take the lessons from the asynchronous channels and apply them to the 1:1 interactions.

Be authentic, get in on the joke, and break some rules every once in a while. Because they did that, FNB has a new customer and Vodacom didn’t lose one. I think that makes it worth it.

In There Will Be No Files In The Cloud Fred Wilson argues that file-based cloud computing will become a thing of the past:

This is why I love Google Docs so much. I just create a document and email a link. Nobody downloads anything. There are no attachments in the email. Just a link. Just like the web, following links, getting [stuff] done. I love it.

That’s the future. I’m pretty sure of it.

He has a point, but I think it’s important to clarify what he means by “file”. Sorry to go all Wikipedia on you, but I promise ther’s a point on the other side. Wikipedia defines a computer file as follows:

A computer file is a block of arbitrary information, or resource for storing information, which is available to a computer program and is usually based on some kind of durable storage. A file is durable in the sense that it remains available for programs to use after the current program has finished.

The point being that a file is a block of data that is accessible to the programs that need it. Based on that definition files are certainly not going away, because software will always need access to the data that makes it more than a pretty shell.

What is going away though is the need for users to care about files: where they’re located, what file extensions work with what, etc. The best example currently in the wild is probably Notational Velocity, a text editor for the Mac where you don’t need to worry about where your files are located. From the web sit’s description:

The same area is used both for creating notes and searching. I.e., in the process of entering the title for a new note, related notes appear below, letting users file information there if they choose. Likewise, if a search reveals nothing, one need simply press return to create a note with the appropriate title.

Those files still exist, you just don’t have to go into Finder and start a search from there. Ther’s no File | Open command because it’s not needed. The data is in the app, and you interact directly with it. So if that’s what Fred Wilson means by saying “That’s the future. I’m pretty sure of it.” then we agree. But if he means that w’ll lose the “computer file” as an entity, I disagree. Fred ends his piece with this:

So if you are working in the cloud storage space, I think you’ve got a bit of a conundrum. The reality of the market today is that people use files. You need to support that use case, enhance it, and make peopl’s lives easier. But over time, that use case will go away. And what people will want is a service that doesn’t have files as the atomic unit.

I don’t think it’s that big of a conundrum. Notational Velocity doesn’t care where I store my .txt files, but I happen to store them in Dropbox. It doesn’t mean I now have to think about my files and wonder if they’re ok over there. It just means that the app pulls its data from a folder in Dropbox.

So taking that example all the way to the future of the computer file, this could be a great selling point for cloud storage companies: we host your files/data so that your apps will work anywhere and on any computer. (Ok, that sentence might need some Marketing magic, but you catch the drift).

Even if manipulating files becomes a thing of the past, data isn’t going anywhere. BBEdit 10 is already going down this road - they are encouraging users to sync application support files with Dropbox so you can easily maintain multiple installs. My guess is that many apps will take this approach where they add seamless data syncing to their offering without having to go into the cloud storage business themselves.

We don’t have to kill files. We just have to build apps that allow users to stop thinking about them.