Scriptorium Publishing

content strategy consulting

Plumber’s guide to content workflows

September 8, 2015 by

Last week I was working in my home office when I heard an odd hissing sound. Upon investigation, I found that my hot water heater had decided to empty itself onto the basement floor.

Fortunately I had some failsafes in place; the heater’s pressure release valve was doing its job by routing scalding hot water onto the floor, and my floor is slightly slanted toward a drain in the floor. This got me thinking (because my brain is oddly wired this way) about failsafes in content workflows.

I spent a good deal of time in panic mode, frantically moving boxes out of the way of the growing puddle as the water made its way toward the drain. I soon managed to turn off both the water supply and the gas, but not before losing many gallons of water to the floor, and was left to enjoy a makeshift sauna while the release valve slowly began to close.


image: Pixabay/ClkerFreeVectorImages

Enter the plumber (aka water tank strategist).

After looking my tank over and testing the valve, the prognosis was not good. There was a buildup of mineral deposits within the tank that were gumming up the works (I think that’s an accurate technical description). They could clean or replace the valve, but it would just happen again, and without warning.

Long story short, I have a new water heater.

I couldn’t help but tie this mess to situations where impurities in content workflows cause their own brand of chaos. Where my tank failed due to mineral deposits, many content workflows can fail or produce poor content deliverables due to deposits of a different nature.

Content workflow impurities

Whether structured or unstructured, unchecked workflows and workarounds can cause problems over time, and can be costly to correct. One practice in particular can completely pollute your content: copy/paste. Even when the content is completely accurate, copying and pasting content creates multiple stand-alone instances of the same information. Updating that content everywhere it’s used becomes very tedious and time consuming, with considerable risk of missing some instances.

A lack of proper review and approval can also cause problems over time. As misinformation and grammatical errors are introduced, they can have a negative impact on readers’ trust in the information and in your company. A single-source publishing solution can compound this problem.

Finally, not having a failsafe in place to catch these issues can lead to catastrophe. You may lose customers or reach a critical mass where your content is no longer manageable. At that point your only option is a complete workflow replacement. As with my water heater, this is both inconvenient and expensive, and will require additional frantic busy-work and workarounds in the interim to prevent the situation from getting worse.

The best way to fix a problem is to avoid it in the first place. Assess your workflows to see if you are at risk for unwanted deposits in your content. As for failsafes, make sure you have proper reviews in place and proper reuse strategies. Also, have the means necessary (expedited updates, ability to “unpublish” bad content) to quickly address issues before they build up and cause an even bigger problem.

Tech comm skills: writing ability, technical aptitude, tool proficiency, and business sense

August 17, 2015 by

Technical Writing is only about what software you know! Is that why every where I read any type of document, web page, or article it is FULL of misspellings, incorrect punctuation, and horrible formatting?!!

That’s what started a thread on LinkedIn that encapsulates long-running debates on the skill sets technical writers need. (The thread was removed from LinkedIn sometime after Friday, unfortunately.)

From my point of view, a good technical communicator possesses a balance of writing ability, technical aptitude, and software skills. Problems arise when that mix of skills is off-kilter:

  • Grammatically pristine content that just scratches the surface of a product reflects a lack of technical understanding and reduces tech comm to stenography.
  • Overly technical content that catalogs every feature of a product demonstrates technical depth but no writing ability. Such content is usually badly organized (writing about every menu choice in order is not good organization) and littered with grammatical and spelling mistakes.
  • Proficiency in the tools for creating content means information development is more efficient, but blind devotion to a tool is a big (and unprofessional) mistake.

A lot of commenters in the thread touch on these aspects, but at the time I wrote this post, there was a glaring omission among the discussed skill sets:  an understanding of business.

