11

How do you manage copy text in a huge application?

almost 5 years ago from , User Experience Designer

Hello!

Have you ever had problems with nobody knowing what text should be on a particular button, or in a paragraph from the app?

How do you manage the Texts (Copy text) in a huge application projects? What is the source of trust for everybody from QA, Devs, Business Analysts, Managers etc.?

What problems do I have: We have a huge application and even a small text change is a pain because the mockups are the source of trust in terms of Texts (copy text), and developers are blocked until I finish updating the mockups. Sometimes I miss some screens to update, I have Web (desktop, tablet, desktop) and iOS and Android to update for just one text change.

What is your process? How do you manage this problem? What tools do you use?

Thanks!

16 comments

  • hugo woodhead, almost 5 years ago

    We had exactly this issue. We started with a central text file in our source code to manage our copy and button text. This didn't work so we just started in-lining everything. The first option wasn't creating any efficiency and was difficult to maintain effectively. In the end we have adopted a headless content management system (CMS) which is a really good option.

    It allows you to store copy in a structured way. You're developers can access it as JSON while your designers and content team have a UI to update and publish the words without having to involve the tech team. Saves everyone time

    Here's a blog we wrote about the decision we made

    https://www.pilcro.com/blog/headless-cms

    5 points
  • Kyle ConradKyle Conrad, almost 5 years ago

    Might look into something like GatherContent - https://gathercontent.com/ - not specifically for "apps" but could easily be repurposed to do that.

    4 points
  • Aaron Wears Many HatsAaron Wears Many Hats, almost 5 years ago

    Our applications use a backend system that among lots of business logic, manages a spreadsheet of all the labels and text elements in our apps based on the context of that label. From there, the spreadsheet of text elements can be sent to copywriters and translators to produce the i18n conversions we need to serve localized content in our apps.

    The backend serves json/xliff files which our front end apps sync with when text changes are made (checks timestamps). This means that if someone higher up wants a certain CTA updated, we don't need to bug the developers unless the text area itself needs to be modified to suit a certain change.

    With all that, however, I should point out that when you start working with multiple verticals, dozens of sites and a massive CRM, it does become a bit hard to manage, no matter what you do.

    4 points
  • Hugo Magalhães, almost 5 years ago

    There's also this new app called Kopie - https://kopie.io. It allows designers to export their mockups to an online platform where your team's copywriters can review, makes changes to the copy, and then sync them back to your Sketch document.

    The app is still in beta, but from what I've seen so far, it looks promising!

    2 points
  • Matt Sawmiller, almost 5 years ago

    This is what has worked the best for us: https://github.com/DWilliames/Google-sheets-content-sync-sketch-plugin

    You can put different locales in different google sheet pages and is the single source of truth. It can then automatically update all of your sketch files via the plugin instead of a manual process. The localization team then can stay out of your sketch files and do all of their work in google sheets, it works great.

    2 points
  • Michael CookMichael Cook, almost 5 years ago

    Haven't tried this but it was posted here awhile back https://www.canvasflip.com/visual-inspector/scribble/

    2 points
    • Rhys MerrittRhys Merritt, almost 5 years ago

      The point this misses for me (my team) is that it only serves as an initial gate. Once the designer collabs to get the copy correct, the design is updated, and it still serves as the source of truth for the development team. I think that's where the big problem lies, the design should never be the source of truth for copy.

      4 points
    • Vipul. MishraVipul. Mishra, almost 5 years ago

      Thanks Michael. I'm maker of Scribble and really appreciate spreading a word here.

      Would love to to hear once you have tried it more and have any feedback for us.. :)

      1 point
  • Andrei Urse, almost 5 years ago

    Thank you very much to everybody! I will analyse your answers and come up with a solution for my context. Of course, new ideas are welcome :)

    1 point
  • Joe AlfonsoJoe Alfonso, almost 5 years ago

    Usually there's some sort of content team or person who's in charge of copywriting. And if there's not a person there should at least be a content strategy set for just this case. Tone of voice, point of view, type of content, content rules if automated or customized and so much more.

    The decision on approval is going to be unique to your organization.

    1 point
  • Mitch Malone, almost 5 years ago

    Writing should be done by the designer IMO. You collab on what it should be with stakeholders, your team, etc. I treat copy like any other UI element.

    You can develop voice and tone documentation to help you write coherent and consistent copy. This is particularly helpful on large systems with many teams.

    Mockups should not be the source of truth (I assume that's what you mean when you say 'source of trust').

    developers are blocked until I finish updating the mockups

    This sounds like an awful situation that leads to a lot of bad outcomes. Changes to copy (or any other UI element) should not be a dependency on engineering. I would work with your team, execs, decisionmakers, etc to figure out why that is the process. It's adding unnecessary bottlenecks to the process and unnecessary stress for you.

    0 points
    • Pedro MC FernandesPedro MC Fernandes, almost 5 years ago

      I agree with this one. The designer is in the perfect position for that job. However, not everyone's good with words, and it can go wrong.

      At least, the UI designer should launch a solid base, provide button and nav copy, titles, body copy where it makes sense, between other bits, and telling the whole UX story. My technique is to embody the user's experience and let it go, flush the text and narrate. Starting it rough and incomplete in the wireframe. Making something more concrete in view design, and making a solid copy in the HTML phase.

      After implementation, the frontend offers the materials for a copywriter to complete where needed, live editing, and then for professional reviewers to sift in and perfect — translation and localisation professionals, ideally.

      1 point