6 Reasons Users Hate Your New Feature

| 11.13.2009

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?”

Your Product Interface Is a Giant Mess

Remember the old Saturday Night Live spoof commercial that advertised, “It’s a floor wax! It’s a dessert topping!”? It’s not as funny when it’s true. Products cannot do everything, and when they try, they end up with interfaces far too complicated for the average user to navigate.

I see this happen all the time, especially with startups looking for a way to make their product appeal to more people. Instead of improving their core product and adding features that enhance that experience, they add unrelated feature after unrelated feature, often stolen directly from more successful companies with larger user bases. Their goal is to find something that makes them blow up huge, but they just end up with an overly complicated product that tries to do too many things and doesn’t do any of them well.

It’s not just startups that suffer from this. Products that have been around for many years often get bogged down with feature after feature, all of which have to be supported because some fraction of the user base still uses it. These products then become vulnerable to new challengers with more focused, easy to use interfaces and smaller feature sets.

Of course, there are times when companies have to take their products in a new direction. For example, Flickr started as a set of tools for an MMORPG called Game Neverending. The game has ended, but Flickr lives on as an entirely different business.  PayPal began as a way to make PDA to PDA mobile payments, but that feature got killed years ago when they realized that web payments were a far better business model.

When you do find that killer feature that’s going to change your whole business model, commit to it and make it a serious focus rather than burying it under dozens of less popular features. Don’t try to be all things to all people, or you will end up with nothing but a giant, unusable mess.

Before adding a new feature, ask yourself, “Does this enhance my current product experience or just add to an already confusing and cluttered interface?” And, if it doesn’t fit with your current product offering but you still want to do it, ask, “Am I prepared to cut other features to make this part of my core offering and simplify my experience?”

You Didn’t Build What They Asked For

Let’s face it, sometimes your priorities are different from your users’. For whatever reason, be it a new business partnership, a need for a new revenue stream, or the desire to attract a different group of users, sometimes you’re going to build something that your current users don’t want and didn’t ask for.

This isn’t always a bad thing. For example, something that annoys your current non-paying users but attracts a whole slew of new, paying users is worth a few nasty emails to your customer service department. Just make sure that the new feature is really going to do what you think it will. It sucks to piss off your current, paying customers to build a feature that never really fulfills its initial promise. Trust me on this.

Before building a feature that potentially has more benefits to your company than your current users, ask yourself, “Am I prepared to deal with the fact that this is going to annoy some of my customers, and what is the real likelihood that I will get more out of this than I will lose?”

You Built EXACTLY What They Asked For

I know. It doesn’t seem fair. They’re angry if you don’t do what they want, and they’re angry if you do what they want.

The truth is that users will often ask you for a solution when it would really be more helpful to tell you that they have a problem. I’ve written more extensively about when you shouldn’t be listening to your users, but the upshot is that users aren’t great predictors of which brand new features will be big hits. Sometimes users will tell you that they want a toaster in their car, when what they really mean is that they don’t have time to make breakfast in the morning.

Before building a new feature that your customers are demanding, ask yourself, “What known user problems is this solving, and is this the best way to solve it for everybody?”

The Feature’s Not Finished

Now, I’m all for building the minimum viable product, getting it out in front of users, and then iterating on it to improve it, but some features just aren’t ready for prime time. By launching a half baked feature without key functionality, you’re running the risk of turning a lot of people off on the idea before they ever get a chance to really try it out.

Remember, your customers aren’t in the conference room with you when you come up with your grand vision. They don’t know where you’re going with this neat new idea. They’re judging the feature based on their first experience with it. Make sure that the first version is at least usable and hopefully that it’s far enough along that users can see the same promise that you do.

Also, good enough to ship doesn’t necessarily mean good enough to remain in your product long term. A big part of shipping early is continuing to improve the feature once it’s been out for awhile. One company I worked with had the tendency to ship early versions of features and then let them just sit there gathering dust, rather than iterating on them until they were truly high quality. What they ended up with was an enormous product that all seemed about half finished and a lot of unhappy customers who didn’t believe features would ever improve past version 1.0.

Before shipping a new feature, ask, “Is this good enough that users will get why they should care about it? And, if they do care about it, am I committed to improving it?”

The Feature’s Not Finishable

At many of the companies I’ve worked with, features have tended to evolve before they even get built. What generally happens is this: you have an idea based on something you’ve heard from users; that idea gets brainstormed and grows based on internal input; UX and visual designers spec out the whole idea, often expanding on the original idea; then engineering gets involved and gives a time estimate of how long the feature will take to build; finally the whole thing gets cut back by about 80% based on the estimates.

Unfortunately, the 20% you end up implementing may not solve the original problem. That means, when you finally announce your great new feature, users who originally asked to have that particular problem solved are justifiably upset.

