- Go beyond drop vs. move as is
- Use rules to assign dispositions during planning, not during content implementation
What is a disposition?
A disposition is a consistent way of treating content during digital change. The simplest dispositions are keep as is and delete (example dispositions are in bold throughout this article). Note: if you're only considering these two then you're probably doing it wrong!
What kinds of projects benefit from dispositions?
Dispositions are important for any project where a large amount of content is potentially being changed. Some primary example projects are redesigns and migrations, but it could be other cleanup efforts like reducing digital presence size or moving away from PDFs.
When in the process are dispositions used?
Broadly speaking, we want to follow a process like this:
Generate a list of your content.
Define dispositions and assign dispositions to buckets of content.
Hand off for execution.
Note: By the time the hand off for execution occurs, you should have already: a) defined the dispositions for your project and b) generated a list of content that is getting each treatment. When it is time for execution, all the key decisions about treatment should already be defined.
Estimating effort levels is a good way of confirming that your dispositions will work, and perhaps indicate where you should optimize/tweak dispositions.
Why are dispositions useful?
Fundamentally dispositions allow you to plan more effectively, to:
Think more creatively of how to meet quality goals.
Estimate effort, which allows us to more effectively make trade-offs and optimize effort and quality.
Make decisions broadly rather than in a disjointed manner.
Provide clear instructions for those handling content.
Get an overall picture of your content improvement project
How should dispositions be defined and assigned to buckets of content?
Ideally we define the following:
Buckets of content. These are groups of content that are similar and will be treated the same during content improvement. These often correspond to content types (technical articles, product descriptions, etc) or site sections, but they are different since sometimes a bucket is a combination of content type and something else. For example one bucket might be old blog posts and another bucket might be new blog posts, since you may treat old blog posts differently (for instance perhaps deleting them) from new blog posts (for instance perhaps moving as is).
Dispositions. For each bucket of content, how will each piece of content be handled?
Assignments. For each bucket of content, who or what team will handle the work? For instance, if new blog posts are moving as is, then perhaps this will be assigned to interns (or perhaps it's assigned to the technical team — it depends on the situation). Similarly, if old blog posts are getting deleted, then perhaps it's purely a technical issue (to redirect to the blog landing page for example).
What are some example dispositions?
Some example dispositions, in order of effort level per content item, include:
Drop. Do not include the content in the target state. This can mean actively deleting on the current system first or simply not moving over the content. Note: do not forget redirects when deleting content.
Integrate. The new system renders the content, but it lives on another system.
Archive. Either expose the content to users with some sort of clear archived state, or remove it from user view but have some method of getting to the information should it prove useful later.
Keep as-is. Largely keep the content as it is now.
Merge. Merge different pieces of content into one.
Change format. Change the format of the content, for instance from PDF to HTML.
Rewrite. Keep many elements of the content the same, but largely rewrite it (from an editing perspective rather than a technical perspective).
Brand new. Develop brand new content for topics that are not already covered by the site.
There's some nuance within each of these. For instance, there are lots of different flavors of Keep as is, such as:
Leave as-is. Leave the content where it is and link to it.
Literal copy. Literally copy the existing content (like raw HTML) from the old system to the new one.
Technical cleanup. Keep the content itself the same but transform it to fit in the new system.