Business requirements should drive all content-related efforts at a company, so it’s vital that content creators—technical writers included—understand how their content supports company goals (or not, as the case may be). Changes to content (new tools, new publishing formats, and so on) must be carefully vetted to determine whether there is a solid business case to make such changes. For example, you propose implementing an XML-based workflow because you have numbers showing cost savings. “Other companies are doing it” and “a software vendor told me we need it” are not business cases.

Writing ability, technical aptitude, and dexterity with software are important skills for technical writers to have. But understanding how your efforts connect to the company’s business requirements is what gives you the edge in making your tech comm work indispensable.

Design versus automation: a strategic approach to content

August 10, 2015 by

Design and automation are often positioned as mutually exclusive–you have to choose one or the other. But in fact, it’s possible to deliver content in an automated workflow that uses a stellar design. To succeed, you need a designer who can work with styles, templates, and other building blocks instead of ad hoc formatting.

More content across more devices requires scalability–and that means more automation. A strategic approach to content needs to incorporate both design and automation as constraints and find the right balance between the two.


First, a few definitions.

Design–specifically graphic design–is the process of deciding how information is presented to the person who needs it. The design effort may include text, graphics, sound, video, tactile feedback, and more, along with the interaction among the various types of information delivery. In addition to the content itself, design also includes navigational elements, such as page numbers, headers and footers, breadcrumbs, and audio or video “bumpers” (to indicate the start or end of a segment). Sometimes, the designer knows the final delivery device, such a kiosk in a train station or a huge video board in a sports stadium. In other cases, the delivery is controlled by the end user–their phone, desktop browser, or screen reader.

Automation is a workflow in which information is translated from its raw markup to a final packaged presentation without human intervention.


Design and automation are not mutually exclusive.


Instead, think of design and automation as different facets of your content. Each quadrant of the design-automation relationship results in different types of documents. High design and low automation is where you find coffee table books. High automation and low design encompasses invoices, bad WordPress sites, and 30 percent of the world’s data sheets. Low design/low automation is just crap–web sites hand-coded by people with no skills, anything written in Comic Sans, and the other 70 percent of data sheets. (Seriously, where did people get the idea that using InDesign without any sort of styles was appropriate for a collection of technical documents? But I digress…)

The interesting quadrant is the last one: high design and high automation. In this area, you find larger web sites, most fiction books, and, increasingly, marketing content (moving out of lovingly handcrafted as automation increases) and technical content (moving out of “ugly templates” and up the design scale).

Design/automation on X/Y coordinates. Automation is the X axis; design is the Y axis.

Design and automation and different facets of content creation.

The world of structured content inhabits a narrow slice on the extreme right.

Automation on the X axis; design on the Y axis. Structured content is a band in the high-automation area.

Structured content goes with high automation.

Design gets a similar swath of the top.

Automation on the X axis; design on the Y axis. Design-centered content is a band in the high-design area.

Design-centered content at the top of the design region.

When you combine a requirement for high design with a requirement for high automation, you get The Region of Doom.

Same grid at before. The region of doom is the top left corner, where you have extreme design and extreme automation requirements.

You can accommodate 90% design and 100% automation or 90% automation and 100% design, but if you are unwilling to compromise on either axis, expect to spend a lot of money.

A better strategy is to focus on the 90% area. By eliminating 5–10% of the most challenging design requirements, or by allowing for a small amount of post-processing after automated production, you can get an excellent result at a much lower cost that what the Region of Doom requires.

The intersection of design and automation bars in the upper right is the best value.

Small compromises in design and/or automation result in big cost savings.


When we discuss design versus automation, we are really arguing about when to implement a particular design. An automated workflow requires a designer to plan the look and feel of the document and provide templates for the documents. The publishing process is then a matter of applying the predefined design to new content.

The traditional design process ingests content and then people apply design elements to it manually.

In other words, automation requires design first, and this approach disrupts the traditional approach to design. Like any disruptive innovation, this new approach is inferior at first to the “old way” (hand-crafting design). As the technology improves, it takes over more and more use cases.