Before drastically cutting your new feature back, ask yourself, “Does this still solve the original problem I was trying to solve?” If it doesn’t, ask, “Can this problem be solved with a reasonable level of investment?” There’s no shame in answering no to either or both of these questions, as long as you decide not to go forward with the new feature.

The Secret to Making Everybody Love Everything You Make

I’m joking. There’s no secret. The truth is that it’s almost certainly impossible. But by asking yourself the right questions during your feature development phase, you can dramatically cut back on time spent creating things your users hate.

And never forget, when you do build something they hate, acknowledge it, apologize for it, and fix it. It will go a long way toward making your users happy again, and it might even get them to like that neat new feature you just shipped.

Interested? You should follow me on Twitter.

For more information on the user experience, check out:

Watts all the buzz about smart grid energy?

| 11.11.2009

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

Fat Spaniel
fat_spaniel_1

fat_spaniel_0

Tendril
tendril

So, we encourage you to simplify, simplify, simplify!  Anticipate user’s most common questions, then make it easy to find these answers. Highlight key information in an easily scannable format, and engage consumers with friendly language, like “How much energy am I using?” and “Is my electric bill on track this month?” If you have more data, you can always offer it on drill down for people who want to learn more.


2)
Present energy data in meaningful unit equivalents, specifically dollars
Which in-home energy device would you want to use in your home?

Option 1
HAN_1

Option 2
HAN_2

I bet you chose Option 2.

To engage consumers, phrase information in a way that makes sense to them. What we say has to be both measurable and meaningful. Consumers do not understand the electricity unit of ”kwH”, unless they’ve had considerable experience with it. And the words “tons of carbon” are just as meaningless even to those who are in the industry. Instead, all energy data should be presented in terms of dollars ($), with kwH and other meaningful equivalents shown as alternative views that can be visualized. For example, “You’ve saved $53.44, or enough energy to watch 362 hours of TV.”   Check out Chevron’s “Energy Generator” as another great example of how to present meaningful unit equivalents that consumers understand.

chevron


3)
Consider a “new user” experience
Most consumers have not had a lot of experience seeing detailed analysis of their energy data, so there is going to be a 3-6 month period of active learning for new users. During this time, users are going to be interested in identifying some basics about their energy usage. For example,

  • How much energy do I typically consume during a single day?
  • What is the impact of different items and behaviors in my home?

After this initial learning period, consumers will have a good sense of the basics that will remain fairly static over time, and will start shifting their focus to a different type of monitoring. For example:

  • Is my energy usage on track?
  • How does my usage now compare to my usage in the past?

We suggest that you recognize this consumer learning curve by considering a “new user” experience for your consumer portal.  The purpose is to educate users on their energy basics and to appropriately highlight information that is most relevant while they’re still learning, but might remain static overtime or become less interesting after initial use. Then, after this initial ramp-up period, keep users engaged by presenting an ongoing use experience that highlights the dynamic information they want to continue monitoring overtime.


4)
Deliver proactive recommendations with bottom-line savings
Consumers want to know what concrete steps they can take to reduce their energy consumption, and they want to know what impact those steps will have on their bottom-line savings. Our research has shown that people are highly concerned and knowledgeable about environmental issues, but their primary motivation is still saving money.  We recommend creating a predictive savings calculator based on actual energy usage that would allow users to see how various changes would affect their consumption and bill. Users could even use this calculator to help convince other household members to make the behavioral changes that matter most for their bottom dollar. Will the calculator show you which trade-off is right for you?  Probably not, but at the very least, it will provide you with your top options for having the biggest impact on your bottom dollar. You can take it from there.


5)
Offer a highly-visible, integrated in-home solution
In addition to creating a web portal for access to consumer’s historical data, we suggest also providing a highly visible point-in-time meter for integrated placement within the home. Consumers are looking for visible, real-time meters that can become an effortless part of their daily routines – much like their thermostats – because they know that everyone in their house has to be able to stay on track with one simple glance. Otherwise, it will be “one day up then one day down” instead of a forward-moving effort by everyone involved.

Also, remember what we’ve learned– keep the device simple, and present energy data in dollars and other meaningful equivalents, such as the following example from Energy Aware.
in_home

We hope you found these tips in creating consumer energy portals helpful. Think about it… talk about it… try it… and get out there and create your own green power designs so that others can give it a try, too.

Is Continuous Deployment Good for Users?

| 11.4.2009

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.

Fast Things vs. Slow Things

Similar to the first point, continuous deployment lets you get everything, not just bug fixes, to users as soon as they’re ready to go. Small features, easy changes, and UI tweaks don’t have to wait for larger, unrelated features to be released to customers. After all, should a new design for the splash screen really have to wait on the implementation of a whole new payment system?

More Opportunities for Community Involvement

