There comes a time in the early phases of most, if not all, website or application projects when a list of potential features must be cut down to fit a project constraint, like budget or time. Whether enhancing an existing experience or creating something new from the ground up, determining the value of a feature for users and project stakeholders alike helps to prioritize a feature list and build a project scope.
One of the methods we’ve used to help prioritize a feature list is plotting the value of features on an x-y axis. In this simple and effective process, the x and y axis of a diagram is assigned a criteria derived the project’s business goals and user tasks. Features, represented as dots, are then placed on the diagram in the position where they seem the most fitting among the spectrum of criteria.
Know Your Objectives
In order to have generated a set of feature candidates worthy of scrutiny, a reasonable and achievable set of project objectives has been defined by the team and approved by the client. Likewise, it must also be assumed that due diligence has been made to understand audience challenges, needs and/or expectations in order to outline a set of supported user tasks for the project.
Clearly defined project objectives and supported user tasks will keep everyone grounded in reality and provide the bar for what truly holds value for a project, rather than being driven by feature lust.
Selecting Diagram Criteria
Deciding on the diagram criteria is probably the most important part of this exercise. Axis criteria should represent the desired end results of the project, extrapolated from the project objectives and user tasks. If the criteria assigned to an axis is unachievable, no feature will measure up. If a criteria is too specific, or even too vague, there won’t be a level playing field on which all features can be judged in relation to each other.
Also, the criteria on each end of an axis should not represent a negative and a positive; for example no sales vs. increased sales. Contrary or polarized criteria makes for skewed evaluation; of course we want more sales. Rather, criteria should represent ends of a spectrum, each with equal value potential for the project. An example of consonant criteria could be short-term benefit / long-term benefit, or return engagement / increased sales. While each criteria has value, it is likely a single feature could be assessed as contributing to one more than the other.
A Project Example
DEFINING THE Y AXIS
During a recent renovation project for a product-focused site with some minimal social functionality, we gathered feedback that existing user-to-user communication was too limited and clumsy. Knowing this, a business objective for the project was to facilitate better audience generated content and interaction and we came up with several enhancements to support that.
However, the site had several other functionality sets focused on an individual user tasks which needed to be updated/fixed. From this we derived our first axis criteria to evaluate our feature list: Is the feature focused on an individual’s experience or interaction with the group or community?
DEFINING THE X AXIS
The second pair of criteria for this diagram came from the tone of the content and the kind of environment we wanted to foster. The client was already generating editorial content and receiving good feedback and engagement. So, an identified objective was to explore new ways for their community managers and endorsed product specialists to publish and engage with users over the content.
The kind of content being generated ranged from instructional and tutorial to the inspirational and aspirational. To be sure the features we moved forward with supported those themes, we considered the feature list with this in mind: Does the new feature provide or facilitate instruction, inspiration or somewhere in between?
So, a quick recap. We’ve defined two objectives from our example:
- Facilitate user contribution and user-to-user interaction
- Explore new publishing for staff and engagement opportunities to instruct and inspire users
We’ve distilled those down to evaluation criteria and assigned the criteria to our Value Diagram.
Now, we go through the exercise of plotting features from the proposed feature list onto the diagram. A dot is placed on the diagram where the potential value resides.
One of the features in our list was implementing a forum so community members could interact with each other, generate their own subject matter, participate around suggested subject matter and engage with community managers and guest publishers.
As mentioned earlier, there really isn’t a negative location, or wrong answer, in this evaluation.
This diagram is simply representing that a forum draws its value from group participation and has the potential to provide both instructional and inspirational.
When reviewed in the context of all the features in a feature list the diagrams can reveal whether or not the project objectives are being supported. Or, is the feature list skewing in one direction or another? Are there deficiencies? Are we missing something? Can a feature be better in someway?
If the desired outcome is prioritizing features for deployment over time, features of similar value can be pitted against each other to determine which launches and which warms the bench or is cut from the team.
Options to Consider
A project may require multiple diagrams to focus on specific themes in your objectives. With the client project mentioned above, we actually had two diagrams to assess each proposed feature, Value for the Audience and Value for the Business.
We plotted each feature on both diagrams and made our final decision on the recommended feature list we brought to the client. We were transparent with our evaluation and included the diagrams in our recommendations document.
EVALUATING EXISTING FUNCTIONALITY
It can be helpful to plot the value of existing functionality in relation to a project’s objectives. The Value Diagram is built in the same way described above. However, the conversation turns into what value is required of, or desired from, the existing functionality to meet the project objectives, are these expectations realistic and what will it take to get it there?
This process can be completed on your own, with your team or involve the client so they can be a part of defining the project feature roadmap. Use a whiteboard or print out the diagrams on cards and pass them out so the group can participate.
The criteria in the diagrams are based on project objectives presumably born from real business needs and research. But at the end of the day, you’re still making a judgment call, a gut check, albeit an informed one. These diagrams can be revisited with post-launch metrics in hand to evaluate how the features are performing.
This is a Tool, Not a Solution
This exercise provides an alternative angle to consider a set of features, not only in relation to each other, but in the context of what the project must accomplish. It may not work for every project, and we don’t use it on every project. Yes, it’s subjective. And it may not be all that scientific either. It’s simply another way to approach a problem and inform your best recommendations for creating an effective and meaningful experience.