3

When you build a mobile client application for enterprise software, how do you decide feature/ function priority from a UX standpoint?

1
  • This depends on the purpose of the app
    – BlueWizard
    May 8, 2016 at 18:05

5 Answers 5

4

To be honest, your question isn't 100% clear - are you after some of the ways that an organisation can seek feedback from users to determine their requirements? For example, using evaluation processes such as focus groups and surveys.

Or, do you mean that the organisation knows what it wants and what you're trying to determine is how to implement those features in the most user-friendly way possible?

That distinction may not seem like much, but I have seen organisations roll out software based on the functions they thought were important from a corporate perspective, only to discover after spending millions that it wasn't capable of performing some of the basic functions their staff actually needed to do on a daily basis.

As a start, below is some reading that may be useful:

Another interesting read is Tony Heap's take on how to prioritise requirements.

Hopefully you find the above resources useful. Feel free to post a comment if you needed something a little different.

1
  • Yes, the organisation knows what it wants, and their priorities are clear as well. However, I believe the list of features would be prioritised differently based on a UX standpoint. Your UXmatters link seems the most relevant here. Thanks mate.
    – Adnan Khan
    May 3, 2016 at 10:35
2

Building a mobile version of possibly complicated enterprise software requires very clear understanding of the main value that users derive from your product. It's about knowing what to push away to the second plan, and this is not an easy task.

I'd recommend to take a step back and not to think about features for a moment. List user needs across different personas. For each persona / need mark if the fulfilment of the need is the reason why that persona pays for the product, or is it a nice-to-have. You should be very restrictive here. The idea is to identify few core needs that drive value for most of your personas. Once you have these, list and discuss features for the core needs. Try to sketch out the simplest possible user flows that would achieve these needs. This should help your with prioritisation.

It's easier said than done. The difficult part is to keep the user needs on the right level, not too specific and not too general. Takes a bit of practice.

Another thing I'd suggest is to think about behaviours that you want to drive in your product. In the ideal situation, what would you like the users to do? What should they do most frequently? What should they do occasionally? Think also of data and make sure that most dynamic and interesting data makes it to the front.

When determining core needs it helps to keep your customers in the loop and look into objective product usage data that you gather through, for example, Google Analytics. This can help you validate your progress.

Hope this helps

1

One way to do it is through user research. You can start by measuring customer emotional reaction to individual features by presenting them in a way that makes sense to them, like making them imagine real scenarios of use.

There is a systematic way to identify which features will bring value to users and which ones won't. This helps you prioritize development, design and time resources to meet the deadlines your budget requires. There is a great article on it: https://uxmag.com/articles/leveraging-the-kano-model-for-optimal-results

My team has been using an app that automates that very same lengthy process to guide our decision making:www.featur.me

Hope you find this useful. I'd be happy to assist you further.

0

To understand which features should be prioritised I'd look your users goals, specific to the mobile environment.

  • Define your user(s) in some way, ideally a persona - pain points, goals, realistic description - extensio is a great tool for this.
  • Try empathy mapping, put yourself in the users shoes - with their goals in mind and try to accomplish their tasks with that mindset. This is a really eye opening practice and will bring up issues you would not have otherwise thought of. More about empathy mapping here: http://www.copyblogger.com/empathy-maps/
  • With the output of the previous tasks in mind, develop some prototypes and usability test them. This can be done in various ways, you could use something like UX Pin to develop, share and usability test your protoypes in, or Invision to add functionality to photoshop mockups - OR just use paper, sketch it up and run some usability tests through it. You don't need much to usability test or to create prototypes, so use whatever is efficient for you.
  • Running a usability test on a design will blow your mind. Here's a test script you can use if you're running the test in person - which to me will give you the most insight into how your users interact with the product.
  • Document the UX decisions you make and demonstrate why they have value, you could link certain features to a usability test case or something you learned during empathy mapping or prototyping.
  • People will not use something that takes a lot of effort, they'll just move onto the next product. If your product is hard to use, it'll be pushed to the side.
-1

Personally I think that features or functions should not be prioritized from UX stand-point.

Features or functions should always be prioritized based on Need and its importance (read 'Value'). Once this is set, then you define the user experience for that feature.

It is extremely important to not get confused with prioritizing the features and User experience. Your feature 'Roadmap' should not be driven by User experience. It should be driven by User Need, Risks, Cost-Value, Delivery, Complexity, Market Demand, etc but definitely not User Experience first.

If you have a feature that provides best user experience in the market but is not required by the user. Then that feature will have no or little takers.

However having a feature that is sorely needed by the user but provide basic or mediocre user experience; You might still find users interested in the feature.

There are multiple requirement prioritization techniques in the market. You can start with this: https://en.wikipedia.org/wiki/Requirement_prioritization

4
  • Why do you not consider user needs and value to the user part of the overall UX process? Those are kind of the base to the whole UCD process. You seem to be implying that "UX" is a single point along the whole develop process, instead of all encompassing (which it is). May 1, 2016 at 14:40
  • 1
    My understanding of the question: I have multiple features which i want to prioritize. How would i prioritize them based on UX standpoint AND this is how i perceive the solution: If I want to decide priority of a feature among multiple features I will not use UX as a key parameter. Prioritizing feature is a requirement level process. Yes, UX does play a part in it, but not in deciding the priority of features. Priority of feature is a business level scenario, like something a Product Owner or Business Analyst would do. Once features are prioritize, Then you consider UX as a parameter. May 1, 2016 at 17:11
  • 1
    UX is part of the requirements process too. Needs & competitive analysis is all part of that, which is in the realm of UX, as it affects the end user. One does not have to have "UX" in their job title to be part of that process. May 2, 2016 at 2:09
  • I totally agree with you. But lets take an example, Facebook has features like 'Sharing a post' and 'Commenting on a post'. On what parameters would you decide the priority of the feature. Which feature would you take first for implementation/delivery; or how would you decide if both features are needed to be taken in-parallel execution? May 2, 2016 at 4:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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