If you’re having a constant dialog with your customers (you are, right?), they’re probably making some pretty good suggestions about problems they’re having or ways to improve the product. A by-product of the first two benefits is that those users are going to feel even more involved in the development process when their suggestions or concerns are dealt with quickly, rather than if they have to wait months or even years for the next major release.

(Mostly) Avoidable Customer Problems

As with anything, continuous deployment can also cause some problems for users. Of course, some of these problems can exist in big, staged deployments as well, but these are a few things in particular to watch for.

Constant Change

Imagine if every day, the layout on your car changed, sometimes slightly, other times drastically. You want to drive to the store, but the steering wheel is on the other side and you’ve suddenly got an extra pedal. It would make it a lot harder to get where you were going, wouldn’t it?

Well, presumably your users are using your product to get something done, and they’ve got a certain way that they’ve learned to do it. Continuous deployment can mean that the interface for your product can change at any moment, even several times a day. If features constantly appear and disappear, it can be very disruptive to your users’ process.

There are a few things you can do to minimize the disruption. First, make sure that you’re testing your biggest changes on small cohorts of people. Iterate on a subset of your user base, rather than hitting every single user with every single change. This will limit the change that any individual sees while still giving you the benefit of constantly pushing code to customers.  In fact, use this as an opportunity to do the A/B testing you should be doing anyway.

Also, and this should be obvious, try to limit your truly disruptive user interface changes so that things don’t feel like they’re in constant flux. You can still change things, but be aware of how frequently you’re making major changes and stay in contact with your users to make sure they’re not feeling dizzy.

Inconsistent UIs

When a big new release is planned, often there is a comprehensive design phase where all the new changes are mapped out and discussed. This means that any inconsistencies in the UI can be found and addressed.

In continuous deployment, different pieces of the product are getting built and shipped to customers all the time, and there is rarely a time when the entire UI is reevaluated as a single entity. This means that sometimes UI standards can tend to…oh, let’s say evolve.

This problem can be controlled by having a UX team member embedded in the development team and constantly working with the engineers to enforce standards before things ship to customers. It can also be improved by providing wireframes, visual designs, and tools like templates to developers so that the look and feel of the product doesn’t shift too dramatically over time.

Avoiding QA

I’m certainly not claiming that every single thing in a traditional release process gets a full QA pass, but I do find that continuous deployment makes it easier for code to slip out to users without any human testing at all. Any time you give engineers the ability to ship code directly into production, you’re tempting fate. Somebody’s going to say, “oh, it’s just a tiny change,” and it’s going to get out without any testing. I’m not naming any names, but you only have to have a tiny change break the entire product once before you realize that there’s no such thing as a tiny change.

Also, continuous deployment can make certain types of testing much less likely to happen. While large release cycles tend to have a code freeze and weeks or months devoted to testing, hopefully including regression, unit tests, and end to end testing, continuous deployment doesn’t necessarily have that baked into the process.

You can always add periodic end to end testing of the product to your own process, of course, and it can be quite helpful in improving code quality, especially when your engineers occasionally slip through a “tiny change.”

Communication Issues

When you’re constantly releasing new features and bug fixes, communication with your users can be a challenge. You don’t have one big release with new help docs, a big roll out plan, and an advertising campaign. Instead, stuff is coming out all the time, and users can get overwhelmed by keeping up with the changes.

Context sensitive help and inline information for each feature can help users get quickly oriented.  Also, clearly marking new features as alpha or beta can let users know when a feature is still being developed so they can set their expectations accordingly.

Documentation can also easily get out of date when things are getting released constantly. Big, staged development cycles often have a built-in time for creating documents. Typically, manuals or help documentation and FAQs go through QA sometime after code freeze and before release. But since you’re not necessarily doing a big, monolithic release with continuous deployment, you can end up with this material never getting any sort of end to end editing to make sure they stay current. Make time for this. It’s good for both your customer experience and your customer support team.

Frequent Downloads and Updates

While continuous deployment is quite natural with web applications, even downloaded products can be constantly updated. However, you should always be aware of the burden you’re placing on your user base. If you’re forcing people to download a large file and go through an installation process too often, you’re going to annoy people.  As a personal example, iTunes appears to have a new version every week, and I’ve started to flinch every time I open it.

There are a few things you can do to make downloads easier on your users. First, you can ask the user to allow the update to download in the background and install automatically the next time the product opens. This means that the updating happens with very little user annoyance. Also, it’s best to keep the update quick by making the downloads incremental. For example, your virus protection software probably updates its virus information daily without asking you to reinstall the entire product every time.

So, Is It Good for Users or Not?

Continuous deployment can be done in a way that’s good for both engineering teams and users, but you do need to take some precautions. By taking care when you introduce changes that your users will really notice and making sure that you make time for important processes like QA, you can get features out faster and constantly improve your product. And that is very good for users.

Interested? You should follow me on Twitter.

For more information on the user experience, check out: