Assessing Fringe User Features
If you are a UX designer, you have undoubtedly been at a client gathering requirements when they say the magic words, “There are some users who will want to do that, but they’re only a couple of people.”
This sends your internal monologue into a quizzical frenzy: How many is a couple? Are we not going to account for them? Are you sure it’s only a couple? Could it really be a few? Could it really be everyone and you just don’t know it? Do they just want it, or do they need it? What does this really mean!?
Sometimes, these questions are answered in a straightforward manner that outlines exactly what it means for the requirements of your project. Ultimately, business owners are going to be the ones dictating which users are “important” and which ones get just enough to survive. That is the nature of our business, and it will always be that way in every aspect no matter how much we may kick and scream and tell them how wrong they are in a cordial, polite, professional manner.
The problem arises when the business owners have no real answers for your questions. They skirt the issue with comments like, “We can address that later.” And, “That’s not really something we’re concerned about right now.” This doesn’t solve the problem, though.
How do you solve this problem? You can’t start developing until you have requirements, right? (Yes, I realize sometimes you need to, but that’s an issue for a different day.) The cop-out answer is, “It’s a case by case basis, so there’s really no one solution.” Personally, I have a few tactics I like to employ when this situation arises. Here they are:
1. Try talking to the “fringe” user group.
Many times, the buck stops here. You ask them flat out if it’s something essential for them to effectively use the product. Make sure you phrase it tactfully like, “Is this something essential for you to effectively use the product?” Sometimes they will be uncertain, sometimes they will be definitive. Sometimes, you don’t have access to that user group. If the users’ answers are uncertain, conflicting, or non-existent, please proceed to #2. There will be times, though, where you end up learning that the feature is actually essential for a large group of users to effectively use the product as a whole.
2. Weigh the feature’s value against its cost.
If the feature has low design and development overhead, and isn’t extraneous, there’s no reason not to move forward with it. However, if the feature would take up valuable resources and time while providing little benefit, the cost outweighs the value. Don’t forget to accurately estimate the amount of time and resources needed to develop the feature. A client may write off a feature that they perceive to be low-cost, such as a single button that kicks off some kind of back-end process and shows an alert to confirm the process was successful. The problem is, that process would add two weeks of development time on the back-end. Be sure to articulate that to the client so that they fully understand what they are getting themselves into, and that it’s not just an IF statement.
3. Explore low-cost alternatives.
Depending on the nature of the feature, there could be an easier, cheaper way to design and develop it. Try looking at the feature’s purpose and examining whether there is a way to address the core goal of the feature that will take only a small amount of effort and resources to build. Sometimes, though, there is no alternative and you just have to submit to the fact that the feature is too labor intensive to reasonably justify including it in the project.
4. Contingency Plan: Phase 2.
When you have exhausted all of your alternatives, but still think this feature should be included in the finished product, you can always suggest that it be considered for a future upgrade. Suggest to the client that it be pushed to “Phase 2″ where these outlying features can be explored in-depth and still be included in the product, but as part of a concerted effort to continually better the product.
The main goal of these tactics is to gather information to articulate to the business owners the facts of the situation. When we educate our clients about the needs of these fringe user groups, they can make informed decisions as to whether the feature should be included in the scope of your project. Again, it is ultimately up to the business owners. If we don’t keep them informed of the impact the product will have on the users, though, we’re not doing our jobs as user experience professionals. More often than not, situations like this are a small piece of a project that tend to get glanced over, but sometimes game-changing requirements come to light. Being able to dig up this kind of information is one of the many ways we are able to demonstrate the value of UX to the client, as well as our own project team.