I am currently working on a web based application and we have wireframes and style guides. Our process works something like this ... designs for each major flow are prototyped and visual creates the style guide for the representative screens and screen elements. Dev works along with UX and Visual to understand the wires + visual and build the final product. The ID (information development) team then looks over the developed screens and tweaks / re-writes things as they see fit.

The wires do not showcase every single message, tooltip, help text example and for some flows where the screen to screen interaction is exactly the same across multiple screens we don't show them all.

So my two fold question is, #1 what team should own the body copy (such as feedback messages, field labels, instructional text, tooltips, ect...) and #2 is there some deliverable that this copy should live in (either the style guide, wireframes, some external copy from the writing team?

Also, feedback or any other insights from people's personal experiences with this sort of thing would be greatly appreciated.

  • If it is a question I'd say you should step up for the sake of consistency of nomenclature and the experience overall. Otherwise, a content strategist or at least a copywriter should be part of every project to make sure you follow the copy style guide (a style guide should include copywriting).
    – Mark Sloan
    Commented Mar 31, 2014 at 23:04

4 Answers 4


The person who owns the body copy is the person who is best-suited to own the body copy. The specific deliverable where the UI text should live is the deliverable where everyone knows where it is, knows who owns it, and is able to easily access it when they need it. As such, the answers to these questions depends on your project and on the team.

On some teams, there are technical writers whose job is solely to write the text that appears in the UI, including the labels for fields, explanatory text in wizards, and tooltips. In other teams, the designer owns this as part of their UX work, and they are uniquely situated to do it because they understand the workflow, the user goal, and application. Still other teams are structured such that the program manager owns it as part of the specification for a given feature. In each case, the most important thing is that the person or people who own the text are the people who are best suited to doing such work.

Likewise, the deliverables are dependent on the team as well. For some teams, all communication occurs in their bug-tracker, and thus the UI text lives in the bug-tracker too. Some teams use wikis. Some teams specify this as part of their feature specification process. Some teams have highly-specific formats for saving their UI text, often for the purposes of internationalization. (It's my experience that if it's the latter case, there's most likely to be a writer who writes the UI text.)

If you are in a position where it's unclear who owns this, then you should identify who is best-suited for this role, and what is the best way for the UI text to get written and updated when the inevitable changes to the UI occur. You might learn that there is a writer who is frustrated because they feel like they've been left out of the process, you might learn that there is a designer who is very good at writing such text. If it's falling to you to write this text because no-one else is doing it, then do the best job that you can of writing great text, documenting the text that you have written, and being able to hand the task of writing off to someone else who is better suited to it in the future.

  • Or at the very least the person who owns the body copy ought to be responsible for finding someone within his team / organization to write / edit the copy.
    – Mayo
    Commented Nov 26, 2014 at 19:31

Disclaimer: I'm biased, having worked as a dedicated UI text editor and writer on UX teams for 15 years (on top of several years of documentation experience). That said: ideally, there are trained content providers that work with PM, dev, design, and user experience teams to ensure that the UI text (control labels, messages, tooltips, instructional text etc.) is technically accurate, grammatical, concise, user-oriented, and all that good stuff. Sometimes the temptation for management is to cut costs and delegate text responsibility to someone from these other teams (on top of their other, more "significant" expertise and duties). However, there are numerous problems with this, including (not least) a faulty grasp of English for many folks who haven't gotten a degree in it - even if it's their first language, which in my experience is often not the case. It's HARD to write minimal and yet helpful text.
Writers getting in on the ground floor is the best approach, during design, as textual challenges often uncover design flaws, and trying to patch a bug with weasly language after it's been coded won't fool users. Beyond that, there are a multitude of organizational flavors, processes, tools, etc. that teams can go with - both agile and not. Currently I'm adding text to a table within the spec; plus I create the ID code that the text is associated with (the text is not hardcoded in the UI). Devs copy and paste from the spec.



Good question. I say this because copy is often a hot potato in the product process. Some of the issues:

  • Copy by committee is highly unpleasant and gobbles everyone's time
  • Designers have unusual minds, so their copy choices are often awkward
  • CEOs tend to insist on words that strike the wrong tone – and it's hard to push back on them
  • Many product teams have small or ad hoc structures so the ownership of copy flits around

A quick and dirty rule is: copy ownership falls to the owner of the product. However, anyone who is deemed the owner of the copy should not write it in a vacuum. It should be vetted by a trusted team, when possible.

Here is the hierarchy of copy ownership as I see it, meaning if you don't have the role in your team, skip to the next one in the list. If you have multiple roles represented, the topmost is the owner, and the others make up your trusted team:

VP of Product. Accountable for all product aspects, can delegate copy writing to a team member and vet the work, can make cases and get buy in from C-level folks.

Product Manager. In agile development, the PM is the product owner, and so all aspects fall upon this position ultimately. The PM will know the product most intimately.

VP of Marketing. Owner of the brand, and thus messaging, tone, language, and voice.

Design Director. (highest ranking designer) Most likely the brand owner if the above are missing. Responsible for tone, brand perception, and product experience.

CEO. If all of the above are missing, it is a small team indeed, and so it is truly the CEO's baby.


The official copy should reside in a plain-text or rich-text document outside of the visual compositions, though it should be represented A=A in the visual comps as well. This is to assure development teams need not retype copy, but MUST copy and paste the exact words and spellings written. This assures the ownership is maintained. Typos remain within the document's author. The visual comps can show text styling.

The visual comp may not be easily updated, so the plain text document should be the final word. The document can also hold a history of proofreading changes and instructions. A good naming convention and file structure will assure smooth processes.


I think ideally, writers should write these messages, but I've hardly ever worked with a writer. It's been my experience that whoever gets to a point where the message is needed ends up writing them. I think after a site or app is "done", it is a good time for designers and writers to go through and give suggestions before the project is truly done.

If there's nobody designated as a writer I'd think the designer is most responsible for this. The designer is responsible for the visual tone which will be related to the written tone of a project.

  • This is, sadly, true and all-to-common. UX ends up writing because the organization hasn't actually invested in content writing talent. Granted, that's the next best thing but, ideally, more orgs would invest in actual writers.
    – DA01
    Commented Mar 31, 2014 at 22:20
  • We actually have writers but they are arguing right now that its not their job to create a document to showcase the copy. They would rather the styleguide contained all possible copy from the application and that's just not feasible.
    – IczerX01
    Commented Apr 1, 2014 at 13:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.