It takes a lot to publish anything and put it out there in the world. Journalists strive to tell stories and reach their readers through clear-eyed reporting, but no writer can relate to the experience of every kind of reader. Having diverse colleagues at each level — reporters, editors, management — is an important system of checks and balances in the newsroom so that organizations can reach a wider audience.
The same applies for engineering teams who constantly write and ship (publish) code that elicits reactions from anyone who has an opinion. They also face the same lack of diversity that news does. Products, like stories, are shaped by the people who build them and accommodate those perspectives first. Engineers also benefit by having teammates who are diverse in age, ethnicity, culture, gender identity, professional experience and personal backgrounds. That everyone feels safe enough to question decisions and contribute to ongoing discussions to make products more accessible is vital in reaching a wider audience.
As newsrooms and technical companies strive to diversify and find new voices on the organizational level, we can diversify our own perspectives by learning how to work with people with different professional backgrounds, considering their priorities, and seeing how we can reach them as part of our audience. There are many journalistic resources putting the onus on writers to be the ones proactively reaching out to developers, learning how to code and design, all the while improving their reporting and storytelling skills. So, how can developers working in media learn from writers?
Asking yourself and your editors these questions is a good place to start, whether it be at your company, on Twitter or elsewhere out in the world.
SW Leuven/Flickr
Have you seen their CMS? Developers work all over the stack in different teams, so this is completely common to have never seen the story editor and CMS that your editorial friends may spend so much of their time working in. At the places I’ve worked, when engineers see the platform for the first time, they have to ask for support and clarification. There’s nothing quite like trying to use a product than to understand it. Now that you’ve seen the interface…
What does and doesn’t make sense, and can you fix it? When you paste text into the story editor, how do you do that without ruining all of the formatting? Can you preview a realistic version of a piece without publishing? Does the uploaded image appear clearly, and do the caption and credits appear as intended? How wordy are different functions? Are there a ton of mouse hover definitions because the UI terms are confusing? Can those things be fixed? These are things that editors work around all the time, but from a technical standpoint, it’s better to nip actual bugs in the bud than to fix the bug and find a lot of workaround hacks ruining archived pieces in new and unexpected ways.
Is the user experience (UX) of the site accessible to you? Consider your own technical perspective and setup. Are you near- or farsighted? Do you use a non-standard keyboard and mouse, screen readers, extra monitors? How do these tools help you work, read, listen to music and podcasts? When you go to the front and back end of the website that writers use, does it make sense or are there things in the way that you have to sidestep to do work or consume the rest of the piece? If the site needs to be adjusted a lot to be accessible to you, it can be a good start to consider how other readers and writers, perhaps those who aren’t as technical, have to work around the current setup. Developers can articulate UX issues or long-standing bugs into tasks that can be fixed and appreciated by so many users, if only those issues are noticed.
How does editing work? There are two interesting product sides to this answer: firstly, editors might talk about the tools they use and the reasons they use them. It’s always good to know that people use Google docs or another tool to edit body text or leave comments, and if they avoid the story editor, it’s good to know what stands in the way of their workflow. The second interesting component is that editing is very much a technical skill; good editors have to be able to skim through a piece and make structural suggestions, move pieces around to make sense, clean it up, and make sure it adheres to style guide best practices. Learning how good editors do their work can give insight on how to improve code reviews, serve as a lesson to write clean code and become a better troubleshooter.
How do potential freelancers pitch stories to editors? How are these ideas vetted? If you manage or contribute to open-source projects, you know the joy of seeing all kinds of people care about the same thing you do and wanting to make the project better with their feedback. On the other hand, the various pull requests can stack up and can be arbitrary requests that miss the point of what the project set out to achieve. Editors and product managers vet article pitches and feature requests all the time from earnest contributors who truly care about the publication or product and know the most about how to kindly explain no or direct future feedback in a new direction. Asking an editor how they set up will shed light on how the process works, from soliciting pitches to reviewing and editing. It can look a lot like feature requests that come in that developers, designers and product managers vet and talk through before planning to build, and can help you realize other ways to do the same kinds of things.
Previously: Questions every writer should ask developers
