I consider myself a fairly conservative Information Architect. I tend to err on the side of caution, forgoing radical, but potentially innovative ideas in favor of more tried-and-true approaches. Over the years, I developed a simple mantra: “less is more.” I believed this because adding more stuff, i.e., features, functions, and options tend to confuse the user experience, ultimately detracting from core functionality.
However, my beliefs have been shaken by some rather basic marketing education and some new knowledge of human behavior. The bottom line is that clients often want more features, even at the risk of reduced usability.
Users Can Tell You What They Want but Not What They Need
The basic tenet of user centered designs is to design products and systems based on end user needs. The problem is that users almost never know what they need. More importantly, most clients aren’t sure what their users need.
If you ask 100 users what features they think should be on a new website, you’d get 100 different answers, suggestions that mostly come from their personal online experiences. So, if a user likes Hulu, they’ll probably ask for more video (even if the organization doesn’t have video assets). Facebook users will say they need social networking features. This isn’t always true, of course, but it’s more often the case. In addition, when offered a list of potential features, most users will want almost all of them. Well, why not?
Why Sometimes More is Better
For years, I’ve railed against Microsoft Word because it has hundreds of features that I never use and many that I don’t even understand. Why continually add new features that people never use?
I use the Styles feature a lot. Like CSS, Styles can create a complete style framework for simplifying document creation and ensuring continuity between documents and different users. Styles is a fairly advanced feature. Most people don’t even know that this feature set exists. Yet there are many fundamental features such as tables, or reveal codes or indenting or Tabs that many people never use. They’re either unaware of them or find them too complex.
Why don’t developers release a “lite” version for users that just need the basics? Here are my two reasons:
- Software companies want to sell more software. Therefore, updated versions have to be sufficiently different from earlier versions to entice people to spend again.
- When looking at a product, consumers look at the “feature set.” The longer the feature list, the more appealing the product.
It’s just basic human nature. Customers want the most for their money, even if they have no idea whether the feature will be useful. Check out this (somewhat misunderstood) article by Don Norman, Simplicity Is Highly Overrated if you want more insight on this concept.
So, for a website, especially a redesign, the web team has to sell the idea to the folks with the money. It would be tough to sell a six-figure redesign by saying:“It’s going to be just the old site, only it’ll work better.” Though I’m an IA, it’s sometimes tough to sell just that angle. Adding a Google Map Mash-up or streaming video sounds so much more exciting. And by the way, we’ll also make the site much easier to use, too!
Where Does the Feature List Come From?
Clients specing a new website tend to want to add features, because that’s how they gauge value. Additional feature = additional value. So, when we get a client feature list, where does it come from? Here’s my (very unscientific) list in the order of probability:
- From small internal groups, usually from the web team and very often from IT staffers or developers close to the site
- Feedback received from users, either though an online feedback form or more likely through conversations, mostly anecdotal. Again, usually from a fairly limited user cross-section
- Analytic information, e.g., Google Analytics
- Structured survey, interviews, or focus groups (Research suggests focus groups are bad but that’s for another post)
- User observation, e.g., usability testing
Though largely unscientific, this is the hand we’re dealt. We have to adapt our recommendations to complement the client’s feature requests.
What Can You Do?
We know that on many web design projects, the feature set is largely determined by people other than users, and often with little supporting data. This also means that some of those features will be stakeholder “pet projects.” That’s a clear indication that you should tread lightly before making any wholesale changes. No amount of data may dissuade a client from implementing certain features. Here are some things that you can do to balance feature bloat and usability:
- Find out who owns what – Find out who the stakeholders are and who’s championing which features. This will help you to avoid unwinnable battles. If an idea is particularly egregious, come with recommend alternatives, rather than simply shooting it down.
- Analytics – Look at actual metrics, aka Google’s Top Content Pages, Traffic Sources, Top Referring Keywords, Time on Site (time on specific pages), etc.
- Audience analysis -- Learn as much as you can about the audience, is it internal or external? Is the site used mostly by people with prior knowledge, or mostly new visitors (via search or referral)? Are there special audience groups?
- Build a library of research – Create a library of research that supports your recommendations, filled with data that you can share with clients.
- Competitive analysis – Odds are someone else has done something similar. Compare what others have done and choose the best bits for your project. You can also hold up other examples as best practice.
You can check out this short post by Oliver Gitsham, Finding the Balance: Users’ Needs Vs. Clients’ Wants to get another perspective.
To sum it all up
I have to admit, I used to rail against frivolous features as being added for no additional benefit. They’re expensive, eat into development time that could be used to refine other features, and don’t improve the user experience.
However, logical thinking doesn’t cut it when the perception is that if one new is feature is good, then five new features must be better. The bottom line is that “more” may not improve the user experience, but “more” adds perceived value.
Here are some quick tips:
- Conduct whatever level of analysis you can
- Arm yourself with information. Build a library of supporting resources/research.
- Consider feature/usability balance when making recommendations.
- Be strategic in your battles.
But, bear in mind that all the evidence in the world won’t always win the day. You’re going to have to find your happy place – that ultimate sweet spot - between Less and More.
UPDATE:
Sometimes less is less – I came across this product review on Engadget. This may be a case where less really is less.
Thomas Ricker (Dec 6th 2010 11:59AM). John's Phone review: 'the world's simplest cell phone'. Retrieved from http://www.engadget.com/2010/12/06/johns-phone-review-the-worlds-simplest-cellphone/
Additional Reading
Don Norman (2007). Simplicity Is Highly Overrated. Retrieved from http://www.jnd.org/dn.mss/simplicity_is_highly.html
Anthony (September 6th, 2010 4:46 pm). Simplicity is Not Overrated, Just Misunderstood. http://uxmovement.com/design-articles/simplicity-not-overrated
Joel Spolsky (December 09, 2006). Simplicity. Retrieved from http://www.joelonsoftware.com/items/2006/12/09.html
Oliver Gitsham (September 7th, 2010). Finding the Balance: Users’ Needs Vs. Clients’ Wants. Retrieved from http://www.uxbooth.com/blog/finding-the-balance-users-needs-vs-clients-wants/
