We’re always interested in improving our interfaces, and interfaces should adapt and improve over time. As we learn more about what our users need, we fine tune them to their needs. We were recently discussing what we should consider when introducing new features to one of our interfaces.
Is the feature needed?
It sounds obvious, but we should always determine whether there is a demand for the feature, are users likely to use it? Is the feature needed by your target users? Research is key, and it’s always good to look at sources of information you may already have (e.g. surveys, helpdesk queries etc). Decide if you need more information, or need to ask users more detailed targeted questions through interviews for example, so you get towards the underlying issues. Your interpretation of what would be a useful feature may be quite different to what a user needs. Also, what people say and what people do can be quite different. Observing people using your interface (or prototypes of future interfaces) is invaluable. It’s best to use more than one method to see if you are getting the same story, what you use and how much research you do will depend on the actual feature though. This sounds more onerous than it really is, but if you put a lot of development time into something that isn’t used – then that is costly.
Too many features?
It is possible to have too many features. More choice can make it harder for people to find what they need. Apparently this can be considered a condition – featuritis! We should be keeping it simple, an interface that has too many features, and tries to please too many people can result in a negative experience over all. UX Myths have produced a good review of research into implications of “too much choice”, and Netflix found that removing an unwanted feature was hard to do without annoying those who actually liked it. So think carefully if it is needed in the first place.
I also like Ben Balter suggestion of playing feature goalie, check it out.
Should a new feature be a priority?
It always feels good to deliver something new and different, but instead we should concentrate more on making interfaces easy to use and better at what they already do. This might mean a new feature is needed, but it also might mean working on improving an existing part of the interface. A new feature might not be the biggest priority.
Testing early and often is a good principle, and testing a prototype before actually putting a lot of effort into development can make a lot of sense. You obviously want to make sure that users understand the new feature, and seeing how they interact with it is crucial. We can learn a lot from testing and improve the design according to the results. Nielsen discusses some issues of how to handle user testing for specific parts of sites.
Here’s some steps I think we should consider when looking at adding a new feature:
- Look at evidence that there is demand for the feature, what is the business case?
- What problem does it solve?
- How can you measure success?
- Develop prototype
- Test prototype with users, refine accordingly
- Develop further
- Release to select audience, user test and refine
- Release fully
- Look at metrics
- Review if feature is working as desired