New feature requests are something we face everyday on a product team.
However, managing those requests doesn’t mean automatically saying “yes” to them. As a product manager or product designer, your responsibility is to ensure the integrity and value of your product—and a harmonized user experience is absolutely essential to that integrity and value.
If you add features to a product at the drop of a hat, the product will eventually suffer from Franken-UX: bits and pieces that individually make sense, but when put together create confusion, waste time, and add zero value for your users.
So what’s the best way to avoid Franken-UX? Ask yourself these 4 questions next time someone insists that you add a new feature.
1. What is the actual functional/business goal we must achieve?
It’s very common for customers or even internal team members to ask for features. By features, I mean “can we have a button that allows me to filter X?” or “can we add field Z to the existing report columns?”
Photo credit: The Next Web
Anyone familiar with an existing application will always think within the limits of that application. And this is not a good thing because we end up trying to find ways to simply “fit” new features into an existing screen.
If someone requests a specific button or menu on the interface, ask them a series of questions so that you can understand what actually trying to achieve. Some general questions that can help you probe more deeply and efficiently are:
- Why do you need this functionality?
- What do you expect to gain by having this functionality (save time, work faster, increase conversion by X%, etc.)?
- Can you explain your business need to me without referencing the current interface?
- What percentage of users will this feature positively impact?
Once you’ve collected more information about the actual functional/business need, you should analyze the data to understand if, and how, it can be addressed satisfactorily.
During your analysis you might realize that there’s already a workaround that addresses the need. This can help to temporarily appease customers while you work toward figuring out the overall relevance of the need for your business and for your overall product vision.
Once you understand the actual need, you may find that the current product already has everything required to accomplish this goal, but it just requires users proceed through multiple screens or processes. While an exhaustive multi-step process isn’t great, you can at least articulate a workaround for customers who need a quick fix. This saves you from adding yet one more item to the interface. Most importantly, you buy yourself time to think more clearly about how to simplify the current multi-step process.
2. Is the goal aligned with our short-term and long-term objectives?
When a new feature request pops up, check if it fits into the short or long-term bucket.
Let’s say that as a company, one of your goals is to convert more “free trial” customers into paying customers and ultimately increase the number of new customers by 10% within 1.5 years. You decide that in order to increase the conversion rate in that time period, one of the required actions is to create an engaging onboarding process.
Photo credit: Kiip
The goal of increasing conversion rate would then fall into the “long-term bucket” and the creation of an engaging onboarding process would fall into the “short-term bucket”.
You may have two dev teams running in parallel: one to support existing functionality (so that existing customers don’t feel neglected) and another to build the new educational content library. Any new feature requests would then have to be evaluated to see if it fits into that short-term objective. Anything that doesn’t enhance the success of that that short-term objective must be set aside until it makes sense for the business to tackle the request.
It’s often deadly to try to sneak in something that doesn’t clearly fit into the two buckets mentioned in this section because the feature is often hacked into the interface, without the proper care and attention from product managers and UX designers.
Grab design ebooks created by best designers
All for free
Do you want to know more about UI Design?
Download 'The Guide to UX Design Process & Documentation' FOR FREE!
Download e-book for free3. Does it fit into our brand experience?
The phrase “our competitors have it” is often repeated as a reason for why a new feature should be implemented. But if a new feature cannot live up to or exceed your brand experience, then it shouldn’t be implemented.
Coherence and consistency of your brand and user experience must go hand-in-hand.
Let’s say Competitor A has a “Minimalist View” that you decide to add into your product. Four months, later you notice that Competitor B has added a new reporting function, so you add it to your report interface. Then 12 later now Competitor C has added an “export to PDF” functionality, so you do the same.
Photo credit: What Does Feature Creep Look Like? by Intercom.io
As you continually try to keep up with your competitor, you enter a reactionary state of mind where it’s simply about “You can do it, so I can do it too”. And this is a surefire way to create a product that will show the tell-tale symptoms of Franken-UX. Over time it will become clear to users that there’s isn’t harmony in terms of the functionality offered, how it’s implemented, and how it fits into the overall brand offering.
Your brand experience is something that needs to sit at the forefront of your mind whenever you’re managing new feature requests. For some brands, their experience is defined by top-of-the-line security. For other brands, their experience centers on file collaboration. For other brands, it’s high-end design editing capabilities.
Whatever you do, each new feature needs to represent that brand experience.
4. Will it help us attract a new market?
For companies looking to attract a new market of users—be it demographically or geographically—a new feature request needs to be analyzed within cultural and social contexts.
If your company is currently considering an expansion to another country, then all new feature requests should be considered for your existing and future markets. Maybe a given feature isn’t relevant for your current market but would be great for users in another region.
Photo credit: Web Designer Depot
If each market will have its own region-specific product, then all you have to do is implement the feature for the relevant market(s) only. However, if all users across geographical zones will be using the same product, then it’s essential to think about how the feature will be accessed. Should the feature be activated by a user setting or as an extra offering in a special subscription plan?
Users in one region should not be penalized with features that are irrelevant for them. Faced with the evidence of your Franken-UX, they could very quickly lose interest in your product
Conclusion
Saying no to new product requests is never easy to do.
And it’s often very tempting to let a few things slide through the cracks because they appear to be “quick wins” (like rewriting the text in an error or confirmation message to make it more user-friendly). Anything outside of that can easily be a small, “manageable” update or a beast that wreaks havoc on your UX.
The culture of “quick wins”, however, can be a slippery slope. When new requests come in it’s best to evaluate them against the 4 questions listed in this article.
You have a responsibility to the business and users to protect the integrity of the product. By taking the time to evaluate each new feature request, you’re ensuring that you, and the product team that relies heavily on you, are building engaging and relevant products for your users.
For more UX and product design advice, check out the free 109-page guide The Elements of Successful UX Design. The book deconstructs 24 examples from today’s top companies.
