I have come to find there is no cookie cutter approach to measuring the value of a product. It very much depends on the organization, product, and the market the product serves. You need to invest the time to determine what metrics will help your organization demonstrate the value of your product, then come up with a measurement plan to guide how you track that value over time.
When designing editorial experiences, there is inherent friction between system architecture and user experience. The more complex the structure, the less usable the editorial experience of your CMS becomes. Content strategists strive to follow best practices when modeling content, but these object-oriented models do not take into account the workflow of tasks required to publish content.
I was just reading a blog posts on why brands should build recommendation engines to create better content platforms and improve the overall experience for users. While I tend to agree “pushing” content to users is a better strategy than “pulling” them in to consume content, I don’t think the technology is ready to truly support these type of experiences.
Below is the comment I posted.
I worked on a few projects in the past year where the question of “what is content?” came up. To give some more context, we were designing content management systems, and client’s were confused by all the different ways you can create content within the software we were using. To the content editors we were designing the CMS for, a page was not a collection of blocks, views, and nodes, but a series of images, content listings, videos, and calls to action.
Digital content can be simply defined as codified information that is transferred from one entity to another via some digital mechanism, but that has little meaning to content editors. They see content as the components they need to build experiences that engage their site visitors. For your modern-day content editor, that content is the collection of parts that make a whole (videos, embeddable tweets, slideshows, etc.), rather than the whole (a rendered HTML page).
We show a stakeholder some wireframes and talk them through the features. Once they see them they begin to imagine the ways features will look and act based on similar products they have used.
While perfectly natural, this behavior is problematic – what we envision may be nothing like products this stakeholder has previously used. These assumptions your stakeholder makes will lead to you and your stakeholders having different expectations during product development.
You need to make artifacts as real as possible in order to elicit the most unbiased, unimpeachable feedback from users during research. You do not need to build a fully functioning product to validate your idea.You do need to eliminate or reduce the guesswork needed to understand how your product will work.