Disruptive technology first takes over the low end of the market, and then gradually moves up to more demanding users.

Evolution of disruptive technology over time, public domain image found at Wikimedia

Travis Gertz writes an impassioned defense of editorial design in Design Machines: How to survive the digital apocalypse:

Editorial designers know that the secret isn’t content first or content last… it’s content and design at the same time.

[…] When we design with content the way we should, design augments the message of the content.

[…] None of these concepts would exist if designed by a content-first or content-last approach. It’s not enough. This level of conceptual interpretation requires a deep understanding of and connection to the content. A level we best achieve when we work with our editors and content creators as we design. This requirement doesn’t just apply to text. Notice how every single photo and illustration intertwines with the writing. There are no unmodified stock photos and no generic shots that could be casually slipped into other stories. Every element has a purpose and a place. A destiny in the piece it sits inside of.

He provides wonderful examples of visuals entwined with content, mostly from magazine covers. And here is the problem:

  • As Gertz acknowledges earlier in the article, for many small businesses, basic templates and easy web publishing are a step up from what they are otherwise able to do. Their choice is between a hand-coded, ugly web page (or no web presence at all), and a somewhat generic design via SquareSpace or a somewhat customized WordPress site. Magazine-level design is not an option. In other words, automation gives small business the option of moving out of the dreaded Meh quadrant.
  • What is the pinnacle of good design? Is it a design in which graphics and text form a seamless whole that is better than the individual components? Many designers forget that not everyone can handle all the components. A fun audio overlay is lost on a person who is hard of hearing. Without proper alternate text, a complex infographic or chart is not be usable by someone who relies on a screen reader.
  • The vast majority of content does not need or deserve the high-design treatment.
  • An advantage of visual monoculture is that readers know what to expect and where.
  • All of these examples are for relatively low volumes of content. I don’t think these approaches scale.


What do you think? Scriptorium builds systems that automate as much as possible, and then use additional resources as necessary for the final fit and finish. Only some limited subset of content is worth this investment. I know that I have a bias toward efficient content production so that companies can focus on better information across more languages.

For more on this topic, come see my session at Big Design Dallas in mid-September.

Making metadata in DITA work for you

August 6, 2015 by

Metadata is one of the most important factors in making the most of your DITA XML-based content environment. Whether you’re converting legacy content into DITA or creating new structured content, it’s important to know what metadata (or data about data) your files will keep track of and why. Coming up with a plan for using metadata can be tricky, so here are some tips to make the process easier.

Using metadata to track content

Metadata can be a powerful aid in organizing your content. It can help speed up your production workflow by allowing you to find all content by a certain author or all content that needs to be reviewed. It can help with distribution by filtering content according to intended audience or location. It can also make content searches easier for both internal and external users. Because metadata exists at both the topic level and the element level, it offers lots of flexibility in content filtering and search.

Before you begin converting or authoring content, think about what metadata you’ll need to track in your content and why. You may need to distinguish between different types of content (informational, instructional, legal), different audiences (internal, external), or different products. Depending on the type and volume of content you create, your metadata needs may be very specific and complex. Making a list of required metadata and how you plan to use it will make it easier to implement your new structured content workflow.

Standard metadata

Learn as much as you can about the DITA standard and what it offers when it comes to metadata. In DITA, you will have certain metadata attributes and elements available by default:

  • author
  • audience
  • product
  • and many others

To determine how well the DITA standard metadata supports your needs, compare it with your metadata requirements and see if you can find an existing attribute or element that matches each item on your list. You may have some requirements with close but not exact matches, or others that are too specific to your company for a match. In that case, you may want to consider metadata specialization.


Specializing metadata attributes and elements can help you organize and filter your content in ways that are tailored to your company’s unique needs. You may need to capture much more information about your product than the DITA standard metadata allows. You may also need to filter content in a hierarchical or multi-faceted way – for example, distributing content to certain locations, and within those locations, only to employees with certain job titles. DITA allows you to specialize metadata elements to include multiple values, which makes this kind of filtering possible.

