I’m fond of the mantra of “the right content in the right place at the right time.” This blog has covered various aspects of the hows, whats, and what ifs on getting that content to the right places at the right times. But we haven’t actually discussed how the content itself becomes “right.”

With so much emphasis being placed on aesthetic and interface, content gets the short shrift in the digital eco-system.

However, the most beautiful feature or app will fail if it only provides poor content. No amount of technological magic or A/B testing will matter a whit if you don’t have a solid content strategy to make use of it.

A flashy digital interface will fall flat without quality content.
A flashy digital interface will fall flat without quality content.

Additionally, no new feature or app will have any value if you can’t back it up with processes that aren’t so onerous that the producers give up after a few rounds.

The technological aspects, process, and experiential differences between piloting a unicycle and an F-22 are vast, but the core “content” is still a human delivering navigation input. However, applying the same content process to the F-22 will result in failure.

It’s pretty obvious in this case, but folks still don’t make that connection with digital technology.

New digital products often require content and assets to be reshaped to work best; sometimes they require new content entirely. This additional work requires resources, planning, and adaptations of existing business processes.

What appear to be minor front-end changes can have a bullwhip effect upstream in the process if product development doesn’t balance the value versus the business impact. Feature and app development should not happen separate from editorial/content development.

Karen McGrane wrote “Responsive design won’t fix your content problem” way back in 2013 — more accurately, it should state “Technology won’t fix your content problem.” She suggests that editorial workflows should be defined before design workflow. McGrane is writing of responsive design, but it’s no less true of any new feature, app, or product.

“The chicken-and-egg problem of content informing design (and vice versa) just got bigger — call it an ostrich-and-egg problem … Planning for how and when the content team will migrate, edit, and restructure content will help everyone ensure that the content and the design work together.”

No feature or app should see development begin without the full supply chain — from content origination and production, to publication and end-user goal — being considered and clearly defined. As McGrane suggests, this is not only an opportunity to reassess process and strategy, but also a chance to re-enforce cross-team collaboration and communication.

I think it also results in better content and better features and apps.