My UX writing process.
When writing is only part of the role.
How I approach UX writing
To borrow (and modify) a line from The Mandalorian: “UX writing is a com-pli-ca-ted profession”.
And that’s because writing is only part of the role.
To produce the words on the screen often involves communicating with a lot of people inside and outside an organisation.
As part of the design team, I think like and approach my work as a human-centred designer – understanding the users, identifying the real problem, learning the technical capabilities and limitations of the product, and (also important) gaining insight into the wider business objectives and how the product sits within and supports these.
My UX writing process varies depending on the product, users, timeline, the way the team works, at what stage I’m brought into the project, my level of knowledge of the product, and many other factors.
I’ve learned how important it is to be flexible, have a bias towards action, deal with ambiguity and adapt to circumstances.
My process tends to incorporate most of the considerations below, but there can be a lot of overlap and jumping back and forth between some steps. Whether an org uses a Double Diamond approach to design, or a custom variation like The Atlassian Way, most of the things I mention apply.
In the end it’s all about the user. If the user wins, the business wins.
The aim is to create a product that doesn’t just have product-market fit, but product-market pull. Solving user problems so well that people are magnetically drawn to the product - they can’t help themselves.
So, here we go…
1. Research the users, context, product, resources, and project.
In the initial stages of a project, I’m working hard to wrap my head around the scope and requirements, getting to know my team, working out our cadence and workflows, and learning as much as I can as quickly as I can.
As my focus is on creating a great user experience, I almost always start by learning as much as I possibly can about our users and the product to figure out: what is the real problem we’re trying to solve?
Who are our users and what are their problems?
What caused these problems?
How do their problems make them feel?
What’s the product?
How does the product work? (I get into this in DETAIL: I like clear maps of user flows, processes, screens, etc.). Possibly one of the most important things I need to understand to be able to write the content. With a new product, I won’t know this information at the start of the project as we’ll be creating the product along the way.
What’s the ‘why’ of the product? How did the idea originate? Is there a clear vision or mission? And why this product at this time?
How does the product plan to address users’ problems?
What’s the product-market fit? How much work has been done on researching this? Does the product address a minor problem experienced by most people? Or a major problem experienced by a few people? Or a major problem experienced by a lot of people?
What tools and resources do I have to assist me — technology, apps, collaboration tools, voice & tone guides, style guides, design system, researchers, team members, consultants, historical data, documentation?
Who are the key stakeholders and what are their values? This includes my team, cross-functional teams, line managers and skip managers (and higher), contractors and external stakeholders. I’ll often draw up a spreadsheet of stakeholders and their roles and values, empathy maps, and interest vs influence maps, to help me more effectively inform, engage, and build relationships with individual stakeholders, earn their trust, and establish rapport.
Who has final signoff on design & copy?
If I’m joining an existing team, how do they like to work? What systems and processes do they use? It’s almost always some variation of Agile, with JIRA, Google (Workspace, Meet, Docs, Gmail) or Microsoft (Outlook, Teams), Slack, Notion/Confluence, Figma. I’ll also ask members of the team how I might best support them to help them succeed in their roles, and think of ways to make the experience fun and enjoyable.
What are the goals and objectives of the project? OKRs? North Star, Big Rocks — a goal is a goal by many names. I like these defined as succinctly as possible and see clear agreement on them across the entire project team. It’s important to really drill down here and make sure OKRs are specific, and that there’s a shared vision and mission for the project!
How long do I have to work on the project? On the various sections? Is there a roadmap or timeline?
Is this a new product, an existing product? Is it only a feature of a new or an existing product? Is it an internally facing or externally facing product?
All through this early stage of understanding the project, product, users, process, and stakeholders, I’m working out:
How to analyse the problem.
Where to start research.
What I’m looking for and what’s most important.
How I can break the problem down into easily manageable (and understandable) pieces.
2. Strategy and analysis
Many of the following steps occur over and over, throughout the project, as the product is developed, tested, iterated, etc.:
Meet with stakeholders, understand their goals. Build relationships and rapport.
Analyse how the product, feature or solution supports business objectives.
What does success look like for the project, and how do we define it and measure it?
Meet with developers to understand the technical requirements and limitations of the product.
Are there risk and/or compliance issues? If so, how can I be transparent with users and balance the need for transparency with protecting the company? Issues need to be flagged and up-front conversations had around them.
Could there potentially be ethical issues with the design — either inadvertent or through organisational / stakeholder pressure to use dark patterns or misuse data?
Anticipate resources I may need at various stages of the project.
Discuss timelines and product roadmaps and build-in buffers and contingencies.
3. More research and exploration
I’ll often start doing competitive and comparative analyses — are there other products tackling the same problems I’m trying to solve? What do these do well, and badly? How is our solution better or different? What’s their standard of UX writing?
If I’m working on an existing product, do we have any data from previous research, usability testing, or A/B testing?
I’ll start to list assumptions about our users, and flag possible biases we may have.
4. Ideate
I find ideation one of the most enjoyable parts of the process. It’s a collaborative process. It’s where the team actually gets to start coming up with ways to solve problems. Gathering the team, firing up FigJam, Miro, a Confluence whiteboard or equivalent and getting to work!
Brainstorm lots of content ideas & refine. Overwrite and then filter down to the best ideas.
Dive into user intent, what the user needs to accomplish through using the product; what they need to accomplish by the end of each process within the product; how they might be feeling about each step; what will they be trying to accomplish at every individual screen or step, where they’ll have come from and where they’re going next.
I’ll base my solutions on good UX writing principles (clear, concise, useful, a dusting of brand voice, etc.), and try to understand the users’ emotional state at each step (and throughout).
As mentioned, we’ll often use a variety of tools here: typing in a doc, iPad & pencil, whiteboards (digital and physical), Post-It notes, Miro, hand-drawn sketches, mind mapping. This stage can get messy and wall-papery (as in, covering the walls with post- its and pages, or writing on the walls if they’re covered in whiteboards).
5. Explore ideas with the designers and write
The most important part here (and at all stages, really) is the mantra: “Share early, and share often”. Especially when working in a large organisation with experienced and talented colleagues.
Sharing work at every stage of development, and soliciting feedback, has saved me many times from wasting time and effort when another designer picks up on an error, or the entire concept needs to be thrown out and reworked. Besides, it’s fun to collaborate, get great feedback, talk design and learn from other designers who work in different disciplines! It doesn’t matter if it’s a lo-fi prototype or draft copy when working with good designers. One needs to balance sharing/feedback, however, with making decisions and getting on with the job. I’ve seen teams in large organisations spend time in endless feedback loops, a simple design taking far too long to get finalised. This lack of confidently moving forward and endless circling back will quickly burn out designers.
At this stage I’m using a content-first approach, I’m working with the UX/UI designers (ideally from the very start of the project) to understand what the user needs to know and when, then building the design around what we need to communicate to the user on every screen and, where necessary, adapting the content to the limitations of the design or technical & functional limitations of the product.
This is where the product or feature really takes shape and becomes a workable prototype – with useful, functional content that obviates the need for ever having to use Lorem ipsum placeholder text. Some things we might ask ourselves or try are:
Look at where we need to add structure.
Are there opportunities to combine disparate ideas and create original solutions?
Get consensus on user intent at each step of every process when using the product.
Try to break the design. Does anything break it?
Refine user flows, eliminate unnecessary steps, combine steps where possible.
Are automated emails and popup error messages appropriate, necessary, triggered by the correct user actions, clear, and reference each other where appropriate.
How can we reduce cognitive load? Can we break up information-heavy areas into smaller chunks, or split multi-action screens into separate single-action screens?
Ideate as many use cases and edge cases as possible.
Are there places where the design can remove the need for words?
Where should we work with existing user mental models and expectations, and where can we depart from these (and with what result)?
Simplify. Simplify. Simplify.
Engage with UX researchers, product managers and stakeholders throughout.
Explore whether a First Principles approach to any part of the design would create a better experience.
This stage is usually where I’ll start to write content directly into the designs in Figma, sometimes creating a dedicated ‘playground’ page into which I make copies of the designs so I can draft content without risk to the original design files.
Build prototypes for testing.
I’ll also create Copy Docs – a Notion or Confluence doc for each screen/JIRA ticket, with the copy brief, approach, comments, any screenshots, draft copy, and design rationale presented in a table or grid. Useful to later articulate design/content decisions when presenting to stakeholders.
6. Usability testing
Test prototypes with functional content.
During usability tests, listen to users and note their language. Does our voice & tone match the way our users talk?
Gather post-testing insights and user feedback to inform decisions.
7. Edit, iterate & polish
Review user feedback. List content issues and ideate solutions. If possible, re-test identified problem areas after updating with new content.
Flesh out the content. Try to leave at least 24hr between writing and reviewing the same piece of content. Why? It gives you some distance from the work and fresh eyes to see all the mistakes you made!
Is the content clear, concise, useful? Does every word count? Is content consistent and (where appropriate) conversational? Does it have that sprinkling of brand voice that makes it sound like us? Do the sentences have rhythm and economy? Rhythm is critical to good writing — how a sentence sounds aloud (or in one’s head) is AS important as what the words say.
Does the content mirror users’ mental models? If it doesn’t, is there a reason for this and can they easily adapt?
Will unexpected content positively influence our users’ way of thinking, help them complete tasks, delight them or make them pay attention?
Does the content solve the user’s problem and help them complete tasks?
When the content helps the user complete their tasks and (hopefully) delights and/or entertains the user — does it do these things at the appropriate steps in the user journey? Is the voice and tone at each step/screen appropriate to the user’s emotional state, intent, actions, type of message and the nature of the information being conveyed?
Are there any localisation/translation issues (e.g., sentence length issues in translation; idiom or colloquialisms that won’t translate across cultures)?
Does the content follow Plain English guidelines?
Check the grammar against appropriate style guides (e.g., Chicago, APA, Style Manual 6th Ed. (AU), etc.).
Does the content align to our Voice & Tone and product content style guides?
Is the content accessible, does it conform to WCAG guidelines? Have we tested accessibility of the design with various screen readers, etc? Which plugins or systems have we used to test accessibility (they vary in how they report and how many issues they flag)?
Do all the images have accurate, concise and descriptive Alt-text?
Is there anything in the content that will quickly date it?
Run a microcopy review and check clarity, necessity, usefulness, and appropriate messaging whenever input errors can occur.
As the saying goes, “Writing is rewriting”. And this stage is all about taking the functional copy from the prototypes and attempting to turn it into clean, beautifully written copy.
8. Delivery
Final consistency checks, capitalisation, detailed copy editing, proof reading, formatting.
Have another writer / editor proofread the content. Always.
Present to stakeholders. Articulate rationale behind word choice and content design decisions. Make any changes required, loop back to stakeholders. Repeat as required.
Get final signoff on the content & ensure PM/designers/dev can access it.
9. Evaluation, learnings and repeatability
Have a post-delivery debrief. What did we do well? What opportunities for growth and improvement can we identify?
What did we learn from the project? Are there any key findings that we can present to the rest of the organisation?
Did we create any assets, develop any systems, or establish processes that could be useful in other parts of the business? For example, a Design System (I’ve seen this happen!), or reusable tokens, elements, content guides, collaborative processes, templates, etc.? If we did create assets, engage others in the organisation, present our solutions and experiences, and be ready to assist them to implement these in their teams and projects.
Measure success (short-term & long-term), actual outcomes vs original goals & objectives.
Revisit, monitor, gather data, test, review and iterate new versions as required.
Write up a summary of the project, metrics, one’s role, etc. in a design diary, to look back on when it’s time for performance reviews.
And that’s an outline of the approach I’ve been using the last few years. It’s mostly grown out of working with wonderfully smart, creative and way-more-experienced people — people who’ve been there to help me learn and grow as I moved between and within organisations, gaining experience in UX writing, content design, content strategy, content operations and designing for AI products.
Peter Dickison, February 2025