Although specialization can be highly useful, it can also present challenges to implementation. If you do specialize, be sure to choose a content management system and other tools that can support your changes to the standard metadata attributes and elements. It’s always better to stick to the standard and only specialize if you absolutely must—that way, you’ll be able to choose from a wider selection of tools that will support your content.

Content management

A component content management system (or CCMS) can use metadata to enhance your content development workflow. A CCMS may be equipped to filter on metadata, which helps authors and reviewers find the content they need and tells the publication engines what output to produce. It may also connect with an authoring tool to populate certain metadata values automatically, such as author or status, when a content creator logs into the system.

When you evaluate CCMS options, you should not only ask whether each CCMS you’re considering supports your metadata needs, but also how it manages metadata. How does the CCMS use the metadata in your content to help with workflow? How flexible is the CCMS if you start with standard metadata now but need to specialize it later? What happens to metadata that is created and managed by the CMS if you ever need to move your content into a different system? Having a solid plan in place for metadata use before you choose a CCMS and other tools will help you ask the right questions and make the best decision.

Structured authoring: breaking the WYSIWYG habit

July 28, 2015 by

There are many challenges involved when moving to structured authoring (XML), but perhaps the most personal challenge is breaking out of the WYSIWYG (what you see is what you get) authoring mode.

The rise of desktop publishing has merged the roles of writer, editor, designer, and publisher into one. With many modern authoring tools, what you see in the authoring environment and what you get as a finished product is nearly identical. It’s easy to settle into a WYSIWYG mindset, as there’s comfort in knowing what the content will look like. However, that trust can be misplaced.

WYSIWYG authoring works best under one condition: producing one type of document with a very specific design. Once you add another format into the scenario, the model begins to fall apart. If you’re supporting two or more delivery formats, you end up designing for one and hoping that it looks good in the others. Juggling several different formats, perhaps with content reuse between them, can quickly become tedious.

A move to XML involves removing the physical formatting of content from the words themselves. Instead of manually formatting text as “Times 18pt Bold” or applying a specific “Heading1″ style to text, you encapsulate the text within a tag (<title>, for example). This tag can then be rendered however you prefer for any output format, at any heading level. This has many advantages in multi-output scenarios, but because the formatting is detached from the content itself, it can lead to frustration among visual authors.

Some XML authoring tools provide both a text view and a visual markup mode as you write. The markup mode does provide some level of visual formatting, but it’s anything but WYSIWYG. Be careful not to mistake the visual authoring mode as an indication of what the final output will look like. It’s best to divorce yourself of the WYSIWYG mindset when transitioning to XML authoring.

Here are some tips that can help you break bad WYSIWYG authoring habits.

Remind yourself of the big picture

Always remember that the content you are writing could be used anywhere. It could be in a printed book or PDF, or on a web page, or on a phone. Because these are very different delivery mediums, you cannot visually format text for all of them at once (at least not well).

Instead, trust not in what you see but in your publishing process. The transformations that produce your finished products from the XML will format the content appropriately, provided the XML has been correctly tagged and structured. In the case of the <title> example mentioned earlier, it can be formatted in a different way in each target output—using different fonts, weights, colors, or other stylistic treatments.

Try working in text mode

Switching from WYSIWYG authoring to text-based authoring (think Notepad) can be a very difficult transition for some people (if not downright scary), but there is value in seeing and understanding what is going on “under the hood” with your content. Seeing that something looks bold doesn’t necessarily mean it’s arbitrarily formatted that way. It could mean that it’s a UI label, or a special term, or some other specific type of content. As an author, it’s very important to know the difference and to use the correct tag.

