Or, just…

Tags

Tags are pieces of keyword metadata used to organize resources within an ordered system. They help users find things quickly.

At Cvent, we created a tagging feature that event planners could use to help attendees find event content related to their interests.

These tags were stored in a Tag Library

From the Tag Library, event planners created tags that they could apply to content across all their events in their account.

This helped planners create tagging standards.

But the Tag Library created some issues

For instance, what if an event planner wanted to delete a tag that was already in use?

Should be easy, right?

It should be easy to delete a tag. Simply add an option to the overflow menu in the Tag Library that lets a planner delete a tag. No big deal.

But what if that tag is already being used in an event? What happens when you delete that tag?

Delete means Delete

We decided that deleting a tag from the tag library would also delete the tag from all events. This kept tag behavior consistent. Deletion would remove an object from our system wherever that object appeared. But, I had to let planners know that deleting a tag from the Tag Library would entail deleting it from their events.

I used a confirmation modal to let planners know.

FIRST DRAFT

FINAL DRAFT

Moving from first draft to final is mostly text removal.

First, the “Are you sure…” question is unneeded. The interaction with the delete CTA in the overflow menu has already established a user’s intention.

Second, the subjunctive framing of the deletion — “If you do…” — is also unneeded. Subjunctive framing is rarely helpful in UX writing, as it forces users to consider potential futures, rather than concrete outcomes.

Third, the “…where it is currently applied” is also unneeded. This construction is redundant. If I have mentioned events already, a user will infer that the “5 events” are where the tag is applied.

So that’s the body text.

I would have liked to change the header text, as well. “Confirmation” is vague, cold, and taxonomic. A better header would have been “Delete tag?” Unfortunately, due to a limitation within Cvent’s codebase, I was unable to make this change.

To maintain some connection between the header and the modal’s primary action, I left the CTA as “Confirm.” “Delete tag” would have been more specific, and more helpful. But I wanted to maintain some connection between header and CTA.

Tag deactivation was a feature our product managers requested, so that planners could remove tags from events, but still track the performance of click-through, use, etc., on those tags in Cvent’s internal data tools.

Unlike deletion, deactivation would remove tags from events, but retain tags in the Tag Library. Planners would be able to reactive a tag at any time.

I had to create a new menu item — “Deactivate” — and a new confirmation modal for this action.

FIRST DRAFT

Then came a curveball. As I was iterating on my first draft, the product managers told me that planners would, in fact, not be able to reactivate tags.

Well dang, I thought. Time to change it up.

FINAL DRAFT

Again, I tried to remove as much text as possible. First I took out the awkward “inactive disables” construction, which ground a present participle against a simple present tense verb, and condensed it all into the gerund “Deactivating.”

“Deactivating” did the work for me of 3 other verbs. It allowed me to move immediately to the consequences of the action — “removal” — and a description of what that removal would entail.

TAKEAWAY

Complex products create tangles of text. The more complex the feature, the more important clear description of actions and risks become. The interaction between account-level features, and event-level applications in Cvent’s platform necessitates writing that is able to communicate the effect of global actions on individual events.