Published on <a href="http://ift.tt/2sPfACK">| Prototyping: From UX to Front End &mdash; Medium</a> Saaqshi <img alt="" src="http://ift.tt/2s4VLdv">
I often fall into the trap of thinking that the content I provide to a designer or developer is final and cannot change. But the truth is that copy is not exempt from the iteration that makes agile development agile.
Iteration is good. This is why we have versions of design and code. This is why we have the notion of “drafts” in writing. This is why Hemigway said “the first draft of anything is shit”.
So why commit to something early when the product hasn’t even come to full fruition?
Avoiding the trap
I think part of the reason I fall into the trap of thinking I need to commit to something early has to do with<a href="http://ift.tt/2sPwkcQ"> my imposter syndrome</a>. When people tell me I’m a good writer and they don’t understand how I just “think of things” I get caught in this loop of self-doubt where I put pressure on myself to produce gold the first time. And if you’re like me, you need to STOP doing this.
Other people don’t know how you do what you do, and that’s ok. You probably don’t really know either, but a lot of it probably comes from thinking about it. And in order to think and grow from your thinking, you need to work in versions. You need to put something down, think about it, and come back to it. Don’t be afraid to admit you’re not sure about something because if you live in fear you will be too paralyzed to get anything rolling. Write it down and give your work the space it needs to evolve and grow. And even when it does get hardcoded, don’t let that stifle its growth and ability to change, cranky engineers be damned!
You’re the expert, sure, but you’re not perfect. Let things change if they’re meant to.
Making it work
How to perfectly execute this copy iteration within a development cycle, I can’t tell you. I’ll have to think about it and get back to you (see what I did there?). I explored the topic a little bit <a href="http://ift.tt/2s5d4eh">here</a> and <a href="http://ift.tt/2sPBrK0">here</a>. And below you can find some more tips that may help.
Get involved in the design and development process early
Copy shouldn’t be an afterthought! Get invested in the project early and look at wires and talk to designers so you can start to understand and define the spirit of the work. While you’re getting involved early, play nice with team members (perhaps by bringing in baked goods) so when it comes time to change something you can readily play the Friendship Cookies card.
Document your changes
Writing stuff down (including some of the rambling thoughts you have when thinking through a problem) helps you see growth, serves as evidence for why copy needs to change, and helps you solidify your voice and strategy
Use the tools your team uses
Using the tools your team uses will make them more receptive to feedback. For example:
<ul>
<li>Leave comments in Zeplin or suggest changes in Sketch if that’s what the designers are using</li>
<li>Request copy changes in Pivotal Tracker if that’s the easiest and least disruptive way to get an engineer’s attention (from my experience, you don’t want to show up at their desk unannounced when they’re in a good zone)</li>
</ul>
Have any better ideas on keeping UX writing agile? Post below.
<img src="http://ift.tt/2s4VQO4" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="http://ift.tt/2sPAotX">Reiterating the obvious: writing is iterative</a> was originally published in <a href="http://ift.tt/2cAqCpx">prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Reiterating the obvious: writing is iterative

Top Stories