5 questions every UX writer must be able to answer about their projects
Do you find yourself tongue-tied whenever someone at work asks you about your project, or when a stakeholder questions why you made certain decisions? Do you, like me, admire colleagues who can think on their feet and speak with confidence?
As the bulk of what we do as UX professionals revolves around communicating with colleagues, being able to speak clearly about what we’re working on is fundamental.
Recently, I’ve had the luxury to think deeply about the things that I’m working on, and I realise that in order to think and communicate clearly about any project, I need to be able to answer these 5 questions at any time:
Why are we building this?
Who are your users and what do they need?
What is the rationale of the UX approach?
How does the current iteration solve the main user pain points?
How can we measure the impact of copy within this project?
If you’re reading this at home, try answering them out loud. Not easy right? These questions may be simple, but they’re extremely loaded. The answer is often complex, but in order to speak with conviction, you need to find a way to summarise and convey the most important point with precision.
Why are we building this?
Let’s start with the most profound question.
If someone outside of my product team who has zero knowledge about what I do asks me about my project, am I able to explain clearly why my work is important in a couple of sentences?
In order to put your project within the company’s perspective, you first need to know how the thing that you’re working on is helping to achieve the company’s larger goals.
UXers are craft people, so we naturally think about how to solve specific problems. But if you want to be seen as a key team player, you’ve got to think beyond your craft and dig deep into why the company is paying you to work on specific projects.
There are many reasons why a business might invest in building a product. Perhaps it’s to build an additional revenue stream. Perhaps it’s to solve a big user pain point. And God forbid, it might be something unjustified like “because everybody else is doing it”. (I recommend this interesting article on how the tech industry stopped building things that customers want. The writer’s argument is that people don’t want more tech or genAI, but rather, the convenience that the tech can bring.)
I’ve also come to realise that while we’re supposed to rely on data and research to make decisions, a lot of things are still open to interpretation and intelligent leaders still make decisions based on gut feeling. You don’t need to hunt down every decision that led to the start of the project, but as long as someone outside of the team can see the value in why your product team exists, you’ve got your answer.
Whatever the reason for building the product, it’s more important to know who will use it and what they need from it.
Who are your users and what do they need?
If you want your colleagues to remember what you’re working on, start with a story instead of bombastic stats. I love this quote by Alan J. Porter from the Content Strategy Insights: Alan J. Porter: Storytelling for Enterprise Content Strategy podcast episode: “But if you don’t put the story around the data, all you’ve got is numbers.”
Are you able to tell the story of the project from the perspective of a specific user? Are you able to step into this person’s state of mind while experiencing the product, and see why they’ll need specific information or guidance?
Alan mentioned that every good story needs 4 C’s: character, conflict, choice, and consequence. So a story can be something like…
Character: Imagine that you received some credits to spend on our e-commerce website via email.
Conflict: You click on the email CTA, and when you arrive at our e-commerce website, you don’t see any indication of the credits.
Choice: You navigate to the ‘Profile’ page but see that the credits were not added.
Consequence: You contact customer service to ask about how you can spend the credits.
With a character in mind, you can then supplement it with impactful data like ‘While the spending credit email drove traffic to our site, only 30% of these visitors made a purchase’.
If you’re doing a presentation about the project, use the user’s direct quotes to convey their frustrations. And if research has been done, showing a short video clip of a user struggling to use a product feature is even more powerful and can sway the most stubborn naysayers.
The thing about user research though, is that its insights are always debatable. There’ll always be stakeholders who argue that a handful of qualitative research isn’t representative of the entire user base, or that participants didn’t understand the information on a screen because it was a prototype and they were not personally invested in trying to understand it.
That’s why it’s very important to fully understand both the research insights but also its shortcomings. By knowing important facts at the top of your head, you’ll be in a better position to offer a counter argument when someone challenges your point of view. It’s also good to have these sources of truth readily available so you can send it over to the said naysayer as quickly as possible.
What is the rationale of the UX approach?
Once you’ve identified the problem and understood what the users need, can you verbalise what UX is doing to solve it?
Depending on who your target audience is, you’ll need to tweak how you explain this bit.
A UX audience would lap it up if you said, “We aim to reduce the cognitive load by redesigning the information architecture.” If you said that to non-UX colleagues though, the message would surely fall flat. For a general audience, you’re better off saying, “We aim to redesign the content so that users can find the information they need easily.”
I also can’t overstate the importance of having good documentation. Yes, it’s time consuming and requires discipline to update, but ultimately, it’s an invaluable artefact that can
help stakeholders understand how and why UX made certain decisions
help the product team get a better context on the end-to-end user experience
help new colleagues onboard to the project more seamlessly
help you build a case study for your own portfolio
When justifying the approach that the UX team took, highlight the long-term vision first to illustrate the purest UX ideas, then explain the constraints, dependencies, and trade-offs which led to the current proposal.
The first iteration in an agile environment will never be perfect, but it should be the best approach based on what the team can control within its scope.
Working in a big company is complex, but it’s how you deal with this complexity that makes you stand out. As Pascal Potvin rightly says in his article about the relationship between office politics and UX design, “Creating exceptional designs is only half our job.”
How does the current iteration solve the main user pain points?
When you’re in the trenches tackling everything from writing microcopy to planning out the timeline for UX deliverables, never ever lose sight of the users. They’re at the core of what we UXers do, and I often have to remind myself to pull back and step into their shoes over and over again.
Even when all the dots seem to connect, make it a habit to sense check the current solutions from time to time. After all the compromises, can the MVP still solve the key user pain points identified at the start of the project?
Remember that just because a lot of people are invested in it doesn’t make something good. One thing I really like about working in a European environment is that people like to question and challenge decisions even if they were already agreed upon. It’s something that I’m still getting used to, but I believe it’s a healthy environment to have if we want to continuously improve our work.
Also, when going down the road of edge cases, think about how often they happen before trying to solve for every scenario. If the volume is small then it can be deprioritised. Do not spend too much time trying to solve thorny issues which might not be able to move the needle.
How can we measure the impact of copy within this project?
No man is an island, but writers need to prove that the country of Content is important.
The truth is, anyone working in a company, especially if it’s a big organisation, needs to justify their pay check. It’s not just UX professionals — we just like complaining about it a lot.
If you’re an individual contributor, it’s handy to have evidence of how impactful your work was. And being part of a successful project is not enough. It’s a flawed system in my opinion because team work is crucial for any employee’s success. But if you want to get noticed by leadership, you have to find a way to measure the value of content.
For example, if you can say, “I did an A/B test of a new CTA copy which led to a 30% increase in conversion,” it’s very clear that the updated copy led to more conversions. However, if you say, “I worked on the homepage redesign which increased user satisfaction scores by 30%”, it’s not as impactful as the satisfaction score could be attributed to improvements in the visuals or loading time of the homepage.
Given that measuring impact continues to be a pain point (Nielsen Norman Group’s recent survey of 126 UX practitioners pointed out that ’no stakeholder buy-in’ and ’no measurable impact’ continues to be a struggle), you need to think very strategically about doing work that can be measured. It’s not always possible, but it’s necessary to keep your eyes and ears out for opportunities to where you can quantify the impact of copy.
Some language-specific metrics to consider:
Rate of error messages
CS tickets related to information clarity
Content and localisation production time and costs
Content audit scores
Whenever I notice myself getting carried away with doom-linking or staring at a problem for too long, these 5 questions can always steer me back on track.