When you first begin working with XML, take some time to try writing in both interfaces (text mode and visual mode). Switch back and forth, applying tags in the visual editor for a bit, and then hand-typing them in text mode. Do this until you become comfortable with the correlation of what you see in the visual editor and the tags (in text mode) that they represent. This will not only break you of the WYSIWYG authoring mindset; it will prepare you for any structural troubleshooting you may need to perform on content down the road.

Get uncomfortable

Developing content, like exercise, is habit-forming. The more you do it, the easier it gets, but the more you conform to a particular technique. In the case of exercise, it could mean that you begin to overstimulate some muscles and underutilize others, despite enjoying the activity and its benefits. When developing content, the more you approach it using the same tools in the same manner, the easier it is to form habits along the way. These habits may get the job done well, and you may enjoy the way you work, but WYSIWYG habits won’t transition well into structured authoring.

yoga pose

image: Pixabay//SimonaR

If you’re coming from a WYSIWYG background, you may have some habits to break. While the tips mentioned earlier will help, the key is to allow yourself to get uncomfortable and stop authoring the way you used to.

XML authoring is not at all like WYSIWYG authoring, and no authoring UI will change that. As close to WYSIWYG as some visual authoring tools may get, the underlying content is still XML, and it needs to be semantically and structurally correct.

If you find yourself struggling to change, push yourself further. Work only in text mode for a while, or switch between text and visual authoring modes more frequently. Just as it is difficult to train a different set of muscles when exercising, making an authoring transition can be difficult. But with time and dedication, you’ll reap the benefits.

Localization: are you the weakest link?

July 13, 2015 by

There is an old proverb that says, “a chain is only as strong as its weakest link.” While many of the links in the chain could be quite strong, it only takes one weak link to break the chain. There is one process chain in particular where this proverb rings true: localization. However, more often than not, little or nothing is done to identify and strengthen the weakest link in that process.

When it comes to localization, there’s a common misperception that if there is a problem with the translation then the vendor is to blame. In some cases this may be true, but in every localization effort (no matter how large or small) there is a shared responsibility between content authors and translators to ensure that the translation is accurate and is completed both on time and within budget.

localization chain

If any link in the localization chain breaks, the chain itself fails. Half of these links are owned by content development.

If we look at every link in the localization chain, we can start to see where the possible failure points may be.

What content creators control

Style guide: A corporate style guide defines how all content should be developed and presented, from writing style to publishing standards. If the rules in your style guide are ambiguous (or worse, if you don’t have one at all), your entire content development effort is left to chance. A good style guide should inform both the source language content development effort as well as the localization effort. In short, it’s the single source of truth for developing all of your content, in all languages, for all audiences.

Terminology: Just as a style guide informs how to develop content, a terminology reference (repository, term bank, master glossary, etc.) informs which words are correct to use, in which contexts they can be used, what they mean, and (perhaps most important) which words never to use in their place. A good terminology reference can prevent unintentional misinformation, and can and should be localized on its own so all terms are properly defined for each target language. Leaving terminology to chance can lead to perfectly cromulent results.

Quality of writing: Writing quality plays a very large role in translation quality. If the wording is unclear, or if the same concepts are written in different ways, then translators may misinterpret how to translate the content. Consistency in writing is critical; a formal editorial review can enforce consistency. Even with a style guide in place, it’s easy for writers to become out of sync without an editorial review.

Consistent formatting: Regardless of what tools you use to author your content, consistent formatting can significantly reduce translation turnaround time and cost. If your tools use templates, adhere to them 100% of the time, and provide the templates to your localization vendors (they should be reviewed for localization appropriateness and modified as needed for target languages). Whoever formats the translated content can then apply the localized template and avoid hand-formatting, provided authors haven’t used formatting overrides.

What localization vendors control

Translation workflow: The translation vendor should have a system in place to manage the overall translation effort. These systems track which translators are being used, which content they are responsible for, and all of the checks and balances between starting and finishing the translation work. Lack of such a system, or a breakdown in this communication chain, can cause deadlines to slip and costs to rise.

