Bug 578967 in Mozilla’s public issue tracker is an issue that’s caught my attention recently. It’s a controversial issue with over 160 comments and over 50 participants. So why so contentious?
The issue is a task to remove a RSS icon from the top-level navigation in the upcoming Firefox 4 release. What exactly are we talking about? I’m referring to this:
Why? To simplify the UI.
As I read through the issue, I found myself relating a lot of the discussion back to similar situations I’d experienced recently. So I thought I’d break down different parts of the conversation happening on issue and relate it to several things I’ve learnt over the last year in product management. For some background, you might want to read the first few comments on the issue.
1. Take yourself out of the discussion and think of the customer
“…I use the button myself as a convenient shortcut (just so you don’t think I’m
any kind of RSS hater, but it’s hard to justify the prominent placement it
currently has…” – Alexander Limi
This is a hard thing to do. You might often hear yourself or your colleagues say “I would use this!” – but the real question you need to ask yourself is – would most of your customers? When looking at making a product decision remove your opinion out of the discussion and put the customer hat on.
2. Achieving simplicity will mean you have to say no
“…You have a compelling argument, the problem is that while this move would
simplify the UI for the lowest common denominator (which is frequently a good
thing) it would drastically reduce discoverability for feeds support…” – David Garrett
This whole debate is a result of a request to simplify the user interface of Firefox. Less is more. Doing this isn’t easy, at all.
Every customer wants to take your product in a different direction. Every direction has a different experience and purpose. Design by committee doesn’t work. The only way you will be able to achieve the simplicity you desire is if you say no. How do you say no? Well, you can’t really say no with confidence unless you have a vision for the product.
3. There will always be a vocal group of users
“…Your usage metrics aren’t accurate.. I use the icon as a visual reference to rss feeds.. yet I don’t click on the icon.. I didn’t know it was a button. RSS technology is still unknown by most users.. removing the icon isn’t going to help people learn about it.. it will just kill it.. this was a very stupid
move. Please bring back the icon!!! Why go backwards? I know votes don’t mean much to you folks, but there are more votes to keep the button than to remove it.. check out the user comments on the Mozillazine forum and on the Firefox 4 Beta forum.. not one user wants to get rid of the icon, but all want to keep. Why don’t you listen to the users?…” – jcspence74
I applaud Mozilla for such a public issue tracker. At my current work we do the same thing – and it’s a hard thing to do. A big part of having such a large customer base is recognising that you will always have a vocal set of users. The difficult part of your job is working out if the feedback you are receiving from vocal users is valid and if it’s a true representation of the majority of your customers.
Using data to make decisions is a helpful way to go about doing this…(next point)
4. Data driven decisions
We’re moving a lot of new functionality to this area with the Stop/Reload/Go
combination, so we should get RSS out of the way. It’s one of the lowest-used button in our entire UI, even among our power users (beta users that supply the test pilot data), with only 3% of users *ever* clicking it even once during the test period: https://heatmap.mozillalabs.com – Alexander Limi
Mozilla are capturing comprehensive stats, with several studies conducted during the Firefox 4 beta. These stats are produced as a heatmap overlay a browser. One of the studies from earlier this year showed that a small percentage (~7%) of users actually clicked the icon. The latest study showed only 3% usage.
Where possible, use data to drive and validate decision making. However, the biggest challenge you have here is making sure you aren’t solely making decisions on user metrics. It’s equally important to consider how user experience can change behaviors rather than relying on existing patterns.
5. Focus on the majority
So here is the counter-argument to the previous point:
“…Even if we’re only talking 5-10% of the Firefox user-base caring about this button, that translates to tens of millions of people…” – David Garett
It’s very easy to say we should focus on the majority. It’s something else to do something about it.
“We simply have to design for mainstream users if we are going to survive in this increasingly competitive marketplace. Everyone seems extremely interested in their own personal usage, and being informed well enough in advance of a otherwise pretty minor modification so that they can riot and attempt to
prevent any type of change… We’re designing a product for 400 million people. This bug could contain a million comments calling us stupid and it still wouldn’t change our desire to create a product targeting mainstream users.” – Alex Faaborg
6. Speed, speed, speed
You have a large customer base and you have lots of data. Most would think that should make it easier to make decisions… Right? Wrong! You can spend forever debating these things – make sure you don’t! An amusing comment on this issue:
“If we hurry we can still beat the release of Duke Nukem Forever as well!” – Alex Faaborg
It’s okay to disagree. In fact, it’s probably a good sign that you have people disagreeing – you have a good balance of people working on the project. However, you must make sure you don’t go on debating these issues for long periods of time. Before you know it, you’ll be behind the competition.
Figure out the implications of making a wrong decision – financial, technical costs, customer experience etc… From there, work out how much risk there is in making the wrong decision. Once you have done that you’ll be in a good position to understand how much time is too much time wasted on debating the issue.
In this specific example, getting the decision wrong isn’t the end of the World. RSS isn’t dead. This won’t kill RSS. It would be very easy to bring back the RSS icon if you got the decision wrong. So, work it out: Is 160 comments over a period of five months worth the debate? No, it isn’t.
Make a decision, move on.
7. No, not another setting
“…A different compromise might be to only show a feed icon as needed if a user
has at least once used the feed system beyond the default. After which point it would have it as an easily user configurable option of some kind. (though I’m apparently only coming up with this now, and it’ll be burred in the new deluge of panic)… I would prefer some kind of an in-GUI option or an about:config option for this
too, but it doesn’t look like we’re going that route right now…” – David Garrett
Please, don’t get me wrong. I’m all for settings – where settings are needed. This problem relates to a previous point I made. Generally speaking, software with lots of ‘optional settings’ is usually evidence that it isn’t catering for the majority of our customers. There is no clear direction and vision for the product. The end-result? Option and configuration bloat. Consoles with hundreds of check boxes and radio buttons. A poor user experience.
I once heard a quote that was along the lines of “For every 20 users I’ll make unhappy, I’ll make another 80 users happy” (couldn’t find where this quote was from).
8. Don’t be driven by your competition
> Those sites are going to have some issues with users on chrome and apparently
> IE9 as well.
Meh… If IE9 completely does away with this in the top-level GUI then I
reluctantly agree we may need to consider it too. (though I’d still rather not) – David Garrett
Don’t let decision making be driven by your competition. This is hard to do, because you can often play it safe by simply “seeing what the others are doing”. Whilst it may sometimes be a safe bet (assuming your competition has it right), it often is a great way to kill innovation and not produce anything of any differentiation.
Interesting side-note: Chrome did consider this feature and decided not to do it.
Removing features is incredibly hard. It’s extremely easy to add new functionality to your product – however, we don’t often stop and think of the (long term) implications of this. If removing features difficult to do, then, we should, equally, put as much effort into deciding what new functionality we want to add.