AT&T: You’re on notice

AT&T just announced in an investor’s conference that smart phone users are using too much of its network for data and that something is going to have to be done to curb their usage since their network isn’t able to handle it. All I can say is WAH-WAH-WAH.

Let me get this straight. AT&T has an issue that their network is slow, which clearly is not the fault of the network but is the fault of the users of the network. So, instead of upgrading their network or preparing for the introduction of more smart phones which are going to cripple their network further, they are going to do something punitive to get smart phone users to download less data. And is their plan to do this while still continuing to charge $40/month for data service? They could offer tiered pricing to people so that some can opt into a lower price plan for more limited data, but charging users who are already paying $40 for apparently subpar unlimited service doesn’t seem fair.

As you can tell, as a user advocate, I think this is absurd. Problems with your product are never the fault of the customer. They are your fault.  And, most importantly, if you are AT&T and ACTIVELY PROMOTING all the awesome apps and great things you can do with the iPhone while then complaining that people are using them too much, you don’t have a leg to stand on.

This behavior is not acceptable for an organization with a lot of competitors (rumored to be losing its iPhone exclusivity soon) that sells a service. Your goal as a product manager, engineer, designer, CEO, etc… is to make your users happy and not think of ways to save money by pissing them off.  It may save money in the short term, but if your business is selling a service, there should be a high level of service involved.

This is a new announcement from AT&T but I predict it is going to lose them customers in the long run. In the words of Stephen Cobert, AT&T you’re on notice.

  • Share/Bookmark

Categories: Technology/Software

Tips for Improving Greenbox’s Energy Portal

A recent SmartGridNews.com article praised Greenbox Technology for “deliver[ing] understanding to utility customers.” While Greenbox does provide useful functionality that differentiates it from its competitors, key improvements to its interaction design would go a long way to provide a better overall user experience.

1_greenbox_original

The Good

To be fair, Greenbox does deserve a gold star for displaying energy data specifically in dollars ($).  As I mentioned in an earlier post, consumers don’t understand energy units, such as kWh, and are motivated to change their behavior by saving money.

costs_dollars

The Not So Good

But, what about the rest of the Greenbox design?   Greenbox gets caught up in the same usability pitfalls I’ve seen in other consumer energy portals as well –too much information and not enough direct reference to the things that matter most to users.  Here are my top three suggestions to help Greenbox, or any consumer energy portal, deliver an excellent user experience:

There's More...
  • Share/Bookmark

Categories: Interaction Design, Review

Which Metrics Equal Happy Users?

One of the greatest tools available to me as an interaction designer is the ability to see real metrics. I’m guessing that’s surprising to some people. After all, many people still think that design all happens before a product ever gets into the hands of users, so how could I possibly benefit from finding out what users are actually doing with my products?

Well, for one thing, I believe that design should continue for as long as a product is being used by or sold to customers. It’s an iterative process, and there’s nothing that gives me quicker, more accurate insight into how a new product version or feature is performing than looking at user metrics.

But there’s something that I, as a user advocate, care about quite a lot that is really very hard to measure accurately. I care about User Happiness. Now, I don’t necessarily care about it for some vague, good karma reason. I care because I think that happy users are retained users and, often, paying users. I believe that happy users tell their friends about my product and reduce my acquisition costs. I truly believe that happy users can earn money for my product.

So, how can I tell whether my users are happy? You know, without talking to every single one of them?

Although I think that happy users can equal more registrations, more revenue, and more retention, I don’t actually believe that this implies the opposite. In other words, there are all sorts of things I can do to retain customers or get more money out of them that don’t actually make them happy. Here are a few of the important business metrics you might be tempted to use as shorthand for customer happiness – but it’s not always the case:

Retention

An increase in retention numbers seems like a good indication that your customers are happy. After all, happier customers stay longer, right?

There's More...
  • Share/Bookmark

6 Reasons Users Hate Your New Feature

You spend months on a new feature for your existing product: researching it, designing and building it, launching it. Finally, it’s out in the world, and you sit back and wait for all those glowing comments to come in about how happy your users are that you’ve finally solved their biggest problems. Except, when the emails, forum posts, and adoption data actually come in, you realize that they hate it.

There is, sadly, no single reason why your new feature failed, but there are a number of possibilities. The failure of brand new products is its own complicated subject. To keep the scope narrow, I’m just going to concentrate on failed feature additions to current products with existing users.

Your Existing Product Needs Too Much Work

Ah, the allure of the shiny new feature! It’s so much more exciting to work on the next big thing than to fix bugs or improve the user experience of a boring old existing feature.

While working with one company, I spoke with and read forum posts written by thousands of users. I also used the product extensively myself. One of the recurring themes of the complaints I heard was that the main product was extremely buggy and slow. The problem was, fixing the bugs and the lagging was really, really hard. It involved a significant investment in infrastructure change and a serious rewrite of some very tricky code.

Instead of buckling down and making the necessary improvements, management spent a long time trying to build new features on top of the old, buggy product. Unfortunately, the response to each new, exciting feature tended to be, “Your product still crashes my computer.  Why didn’t you make it stop doing that instead of adding this worthless thing that I can’t use?”

Now, you obviously don’t need to fix every last bug in your existing offering before you move on and add something new. You do, however, need to be sensitive to the actual quality of your product and the current experience of your users before adding something new. You wouldn’t build a second story on a house with a shaky foundation. Don’t tack brand new features onto a product that has an unacceptably high crash rate, severe usability problems, or that runs too slowly for a significant percentage of your users.

Before you add a new feature to a product, ask yourself, “Have I fixed the major bugs, crashes, and UX issues that are currently preventing my users from taking advantage of core features?”

There's More...
  • Share/Bookmark

Categories: Interaction Design

Watts all the buzz about smart grid energy?

We recently worked on a new energy tracking site to help consumers monitor their energy use and find ways to save money. With President Obama’s recent announcement awarding a few billion dollars in smart grid grants, we expect to see an even larger effort devoted to creating new energy tracking systems and devices.  So, let’s save all of us some energy by sharing our top tips for creating a consumer energy portal.

1) Simplicity is key
We’re noticing that far too many of the new energy portals on the market are delivering complicated interfaces and busy dashboard-style pages with dense data charts and lots of buttons. Although heavy data, analysis tools, and controls might be interesting to data geeks, most consumers will find this information overwhelming or just plain boring. Consumers don’t want it to be rocket science just to learn to set their thermostat, and they don’t want to spend hours reviewing their usage details just to determine how they can save money.

A few examples of interfaces with too much data for consumers:

Greenbox
greenbox

There's More...
  • Share/Bookmark

Categories: Interaction Design

Is Continuous Deployment Good for Users?

The recent release of Windows 7 got me thinking about development cycles. For those of us who suffered through the last 2+ years of Vista, Windows 7 has been a welcome relief from the lagging, bugs, and constant hassle of a failed operating system. Overall, as a customer, I’m pretty happy with Windows 7. But, at least on my part, there is still some latent anger – if Windows 7 hadn’t been quite as good as it seems to be, they would have lost me to Apple. They still might.

A big part of my unhappiness is the fact that I had to wait for more than two years before they fixed my problems. That’s a lot of crashes and frustration to forget about.

One approach that many software companies have been adopting to combat the huge lag time built into traditional software releases is something called continuous deployment. This sort of deployment means that, instead of having large, planned releases that go through a strict process and may take months or years, engineers release new code directly to users constantly, sometimes multiple times a day. A “release” could include almost anything: a whole new feature, a bug fix, or a text change on the landing page.

I worked with a software development organization that practiced continuous deployment on a very large, complicated code base, and I can definitely say, the engineers loved it. From the point of view of the employees, continuous deployment was a giant win.

But how was it for the users? The fact is, some decisions that seem like they only affect engineering (or marketing, business, PR, etc.) can actually have a huge impact on end users. So, whenever organizations make decisions, they should always be asking, “how might this affect my customers, and how can I make it work best for them?”

Is Continuous Deployment Good For Users?

As with so many decisions, the answer is yes and no. Continuous deployment has some natural pros and cons for the customer experience, but knowing about them can help you fix the cons and benefit even more from the pros.

Big Customer Wins

Fast Bug Fixes

Perhaps the biggest win for users is that bugs can get addressed immediately. Currently, even Microsoft releases patches for some of its worst security holes, but there is certainly a class of non-critical, but still important bugs that have to wait until the next major release to get addressed. That means weeks, months, or even years of your users dealing with something broken, even if the fix is simple. In continuous deployment, a fix can be shipped as soon as it’s done.

There's More...
  • Share/Bookmark

Infographic: How much do employers pay for healthcare?

We’re excited to share the infographic we designed for the Intuit Health Benefits Center project to answer this question.

infographic

In July 2009, Intuit conducted a survey with over one thousand small business owners in California asking about the health insurance options they offered their employees and how much they were paying for health insurance plans. From prior discussions with business owners, we knew employers were very interested in finding out the results of this survey, as they wanted to remain competitive with other businesses in their industry. We decided that an infographic would be the perfect way to transform our huge collection of data into a single, compelling visual.  Our goal was to create a comprehensive infographic that would be instantly meaningful and easily understandable to the many employers looking to get a handle on the best way to offer competitive insurance packages to their employees.

Sound easy? Not exactly. Like most aspects of design, it turns out that creating infographics is a tricky business – on the one hand, we had to be careful not to present too much information so as to be overwhelming, but on the other hand, our infographic had to be able to provide enough detail to be useful to a wide range of employers looking for very specific information. And, of course, we had to do all of this without getting bogged down in the details or jargons of health insurance plans that often don’t make sense to someone at first glance who isn’t in the healthcare industry.

There's More...
  • Share/Bookmark

A Faster Horse – When Not To Listen To Users

Henry Ford once said that, if he’d asked his customers what they wanted, they’d have asked for a faster horse. In the high tech industry, this quote is often used to justify not talking to users. After all, if customers don’t know what they want, why bother talking to them?

You need to talk to users because, if you ask the right questions, they will help you build a better product. The key is figuring out the right questions.

For starters, users are great at telling you when there’s something wrong with your product. They can tell you exactly which parts of the product are particularly confusing for them or are keeping them from being happy, repeat customers. Figuring out what to do about those problems is your job.

In general, users are not going to be able to answer the following types of questions:

  • What new technical innovation is going to revolutionize a particular industry?
  • What’s the next cool gadget that you’d like to buy?
  • Do you think that people like you would buy this new cool gadget that you’ve just learned about?
  • What new features would make this product more interesting/compelling/fun/easy to use? (although, this question becomes more answerable when the user is presented with some options for which features they might prefer.)
  • How exactly should we change the product to make it easier for you to use?

They are fantastic at answering questions like these:

  • What do you most love or hate about this product?
  • Do you find anything about this product hard to use or confusing?
  • Does this product solve your problem better or worse than what you’re currently doing?
  • How are you currently solving a particular problem that may or may not be addressed by this product?
  • What don’t you like about your current solutions for a particular problem?
  • Why did you choose this particular solution as opposed to another solution?

Obviously, there are innumerable other questions that you might want to ask your users, so how do you decide which ones they’ll be able to answer with any degree of accuracy?

There's More...
  • Share/Bookmark

Improving the ROI for Your User Research

So, you decided to do some user research in order to find out where you can make improvements. After a few hours of user interviews, you ended up with a notebook full of scribbled information that all seemed really critical. How in the world do you figure out what to do with all that information?

If your answer is “talk about it all abstractly with everybody in the company or write a huge paper that nobody will read and then go on with business as usual,” you’re in good (bad?) company.

But you have to DO something with all that data. You have to analyze it and turn it into actionable items that your engineering department can use to fix your product. It’s not always easy, but I’m going to give you an approach that should make it a little easier. This isn’t the only way to do your test analysis, but it’s one of the quickest and easiest that I’ve found when you are concerned with key metrics.

When to use this method:

  • You have an existing product with a way to measure key metrics, and you’re interested in improving in particular areas related to your bottom line
  • You have a limited research and development budget and want to target your changes specifically to move key metrics
  • You are looking for the “low hanging fruit” that is getting in the way of your users performing important tasks with your product
  • You are working in an agile development environment that is constantly tweaking and improving your product  and then testing the changes

When not to use this method:

  • You have an existing product that you are planning to completely overhaul, and you want to understand all of the major problems before you do your redesign
  • You are trying to create an overall awesome, irresistible user experience that is not related to a specific metric
  • You are designing a new product or feature and are observing people using other products to identify opportunities for innovation

If you fall into the first bucket, read on…

The Five Basic Steps:

  • Identify key metrics you’d like to improve
  • Identify the tasks on your site that correlate with improvement in those metrics
  • Observe people performing the appropriate tasks
  • Identify the barriers preventing people from completing or repeating the tasks
  • Develop recommendations that address each specific barrier to task completion
There's More...
  • Share/Bookmark

Why I Hate Paper Prototypes

Ok, maybe hate is a little strong. Paper prototypes and sketches have their place in interaction design. For example, they’re great for helping to quickly brainstorm various different approaches to a problem at the beginning of a design process. They’re also a very fast and cheap way to illustrate a new idea, since most people can draw boxes faster than they can build interactive prototypes. But, in my opinion, they have several serious drawbacks.

Before I get too far into this, let me define what I mean by a paper prototype, since I’ve heard people use the term to refer to everything from sketches on actual pieces of paper (or cocktail napkins in a couple of cases) to full color printed mockups with a polished visual design. In this instance, I’m referring to a totally non-interactive screen, mockup, or sketch of any sort of application that is meant to be shared with customers, test participants, or team members. It can be printed on actual paper or shown on a computer screen, but whatever the viewer does to it, a paper prototype is not interactive.

So, what don’t I like about them?

Screen vs. Paper

This first couple of peeves apply to screens that are actually printed out or drawn directly on paper. With a few exceptions that I’ve listed below, I’ve found this approach to be really counterproductive.

Iterating On a Design

One of the biggest problems with hand drawn sketches on paper has less to do with user interactions and more to do with my work flow as a designer. Sure, sketching something quickly on a piece of paper can be quick, but what happens when I realize that I want to swap two sections of the screen? I can draw arrows and lines all over it, but that gets messy pretty fast. Whenever I want to make any changes to my design, I need to create a whole new sketch. This can mean redrawing the entire screen quite a few times.

If I’m creating a design in HTML or any other prototyping tool, the very first version might take a little longer than a quick sketch, but the second through nth iterations are a whole lot faster. And, as a bonus, I can check them into source control, which means I’m a lot less likely to lose my work than if I have dozens of pieces of paper scattered all over my office.

Interacting With Paper

Whether they’re sketched out by hand or printed out on paper, people interact with paper screens differently than they do with computer screens. They view them at a different angle. They focus on different parts of the screen. They use their hands to interact with them rather than a mouse and keyboard. Any feedback that you get on a printed design will be colored by the fact that people are fundamentally interacting with it differently than they would if it were on a computer screen.

Given all of these drawbacks, there are a few situations when designs printed on paper can be used effectively:

  • You are at the very beginning of the design process, and you want to explore a bunch of different possible directions with other team members very quickly before committing yourself to fleshing out one or two specific options.
  • You’re designing material that is meant to be printed, like brochures, user manuals, books, etc. In this case, you want to know how people will interact with the printed media.
  • Your product is an interface for some sort of embedded or small screen device that would be very difficult to replicate in a quick interactive prototype. For example, a screen for certain mobile devices or the heads-up display for a car dashboard might be hard to show interactively in the appropriate context.
  • You have several different visual designs, and you’d like to show them all to users at the same time in order to see which one is the most attention-getting. You’ll still need to show the designs on screen, of course, since colors can vary so much between screen and print, but it can be helpful to lay out several pieces of paper so that the various options can easily be compared.
  • You need to share screens with people in an environment with absolutely no access to a computer whatsoever. You know, maybe you’re in the middle of a meeting and need to sketch something quickly, or the rest of your design team is Amish, or you are designing in a post-apocalyptic wasteland where the computers are trying destroy humanity.

On the other hand, if you’re designing desktop or web applications for standard computers, at the very least, show your prototypes on a computer, even if they are not interactive!

There's More...
  • Share/Bookmark