Looking for feedback on this work process:

The product team is coming up with design features for existing product & then validating it based on user research (self reported). As a user/UX researcher I am not 100% convinced that is the correct progression, but given the strict deadlines, this is what is finalized. Has anyone worked in this manner, if yes did the final product perform well from user's perspective?

  • Hard to say based on this information. For some products new features should be driven by user feedback, but for some they might be driven by something else (e.g. a business requirement) and then validated by user testing to make sure they work well. – user31143 Nov 4 '15 at 10:21
  • i think its a common task in a beta version....i have seen many products do so. – Stanley VM Nov 4 '15 at 14:42
  • Are pre-determined design features based on well-established conventions in the industry, medium, or world in general? If yes, that makes sense. Based on your description, you'll want everyone to be mindful of confirmation bias. – Tim Huynh Jan 3 '16 at 20:43

For an existing product, you have two primary modes of working on new features:

1. Optimization

When optimizing an existing product to the needs of it's user base, or to extend into adjacent markets, research into real user behavior is critical. You would be hunting primarily for pain points, under-used features, and workflow gaps. You can guess based on tribal knowledge, but your risk would be much higher.

2. Innovation

Even existing products have room for something totally new. Something your user base (maybe any user base) has no experience with and may not even know they need yet. You can and should do research, but someone with a talent for seeing the unseen is your best asset here.

In either case, be ready to ship often.
If the product team wants to get ahead of the users and start building to their assumptions, you have to also commit to rapid optimization and course correction. This is less of a concern when the project is heavily rooted in real user research -- still valuable, but not as critical.

The results

Without research-driven feature definition:

  • An optimization project probably won't be as successful as it should be. You'll have to watch the KPIs and pivot based on the post mortem.
  • An innovation project will be a guess. Cross your fingers and hope that your product team is really good -- they just might be on to something.

I've worked on heavily researched optimization projects that yielded mediocre results. I've also worked on revolutionary innovation with little user validation that completely blew expectations out of the water. It all comes down to the talents of your product team, the resilience of your users, and a big lump of luck.


I would recommend you Ansoff model as a way to drive your UX design approach https://en.wikipedia.org/wiki/Ansoff_Matrix

For extending and adding features to an existing product and for existing users, user research approach would involve mining through the issues/faults and enhancement requests. Its one of the efficient and reliable ways to gather data to justify your product features.

The information you gather would help in developing and refining your profiles, personas, workflows and task models.

I would like to add the outcome of using UX design in such scenarios is a well refined and optimised user experience.

For adding new features to an existing product and for new /users, user research approach would involve new user segment survey, field research, a task-based audience segmentation.

The outcome of such an exercise would be that your new product features are user-centric, hopefully leading to increased adoption right from the start of the product launch.

It appears to me that there is some ambiguity about the product strategy for the product features you would want to extend or add. Suggest you clarify the goals and aims of UX design with your product management team.

  • Existing products with existing user have evolving needs. Simply mining issues/faults and enhancement requests only tells you how people are currently using the product and the problems that they have identified. To continue to evolve the product to keep up with a changing marketplace and changing users, a researcher should do far more than mining self-reported issues and requests. – nadyne Dec 6 '15 at 21:14

It sounds like your team has designs in mind. What are those designs based on? I assume not from users. So they're, in effect, using usability testing to verify that their assumptions were correct.

In my experience, it makes better sense to do user research first, and base your designs on what you now know about them and what their tasks and needs are. Then usability testing isn't about verifying that you're heading in the right direction, since you're already designing in the direction of supporting user needs.

(And yes, your original scenario is common. The UX Designer's plight is to always be advocating for better ways to design against entire organizations that think designing without knowledge of users is good enough.)

Edit (to answer your actual question): It's hard to say whether these non-user-centered designs perform well. My teams don't typically do any follow-up to see how they perform. Usually we deliver the product and someone pays us and everyone's happy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.