1

I want to prioritize a list of features that our customer facing application does not currently have. I've first taken a look at our CSR call data to discover what services our customers call-in most to complete because they cannot self-service over the phone. I have also taken a look at what features our competitors currently have that we do not.

At this point, I'm not sure what to do, because most of the CSR call data shows that most calls point to issues that could be solved by improving current features, rather than introducing new ones.

At any rate, can someone help me with the next step of the research process? I do have the opportunity to interview customers in the future.

I'd like to present a customer priority list based on data that considers the impact on the user.

Does this make sense?

  • Hi, what's you point here? Can you be more specific about the issue and your question please? How can the community help you? – Marco Tatta Jul 19 '16 at 15:48
  • My question is do I just look at the CSR call data and use this as my prioritized feature list or is there more research to be done? – llowery Jul 19 '16 at 16:04
2

I think your next step here should be focusing on the improvement of the current features. If you have already discovered that "most calls point to issues that could be solved by improving current features, rather than introducing new ones," then adding new features doesn't make much sense here from a UX standpoint. Instead of wasting your, designers, and developers' time on adding new features that might not be using by the users, you should focus on making the current features awesome so that your users wouldn't need to call to complete them.

If you are willing to do that, then I suggest your next step would be run interviews and usability test on users with the most called-in features, learn what they are having trouble with the current features, understand why users call instead of completing the tasks on their own.

1

You've answered your own question here (although, ahem, you might want to rephrase it into a question).

User research shows that the priority is improving features you already have. Prioritise that before adding another feature.

At the heart of great UX is a long, fiddly, detailed, often boring, Continuous Improvement Process

0

In my opinion the study on the CSR you did is a good starting point. If you have the chance to interview the users, try to understand why do they needs those features, which additional features they could want or imagine.

0

Some believe that the best way to determine what should be built is to observe users in the wild before deciding on features. Watch them as they do their work, without directing them. What tasks do they perform most often? Which ones give the most trouble? What do they never do?

Discovering these patterns should provide some obvious directions for what features will be useful to your users.

0

Without really knowing any of the information that you have on hand, I can suggest some basic strategies that you can consider for feature prioritization, which you can combine to create a weighted feature list that should suit your purpose. For each of the categories listed there are a number of different ways in which you can score the features (old or new) based on how important or difficult you think they are (e.g. a 1-3 scale to keep it simple), and then tally them up to get a final list (you can also give heavier weightings to categories that are more important).

  • Business objectives/requirements (needs versus wants important to consider)
  • User objectives/requirements (needs versus wants important to consider)
  • Technical feasibility/constraint
  • Design/development team skills
  • Design/development effort (time and complexity/size of task)
  • Frequency of usage by users (how often is this a pain point for users)
  • Volume of usage by users (how many users does this pain point affect)

So your competitive analysis on similar applications will give you some idea (in consultation with a business analyst or business stakeholders perhaps) on how to prioritize based on business objectives/requirements. You can then use the call-in data to prioritize based on user objectives/requirements, but you are making the assumption that this information reflects the overall user group (which I suggest you validate through some analytics perhaps, since users might have issues with the feature but not call in to complain or ask for help).

What will help you assess the impact on the users as part of the user objectives/requirements analysis is to look at the frequency and volume of usage, and you can even assign a 'severity' category that is either a combination of the frequency/volume measures, or base it on how badly the users feel that not addressing this issue is for them (which is a more qualitative measure).

Depending on your software development process/cycle, you then need to prioritize based on what you think is technically feasible, so then there is some prioritization in consultation with the technical lead, and they may assess this list based on the overall team skills, effort and the time/budget provided.

I think that will keep you rather busy and provide a good starting point to home in onto what the design/development team should tackle first (with the blessings from business stakeholders). But I am interested to hear if other people come up with different suggestions.

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.