Feature Request - Understanding user impact

When assessing a feature request keep in mind that a change to the software might impact people other than external users. Some changes are to help yourself or others such as a developer tool. In all cases, someone’s workflow is being changed. You’re responsible for avoiding making that worse. Slow down and consider what the impact of your change will be. The following questions will help you assess this.

What users would see this change?

Most cases this will be obvious. It’s everyone. Sometimes it’s a more difficult subset, such as all Windows users. Sometimes it’ll be some subset of users who have a specific feature enabled for them. Try to measure how many users will be affected by this change. This will help you determine how useful the change is. It may also impact when the change can go out. If you’re deploying a change that will lock a table for 5 minutes, you’re better off doing that during downtime than peak usage of that table.

What is the user trying to do?

Consider what action the user is taking and the motivations for doing so. If the motivation is clear, it’s easier to determine if the change aligns with the user’s needs. If the motivation is unclear, try to gain more understanding. Occasionally features are requested to scratch an itch because the user didn’t know the underlying problem could be solved. Don’t be afraid to confirm this.

Is it a reasonable user experience?

If a change delivers a feature, but only behind a terrible user experience it’s not a success. If there’s a more pragmatic and efficient way to accomplish a task it should be weighed against the other options. Intuitive user interfaces make it clear what the next action should be. Efficient interfaces makes common actions easily available. Balancing and promoting both is difficult, but when you achieve it, your users love you.

A common metric is the number of clicks require to achieve some result. The actual threshold will change depending on the need. For example, the number of clicks to purchase your product should be as few as possible. The clicks to delete your account should be at least 2, but probably fewer than 5 (Amazon Prime, I’m looking at you).

How do users recover from errors?

Errors are going to happen. Someone will click delete rather than cancel. Someone run a query that locks up a database. Someone will eventually take down production. When reviewing an issue, consider where the errors might crop up and how the user will recover from them. It’s worth imagining how severe and frequent the error may occur. The lower the impact and easier to recover errors require less warning signs. The difficult to recover errors need big warning signs.

Do users need to be notified?

If they proposed change significantly changes a customers workflow or interface, you should tell them ahead of time. If the change is minor or intuitive, you don’t need to. In fact, some users may prefer to not be notified unless it actually impacts them. They may simply want your application to continue functioning according to their perspective and don’t need you taking up any of their attention.

Does the change include a deprecation?

If this change includes a new way of doing things and marks the old way as obsolete, the application should reflect that. The documentation for the old flow should point to the new flow. There should be indications at the beginning and end of the old flow, informing the user of the deprecation and pointing them towards the new way. Try to make it easy on the user to switch over. Sell them on why the new way os better. The new way is better right?