Table of Contents
UX redesigns: knowing what’s what
I get messages from aspiring UX writers pretty often. Many people want insight into what the job really entails—what will they be expected to do? What will they be expected to know? How will I know how much or how little I should do? And where do I draw the line?
I love getting these questions because it gives me an opportunity to offer a clearer picture of what a real-life job in UX writing is about.
What comes first, the copy, the design, or the product development?
It’s a little bit of a chicken or egg situation. And the answer is similar: none of them can exist without the others. I mean, you can try, but you normally don’t end up with a very pretty or functional product.
Scenario
We are asked to rewrite some copy for a feature that allows users to comment on posts. When the user is viewing a comment on their own post, something appears to indicate that another user is in the process of typing a reply. Examples may be “someone is typing a comment” or an ellipse “ … “.
Should we just write some copy to replace the existing one? Or might there be a better approach that involves making changes to the UX?
As writers, we need to know how to best approach an assignment when it’s given to us. Do we build around the technology that exists and only edit the copy as asked, or do we design features with the expectation that the developers will figure out how to do what we ask? And if the latter, how do we know what the limitations of the application or tech are so we can design a user experience that actually works?
First, we should understand that every product team approaches product design differently, and the question depends on if we’re building a new product from the ground up or if we’re being asked to come in after it’s already built and fix or change something. A UX writer is often asked to “replace some copy,” and rewriting some copy would be a completely appropriate thing to do. It would get the job done and satisfy the stakeholders.
But a good UX writer wouldn’t just look at that one screen and be satisfied. We’d always want to think about a UX redesign. We would ask a lot of questions about the context of that screen to the feature and that feature to the entirety of the user’s journey through the product. We want to understand what the user is trying to accomplish when they arrive at this screen and map out what they might be thinking or feeling at that point in the process. We might ask for data from heat maps or conversion rates, and if no data is available, we might do some research, propose user testing, or conduct some ourselves.
The most effective content designer behaves as a high-level product designer. Having the big picture perspective is vital to understanding the user experience. And all the best UX decisions are data-driven!
UX redesign questions
How much are we expected to know about how the technology works? How do we know as writers if something is possible?
It’s really easy sometimes to imagine a UX redesign and better way to do something, but we’re not programmers. (Well, most of us aren’t, anyway.) When dealing with software functionality, how do we know the limits? Where do we draw the line with certain features? And how do we deal with it if/when developers shoot down one of our designs?
Scenario
A user uploads a file, and there is an error with the upload due to a file name that is incompatible with the system. You must write an error message indicating that the file name must change before the upload can work.
If we want to suggest that the system auto-generates a name suggestion and gives the user the ability to accept that name with the click of a button, can that be done?
A lot of the knowledge about what’s possible comes from experience. If we don’t have a technical background, we can simply pull ideas and inspiration from other applications we’ve used or digital experiences we’ve seen. Logically speaking, if someone has done it before, it’s possible to be done. We can keep an eye out for different trends in how users navigate their way through experiences. We can screenshot or bookmark sources of inspiration when we see something we like.
Over time, when we get more experience under our belts working on a team with designers and developers, we’ll have a better sense of what is possible because we can ask them before we dive too deeply into a feature design. Until then, be a sponge!
And as far as pushback goes, if a developer ever tells us that something isn’t possible, there’s no harm in asking “why not?” It might spark a productive conversation that can improve the product in the long run.
Writing copy or a UX redesign?
Whatever happens, my advice is don’t be intimidated by not knowing something. It’s not our job to know every moving part of what we build. It’s our job to understand and advocate for the user, figure out what questions to ask, and iterate based on those informed answers. One of the most beautiful things about the content design field is that everyone has varying degrees of experience in a wide range of areas. There is no requirement that every UX writer have a background in tech, writing, or design. The perfect job is out there for everyone.
