Many content designers come from editorial or journalistic backgrounds, and while digital continues to become the dominant force in those roles, an agile approach to working hasn’t been adopted by everyone.
As a content designer, being thrown into an agile team without agile experience can initially feel daunting. It might seem as though everyone is speaking a different language and it’s likely that there’ll be a number of new tools to use.
It can be easy to think that your involvement in the agile process isn’t necessary, and that it’s something only the developers should be part of - but this isn’t true. As a content designer, you should involve yourself as much as possible, and it might not be as difficult as you first think.
Here’s my advice for content designers looking to align their work with the agile process.
Understand the agile process and terminology
First it’s important that you grasp the agile basics. This will include the process the team follows and the words they use to describe it. Not everything will be directly relevant to your role but the better you understand how the team works, the better you can be a part of it.
A glossary of some basic agile terms can be found at the bottom of this post.
Listen and contribute in stand ups
You’re not going to need to understand every detail mentioned at the daily stand up meetings, but it’s important to listen and contribute. Stand ups should be brief, but if something’s mentioned that you feel may be relevant, ask for clarification if you don’t understand.
In the stand up clearly let everyone know what you’re working on and if there are going to be any delays. If a developer is waiting for content from you and you’re waiting for sign off from a policy maker who is on holiday, make sure this is communicated so work can be reorganised if needed.
Find your place in the process
If a developer has a story to work on in the current sprint and soon learns that to implement the story 250 words of content are needed, it’s likely to cause some issues. Of course you could churn out 250 words that you think will do the job quite quickly, but the content should have been drafted, proofed and tested on real users before going into the code.
To avoid such issues it’s important that you keep a close eye on the agile board, so you’re aware of the stories that will require content. Once you get into a rhythm, you might find that proactively working several sprints ahead works better.
That said, when a task can’t be completed because the required content isn’t ready, it’s best to get something in place immediately and iterate later. There’s the risk that an impatient developer might write the content themselves to move on. This could come back to bite you later, as while the content might be okay and follow house style, the developer is unlikely to have your expertise and acute understanding of how users have responded to content in testing.
The content within a service and across services needs to be consistent in style and language. If content exists within your service that you aren’t aware of, it’s easier for inconsistencies to take hold. Error or validation messages, for example, can often be overlooked when designing the content within a service.
Get used to working with non-content people
I began my work as a reporter, turning out thousands of words a day. And I would sit within a team of others doing similar work. We’d ask each other questions about particular words and their exact meanings, and regularly have each other read over the paragraph we’ve just written. In the world of agile, teams are based around the product rather than discipline.
Rarely have I worked on a product where there’s been the need for more than one content designer, although most products will have more than one developer. I often overhear developers discussing code at the level I used to discuss words. And while most English speakers will be able to help you find a better word to describe x when your mind goes blank, the reviewing of your content should ideally be done by another content designer.
Attend the user research
Attend as much of the user research as you can and look out specifically for those problem words or phrases. Have the researcher ask the users to explain what they think is meant by the phrase xyz.
Work closely with the user researcher in preparation for the sessions, and take the opportunity to test certain words or phrases, either in the prototype or on pre-prepared cards. Asking users to fill in the blanks can be a useful way of understanding the language they use to describe the product or service, rather than putting words ‘in their mouths’.
Get involved in a project from the discovery phase
Being involved with a project from the very off, helps you understand the subtleties of the project and the end users. In the early stages there will be a lot of research done that can validate content decisions further down the line, and a number of assumptions will be made. Knowing these assumptions can help you shape further research.
Content is too often seen as the last step before a new product is deployed, and it can then be too too late to change the design. Getting real content into the product earlier makes it easier to get user feedback on the language used to test any assumptions.
If a prototype containing placeholder content, such as lorem ipsum, is put in front of a user, you might learn something about the layout. If a prototype is put in front of a user containing content written by a developer, you might only learn what’s been learnt in previous research sessions. If a prototype is put in front of a user containing content that’s been carefully designed with the consideration of previous previous research in mind, then you’re more likely to learn something more new.
Have conviction in your expertise
There’s more than one way to convey a message in written words, and most English speakers are able to do this effectively. However, it’s important to have conviction in your expertise. This is your craft. You have been employed to do this work based on your skills and experience. And while you’re open to suggestions, and prepared to have your carefully written content picked apart and rubbished by users, your expert judgment and experience is what makes your role a crucial part of the process.
When the code breaks, a developer will fix it. When the words aren’t right, the content designer will need to make them right. This distinction in responsibility is clear. Own the content.
Glossary of basic agile phrases
| Word or phrase | Meaning |
|---|---|
| Stories | The work will be broken down into single tasks and each one will be written as a story and added to a backlog. |
| Sprint | This is period of time in which work will be completed. |
| Sprint planning | Before, or at the beginning, of each sprint stories will be picked from the backlog to be worked on. Each story will be given points based on their size. |
| Epics | An epic is a large story, that can be broken down into smaller stories. |
| Blockers | A blocker is something that prevents a story from being completed. Examples might include not having the required content on time. |
| Spikes | A spike is something that needs to be investigated. |
| Velocity | A good agile team will be able to accurately predict how much work it can take on per sprint. This is why each story is given points. At any time during the sprint, the velocity can be calculated based on how many points have been completed so far. |
| Retrospectives | At the end of each sprint, a retrospective meeting should be held to look at what went well and not so well from the previous sprint. |
| Show & Tells | These are really important parts of the agile process, and the opportunity to show off what’s been achieved and why decisions have been made. Show & Tells keep stakeholders up-to-date and are also useful ways to share knowledge with other teams. |
Let’s share
Do you have a different approach or thoughts on what we’re doing? We would love to get your thoughts, inputs and experience in the Comments section below or via twitter.
2 comments
Comment by cleavy posted on
Great stuff - thanks Ben.
Comment by Maria Watkins posted on
This has been a great help to me. Thanks!