Who out there hates doing data entry?

We all know that it's a pain, we all hate to do it, and a lot of projects end up in a Texas standoff of sorts trying to figure out who's responsible for it. We do our best to manage expectations on a number of topics on our twitter feed, but it's time to do an exploration of the role breakdowns.

Also - @acorndevops - wow great follow really informative cutting edge industry analysis with a twang of fun and silliness...👀

There are two flavours of data entry

Generally speaking the need emerges when we are building out Content Management System (CMS) applications. Content management systems utilize patterns of database storage and retrieval that make it efficient to build customer interface designs with adjustable/editable contents.

Flavour 1: From The Ground Up

In this version, there are two divergent streams of thinking that tend to interfere with each other: creation of written contents, and populating the applications page templates for reengagement. This ends up falling into the nebulous void of content strategy. To illustrate these distinctions, we can write a couple of simple user stories.

As a vistor to [your web presence] I am looking to get a summary of your organization, understand the personnel behind the organization, and understand how to contact the business.

As you can see, deliberation and planning needs to go into the page writing to solve organizational objectives. The priority of the page contents factoring in the:

1. the summary
2. the personnel
3. the form

end up being a content drafting exercise. Data entry, then, would have several steps:

1. establish the layout of the page
2. draft written contents for each section of the page
3. revise both the template and verbiage to accomplished the desired look and feel.

Depending on the size of the organization, data entry considerations would need to factor the number of personnel bios required for a practical web experience. For example, many investor driven sites need exposition on the board of directors, their credentials, and a brief personalized bio.

With that, planning for publishing in content strategy is one way to tease out whom, within an organization, will be responsible for utilizing the content management system. This invites our next user story.

As an [organization] event moderator, I want to publish company events to bring people to physical locations, or host webinars, to showcase the value propositions of our organization

This is where confusion emerges.

What is the content strategists role, and what is the data entry administrator's job?

Content Strategists need to look at the user story and tease our critical metadata. In the story above that could be:

1. showcasing event multimedia (optional)
2. rendering the calendar date and time on every post
3. showing a written address for indexing in search engines
4. visualizing the address on a map, with a pin

Additionally, content strategists help to tease out associations between content to promote CMS interactivity, and inform the information design.

For example (and there may be time-stamp logic governing this for future applicability), our work on the Vancouver Art Gallery connected exhibitions with supporting events. You can see the JIN-ME YOON: ABOUT TIME is connected to these events:

1. WHAT IT MEANS FOR US TO BE TOGETHER: SOLIDARITY, DIFFICULT HISTORIES, AND PLANETARY FUTURES IN THE WORK OF JIN-ME YOON
2. THE ART OF LIVING AMID THE RUBBLE OF SEDIMENTED HISTORIES: HERE AND THERE, THEN AND WHEN WITH SASHA SU-LING WELLAND

Understanding these role differentiations is how to breed effective partnerships here. The content strategist can help to tease our major data considerations on a per-page basis, while data entry personnel will be responsible for entering in the contents on an on-going-basis.

Ideally, the right foundations for these joint efforts build off of each other. A content strategist can provide a stable foundation for data-entry personnel to be successful in their role. Feedback from the data-entry personnel, website visitors, and organizational subject matter experts can then inform future content strategy initiatives.

It's magic when it works 🪄 



Flavour 2: Content Management System Migrations

The key tenant for success here is planning. A lot can happen between the time a CMS is setup and configured, contents get populated, and the application itself evolves.

The migration process factors in a number of considerations:

1. What alterations to the page and template layouts are required?
2. What contents need to stay?
3. What contents need to go?
4. Will the be an addition of new content entry portals?
5. Will antiquated ones be removed?
6. Will an archival subdomain be necessary?
7. How will redirection services work?

Like everything in assembly, be it mental or physical, the rule of thumb is always

Measure twice, cut once.

Unfortunately, we do need to tend to the dry parts. Our starting point for any content migration is done in a content audit.

Sadly, it is exactly what you would expect it to be.

The content audit is an inventory of every single page on your current content management system.

Page by page, by category if you can, we need to understand the guts of what's in the database. There are a number of ways to approach this, from automation, to vendor assembly of the audit, to an organizations in house team producing the audit itself. It becomes a tired cliché in software but - all of this is context dependant.

Once the audit is done...

Remarkable insights can be gained from review. Invovling clients in the review, especially ones who were previously responsible for content administration and data entry, allows for memory prompts about

1. what needs to stay?
2. what can be discarded?
3. what content based structural changes have been lurking in the back of the mind from experience?
4. what improvements can be invoked with design?



And Voila! A completed content audit.

With a completed content audit we can springboard into all of the good stuff. What wireframes and mockups are in store? Which pages are unique, and what pages are templates? In what order do we want to design, and develop the templates within the content management system? Having structure for this approach is the mitigation system to avoid going all

✌️willy nilly✌️

on the decision log. With a list of contents to keep, and contents to omit we can substantially reduce the overall costs associated with data entry. Furthermore, by having a visual inventory of what is to be migrated between old and new systems, we set ourselves up for the assignment of roles. Do we:

1. Train in house subject matter experts on the new systems the vendor has built ?
2. Train the vendor and create a script for a subcontracting agency to fulfill the data entry?
3. Some combination of both?

This boils into what I call the Land of Impossible Distinctions. A land where there is much work to be done, the work itself is arduous, and it can take a lot of time and money. As opposed to sleek and sultry visual deliverables, this part of software initiatives is often overlooked...

So where do we go from here?

Conclusion

Do not take this step of a build initiative for granted. Leaving data entry on the back burner until the 11th hour is a sure fire way to set up a future five alarm for yourself and your client with the only outcomes being jadedness and hurt feelings.

Be sure to understand the differences between what is content ideation, content structuring within the confines of a template, and general data entry for contents that already exist somewhere else. Isolating each one of these steps and handling them sequentially can bring one to a more enjoyable destination:

The Land of Satisfactory Task Completion.

In order to navigate oneself to this promised land never hesitate to seek professional council on these matters, namely in the form of a content strategist who is trained in dismantling the blocks of production and getting the results that one wants. Always remember:

🏴‍☠️ Nobody wants to do data entry 🏴‍☠️ 

Pre-training on the "how" is essential in the long term and can generate all kinds of meaningful feedback if channeled correctly. There is always going to be friction with the first iterations of the tasks themselves. For public facing web experiences like content management systems that having strong user interface (UI) guidelines and sound fundamentals in content strategy, getting the plan right and the team organized is exactly how Acorn Interactive Inc. makes web experiences sparkle ✨