Translator qualifications: Translating content requires more than just a strong command of the source and target languages. A good translator must also be familiar with the subject matter, and be very familiar with the regional variations of the target language. The translation vendor should select the appropriate translators for the job and consistently evaluate their work.

Translation memory: It goes without saying that a good translation vendor uses translation memory (TM) in their workflow. Leveraging the TM can ensure consistency in translation and reduce overall translation costs and turnaround times, provided the source content is also consistent. If inconsistencies are found, the translation vendor should work with the content creators to correct it so the inconsistency isn’t added to the TM. Further, the TM itself should be audited on a regular basis to clean out any inconsistencies that may have crept in over time.

In-country review: An in-country (or local) review of translations is critical for tailoring translated content to the target audience. Language varies by location (would you like a pop/tonic/soda/coke to wash down that sandwich/hoagie/grinder/sub?), and the local review ensures that the translation is appropriate for the target audience. Failure to conduct these reviews can result in misunderstandings between the audience and the content, causing a scramble to correct the issues and a negative perception of your company in that location.

Any one of these links could be a point of failure in your localization chain. By identifying and strengthening that link, you will not only improve the quality of your localized content, but will likely save time and money in the process. Evaluate your localization chain often; strengthening one link may help identify another than also needs attention.

Content strategy amateur hour

July 7, 2015 by

“My team is looking into how we can use <incumbent tool> to handle our new content requirements.”

That’s what I heard from a manager during a recent phone call about a company’s expanding content needs. The tools-focused response made me cringe.

This is not the first time I’ve encountered content developers using a current tool’s capabilities as the benchmark for content requirements. An incumbent-tools-first approach is an easy way out that maintains the status quo.

Periodically assessing how efficiently you’re using tools is sensible, but don’t fool yourself into thinking that checkup is a complete process analysis. A true content strategy assessment looks at how content supports business requirements and then investigates which tools best support those needs. The list of prospective tools should include the incumbent if—and only if—that tool meets the criteria for supporting business goals.

When developing a content strategy, content professionals are anything but professional if they do not step outside the comfort zone of the tools they use every day.

Please don’t be one of those amateurs.

Waterfall content development? You’re doing it wrong.

June 29, 2015 by

Product development, content development, and localization processes are too often viewed as a waterfall process.

This is not at all accurate.

Waterfall: product to content to localization is highly unlikely.

Waterfall. As if.

Product development decisions do feed into content and content into localization, but, in the other direction, localization decisions also drive product development. For example:

  • Every time you add a new locale, you need to make sure that your product can support the local language, regulations, currency, and so on. Regulatory requirements might drive product decisions—the European Union, for example, has strict requirements around personal data protection.
  • In a country with multiple official languages (like Switzerland or Canada), you may need to provide a way to switch a product interface from one language to another.
  • If you want to deliver content as part of the product, you need to make sure that your product has enough storage space available for product content.
  • If you want to deliver web-based content with periodic updates, how do you handle the connection from the product to the content?
  • What if you want to have troubleshooting instructions that use product information directly? How do you integrate the instructions with the product status? How do you do that in 57 different languages?

This leads me to the unified theory for development:

Product, content, and localization maturity are interdependent. A mature process in one area requires alignment with mature processes in other areas.

Instead of waterfall, think of content, localization, and product as sides of a pyramid.


Three-face pyramid with content, product, and localization on the faces.

Content, product, and localization all contribute to the overall development process.

Your development process is a slice across the pyramid that intersects all of the faces.

Three-face pyramid with horizontal slice.

If your processes are equally mature, development works well.

What you want is a horizontal slice—the development process in sync across all of the faces. If the processes are out of alignment and do not have similar levels of maturity, you end up with an unstable platform that is impossible to stand on. Problems on the lower (less mature) side will cause instability everywhere.

Three-face pyramid with angled slice.

Different levels of process maturity make for an unstable development platform.

