When you’re in charge of content for a product, you have to work closely with the developers building it. This means more than handing off good, clear copy. You have to understand developers, talk to them, work alongside each other, and prepare your work for their code. After all, how your product is built affects how it works.
I’ve outlined specific things to try with your team; these ideas aren’t linear or universal. It’s up to you, as Tim Gunn would say, to make it work.
Set up
Before you start writing, get integrated with your team. Sit with them. Have lunch with them (or drinks, if that fits your team’s culture). Find out how they talk to each other and join in.
Get the tools
Developers typically chat over IRC, push code to a repository, track bugs in a proprietary system, and review their work in a testing environment. Ask your team for access to their tools, so you can make their lives easier and stay in the loop.
IRC
Most dev teams use IRC (internet relay chat) to chat with each other. IRC is a persistent group chat, which lets you join a shared room whether anyone is signed in or not.
To set it up, ask your team for the server address and tips for getting started. Download an IRC client like Colloquy or Adium for Mac and Trillian for PC.
There’s bound to be an overload of snark and server talk. You don’t have to read all the chatter, but it’s important to stay in touch.
Issue tracking system
A ticketing system (e.g., Pivotal Tracker, Jira) helps your team manage and prioritize tasks. Be familiar enough with your team’s tracking tool to find, make, assign, and close tasks. And don’t be offended if a major content request is logged as a bug.
Test environment
A testing environment lets you see the product during development. People have different names for testing environments, like staging, build, or QA.
Get the latest version of the site or app from your team so you can see everything before it goes live in production. You may need to ask for help installing the latest build on your mobile device or changing proxy settings in your browser.
Learn the language
Spend time learning the team’s philosophy and vocabulary. If your dev team lives and breathes agile methodologies, understand the jargon enough to keep up. Most geeks speak human, but knowing the terminology will save everyone time.
It won’t hurt you to learn about programming, either. A basic understanding of code will help you understand your product and write more realistic content. You’ll score points with the dev team too. Here are tips to get more involved with your team:
- Ask your team for an overview of how the product works.
- Learn basic HTML and CSS. It’s not hard; don’t be afraid.
- Find out which back-end programming language your team uses and read about it.
- Watch a 15-minute tutorial about Rails or Python online.
- Talk to your team about the differences in what each of them does. Are they engineers? Programmers? Developers?
Find out how they see the world and why they love their job.
Sync up
Clear communication is key. Set a good example for busy product owners and keep your team connected.
Show up
Meetings can be toxic for writers; developers don’t love them either. But if there’s a daily team meeting or group lunch, make it a priority. Being there will tell you how the product is coming along and let you stop bad content decisions before they start.
If you’re working without a CMS, your content is hard-coded, so a developer will have to make changes for you. If you can, save time validating revisions by sitting side-by-side. Developers live in the details, but it’s your job to check capitalization, punctuation, and styling.
Share goals and ideas
What you make is a reflection of your team’s health. If you take time to discuss your goals and ideas, your product will improve.
Figure out what your development team is trying to do and understand the problems they face. Make sure they know what you’re planning, too. These questions will help you plan your work together:
- What does the client or product owner expect?
- What is most important to the user in this flow?
- What is the purpose of this page or section?
- Which features are planned for the next 2–6 weeks?
- Which parts of the product are most difficult to develop?
- Are there any unspoken restrictions to consider (e.g., political concerns)?
Developers work from client or product owner priorities. Unlike most waterfall teams, their focus may change daily. Finish content for the hardest parts of the product before development starts, and avoid making changes during development. Your team will thank you for thinking ahead.
Software development is a creative process; developers build from a blank canvas. Respect their time and attention by agreeing on the best times and ways to work together.
Fill in the gaps
As a professional communicator, it’s up to you to fill in the gaps between members of the larger team. You are the voice of the customer. You are the connective tissue; it’s your job to bring peace and harmony to the world with your words. Clarify goals, user needs, and critical details for the whole team throughout the project. If you can’t articulate the problem, who can?
Speak up
Defend your work and your customers when it’s appropriate.
Be clear and concise
Whether you’re assigning a bug or fighting for a better user experience, think through what you want to say and give brief, specific instructions.
Create a flexible, repeatable process
Ask your team how to help in their tasks and propose standard processes when you can.
Make a template for content requests
Ask stakeholders to provide you with the information you need to complete a request:
- Why do we need this content?
- Who is the audience?
- Which pages does this apply to?
- When will people see this message?
- Which countries or regions are affected?
- What is the message?
- Is this a priority?
This structure will help you flesh out the content before sending it to your team.
Be specific with your requests
When assigning a task to a developer, include the following details:
- Page name
- Applicable URLs
- Instructions of what to replace
- Screenshots
Taking the time to outline these details will save you time validating content changes later.
Use a friendly file format
Make it easy to move your content into code. For web and email content, I usually work in a text editor and write strict HTML. For a native app, I make a document with the following items for each page of the app:
- Page name
- Screenshot, if necessary
- Content (e.g., interface labels, links, body copy)
- Basic style notes for headers (e.g., h1, h2, h3)
- Notes for reviewers (e.g., stakeholders, legal)
- Relevant error and alert messages
A clear copy document speeds up the approval process with stakeholders and clarifies minor questions from the dev team. When your content is approved and ready for implementation, post it to a central place, like a shared code repository or wiki. Avoid sending anything important over email, as it may get lost in the shuffle.
Say no to bad content
Don’t be afraid to say no to bad content, no matter who the source is. If the content is confusing, talk with your team and fix it quickly. This is especially important when editing navigation, forms, error messages, and calls to action.
Level up
When you’ve mastered the basics, get more involved with the developer community. Understanding developers gives you perspective about how businesses work and helps you avoid making assumptions about product development.
Build your own project
You can learn CSS or build a Rails app without understanding server integration. Pick up a book and bend your brain. Here are some suggestions:
- Dreaming in Code by Scott Rosenberg
- Getting Real or Rework from 37signals
- HTML5 for Web Designers and CSS3 for Web Designers from A Book Apart
Socialize
Next time you’re at a conference for web folks, skip a few of your favorite speakers and watch devs talk to devs. You can also find free meetups with men and women of all ages in your area.
Limber up
Be flexible. Content, like code, is fluid. Adapt your process to suit your team and your customer. Flex those strategic muscles, like so:
- Summarize how you see the product after the next release.
- Share and align your timeline with your team.
- Clarify content priorities before development starts.
- Show the shapes of the content in sketches or wireframes with real copy.
Make sure important details aren’t lost during a fire drill.
Buddy up with your development team. The time you spend working on those relationships will serve you well. With the right balance of communication, patience, and respect, you’ll make great things together.
1 comment
Comments are closed.