Creating Editorial Process Before A Finished Product
Building news products is fun! But it takes time, patience and lots of experimenting with even the most simple concepts.
When you’re hired to help build a thing, it’s easy to get wide-eyed. You dream of the end-goal and get hyped (this is OK!).
The reality? The thing is actively being built, workshopped and tested. You have pieces of the whole, but no finished puzzle (this is also OK!). At this juncture, it might feel easier to just wait until there's more to play with. And I get it: journalists aren't traditionally trained to operate without platforms. No excuse! The jobs of the ~future~ require us to think and act before developers hand us shiny tools.
But without all those bells and whistles, one might ask, what's an editorial team to do? The BuzzFeed News app team has a talented crew on the editorial and product ends of the operation, and these teams work closely to make the concept of the app a reality. And in the interim, instead of twiddling our thumbs, we fired up our Google Docs and Evernote files and got moving.
The recent FCC vote on net neutrality is a great example. Our team determined that we could learn several things by tackling it, even without a "finished" product in place:
- Editorial process during an important story
- Best communication methods during breaking news
- "Wish list" of features for news scenarios
During the FCC vote, I was assigned to curation and coordination of both BuzzFeed News' coverage and that of other media organizations. I also monitored a livestream of the proceedings for push alert opportunities. Millie worked as a back-reader for analysis and contextual write-ups about net neutrality. And Sam rolled our efforts into the app's flow and presentation. We documented in Google Docs the situations that we thought would work best, and used our Slack channel to talk through steps, including those as granular as "X Editor sent stories and bits of information to Y Editor."
This model is implemented on newspaper breaking news desks and online-focused newsrooms all over — it's a traditional structure that applies well to real-time, social-driven news. But assuming that a new team will adopt these principles without explicit goal-setting and parameters established is a recipe for disappointment.
At Breaking News, where I worked as an editor before joining BuzzFeed News, my team had fine-tuned a workflow and shift handover system that played extremely well into the organization's goal of being fast, accurate, and deliverable. We revisited the structure often, communicated it as much as possible, and improved upon our core product by doing so.
In the context of product development, this approach allowed #teamnewsapp to identify problem areas and brainstorm potential features. For instance, we learned that a story like net neutrality would need interspersed explainers (go figure), more so than other news stories of that day. This became a point on our edit team's wish list, and an actionable request for the developer team.
A few weeks later, our app's alpha had clearer customization options for notifications and we applied what we learned to coverage of the Apple Watch announcement. We dedicated an editor to alerts and had another editor focused on the look and feel of the app. Now, when approaching stories with the potential for alert customization and special sections, we have go-to editorial processes.
It might feel awkward and kind of frustrating to go through the motions of these workflows without a complete product, but the lessons learned can be invaluable during the early stages of development. Too much process can weigh on a team tasked with experimentation, but having none at all will almost always lead to more confusion.