Here’s are some examples of misaligned processes:

  • Localization needs to deliver languages that the product didn’t account for. Suddenly, you have a need for Thai characters, and no way to embed them in the software.
  • Product is cloud-based software that is updated weekly. Content development process can only provide PDF that is updated every six months.
  • Product ships with all languages enabled, but localization process requires another eight months to provide content in all languages.
  • Content development process is frenetic and unpredictable. Localization costs skyrocket because of lack of style guides, consistent terminology, and formatting templates.

When we develop content and localization strategies, we must assess the maturity of the product development process. The right content strategy may require the organization to make changes in product development and vice versa. Product, content, and localization strategies all need to be aligned at similar levels of maturity.

Put another way: Your content strategy can’t get too far ahead of your product strategy.

Webcast: Risky business: the challenge of content silos

June 25, 2015 by

In this webcast recording, Sarah O’Keefe discusses how content silos make it difficult to deliver a consistent, excellent customer experience. After all the hard work that goes into landing a customer, too many organizations destroy the customer’s initial goodwill with mediocre installation instructions and terrible customer support.

Do you have a unified customer experience? Do you know what your various content creators are producing? Join us for this thought-provoking webcast.

Localization, scalability, and consistency

June 23, 2015 by

When companies need to change the way they’re producing content, localization and scalability can be two of the biggest motivating factors. If your company’s content is not consistent, you may face significant challenges with translating it into new languages or distributing it via new platforms. A content strategy that embraces consistency and emphasizes planning for the future will help your company navigate these changes more smoothly.

(flickr: Beverley Goodwin)

(flickr: Beverley Goodwin)


Localization is usually difficult, time-consuming, and expensive—especially if your company is doing so for the first time. Even if you’re already localizing your content, a major increase in the number of required languages or a demand for new types of languages (such as right-to-left) may suddenly feel like more than your current process can handle. Here are some ways you can make localization easier and offset costs:

  • Prepare your content. Using consistent terminology, avoiding jargon, and practicing cultural awareness when you’re creating your source content can make it more ready for translation.
  • Plan ahead. As your company grows, localization will become more and more of a requirement. If you have target markets in other countries in mind, it never hurts to start researching their localization needs ahead of time.


Companies can grow and scale up their operations in a number of ways. Maybe your company is growing larger, hiring more employees, and developing more products. Maybe you’re getting requests for content distribution through a wider variety of channels (print, PDF, HTML, online help), optimized for desktop and mobile. You might also be expanding into the global market, which means scalability will go hand-in-hand with localization.

Thinking about your company’s long-term goals for growth and planning for the future can help you avoid some of these common roadblocks to scalability:

  • Your content creation process is too slow or too small-scale to keep up with the demands of company growth.
  • Your content creation process can’t handle new localization requirements.
  • Your content is developed in a way that results in limited output types (such as a desktop publishing system that can’t produce output in electronic formats).


When it comes to localization and scalability, inconsistent content can be part of the problem, so making your content more consistent can be part of the solution. Inconsistency makes translation and legacy conversion difficult, introduces accessibility issues, and ultimately hurts your brand. Here are some ways you can make your content more consistent:

  • Have a style guide (and use it). Train your content creators on consistent style and make checking for consistency a major focus of the review process.
  • Replace manual processes with automated ones. If a style guide alone is unreliable, use templates to help enforce it. The more you automate your content development, the less room you have for human error.
  • Consider controlled language software. If inconsistency is a huge pain point for your company, it may be best to invest in technology that can strictly enforce language and style.

Getting your content consistent can be difficult, especially if you’re currently working without a style guide or templates, but the rewards are worthwhile. Consistency can save your company money by allowing you to produce, translate, and publish your content more quickly and efficiently. With consistent content, localization and scalability will seem less like insurmountable obstacles and more like exciting markers of company growth.

To see how much your company could save by creating more consistent content, try our business case calculator.