UX in MCE

When you think about User Experience in Marketing Cloud Engagement, who exactly is the “user”? For me, it is rarely just the subscriber. It is also your teammate who picks up the project after you, the developer who debugs it late in the evening, and - very often - your own future self, returning to a solution months later. Good UX in MCE means keeping all of them in mind.

This article gathers the practices I have been sharing on LinkedIn, now collected in one place. Think of it as a toolbox of small habits that, together, make working in MCE clearer, calmer, and far less error-prone.

You might ask - why focus on Marketing Cloud Engagement now, when all eyes are on Marketing Cloud Next? Because MCE is far from gone. It still powers the daily work of a huge number of marketers and developers, and it is not disappearing overnight. On top of that, Salesforce is actively promoting “Plus” licences, which give existing MCE customers access to Marketing Cloud Next. In practice, this means many of us will soon be working across both platforms at once.

And that is exactly why UX in MCE matters even more than it used to. When you are switching between two environments, every bit of clarity you build into your MCE solutions - a consistent name, a helpful description, a well-handled error - saves you from friction and avoidable mistakes.

So let’s dig in!

Consistent Naming Convention

Naming Convention improves cooperation within the team and brings clarity to delivered solutions. It makes routine tasks more straightforward, reduces the time needed for onboarding new team members, and, most importantly, minimises the risk of user errors.

The final strategy may depend on your MCE instance organisation, sharing permissions, or use cases, but I have prepared a list of 5 Good Practices for Naming Convention in Marketing Cloud Engagement.

Focus on the goal

An asset name should represent its purpose, so make sure it is easy to understand WHAT is the goal (e.g. What does this Data Extension store? What does this Query Activity do?).

Introduce a pattern

Divide your asset naming schema into elements and order them from general to specific. This is especially helpful while delivering complex, multistep Automations.

Use an underscore as a delimiter between elements. Avoid spaces and other special characters as they might be visually confusing. Also, capitalise the first letter of each word within an element to delimit them.

Find a balance

While working on asset names, it can be tempting to go into too much detail. Bear in mind that an overly long name will negatively impact readability. If possible, use abbreviations but always make sure a name is still clear.

Keep it consistent

Whenever possible, use the same names for different kinds of assets associated with the same process.

Let’s have a look at a simple example - Data Extension, Query Activity which populates it, and single-step Automation where this Query resides can have the same name. This also applies to a Journey using this Data Extension as an entry source.

Of course, it’s not always that simple, but if you only have a chance to provide the same name for related Query Activity and Data Extension, just go for it!

It’s an easy way to reduce the risk of user errors. You don’t want to accidentally overwrite a wrong Data Extension, right? Right…

Make it operable

Introduce a prefix to differentiate between production and test assets. While working on MCE projects with no test environment, this practice is a must-have. However, the usage of prefixes has many more pros!

Let’s discuss one of them - having a proper prefix in place allows you to retrieve key production automations, make sure they are up and running, and send a notification to a user if at least one of them requires attention. This way you can have better control over key processes and ensure data integrity.

Another handy example is automating routine cleanups by introducing a process that removes assets following a specific naming pattern.

You can think about other prefixes that would support your use case.

Take advantage of descriptions

Marketing Cloud Engagement doesn’t allow for much customisation of the interface, but you can still achieve it with some simple practices. Introducing a consistent Naming Convention is a great first step.

Let’s now take it to the next level with descriptions!

Provide descriptions

Let’s be honest! How often do you take advantage of description fields while delivering solutions in Marketing Cloud Engagement?

Since that field is optional, it’s often skipped. Filling it in can bring clarity to your solutions. Adding a description to data extensions or activities in Automation Studio is helpful, but for me, the most valuable use is providing descriptions of an automation’s steps in a workflow canvas.

It’s an easy way to briefly explain the general logic of an automation.

Another handy trick is replacing the default names of paths in Journey Builder while defining Decision Splits. Instead of “Path 1” or “Remainder”, use a short description of conditions records must satisfy to enter that path.

Once you do that, it’s enough to hover over a path name to understand a Journey flow without accessing Decision Split’s settings. Cool, right?

Make sure they really help

Bear in mind that a description will add value only if you focus on its quality.

First of all, keep in mind the end user and adjust the language accordingly. Make sure your descriptions are inclusive - they are supposed to be helpful not only for you and your peer developers but also for users with less technical skills.

Secondly, keep them short and sweet. Although character limits will help you hold back your creativity, remember to keep them simple and explicit.

Be consistent

At first, it might feel like an unnecessary waste of time, but don’t give up! Once writing descriptions becomes your habit, it will come naturally and both you and other users will benefit from that.

You can always employ AI to generate descriptions that follow the best practices based on a broader definition of a particular process or asset.

Provide efficient error handling

I like this topic as it explains my understanding of UX in Marketing Cloud Engagement very well. I believe that at some point in time, everyone is a user. One solution, e.g. a subscription form, can have at least 2 different users - the one who submits the form and requires clear error messages on what went wrong and how to continue, but also a developer who maintains the process and is responsible for debugging.

That’s why it is vital to capture different perspectives while designing a solution!

In this section, I focus on MCE developers. If you are one, check the good practices below.

Introduce error codes

Create a library of error codes along with clear explanations. It allows you to display a human-readable, user-friendly message while leaving developers with a handy hint on the root cause of an error to streamline debugging.

For example, in case of an issue with processing on the Cloud Page, you can redirect a user to an error page but also log or display an error code. Once you or your peer developers see this, they can easily verify that the issue was caused by e.g. missing key variables for processing.

Think about what can go wrong

Eventually, something WILL go wrong. Be ready for this and try to predict possible scenarios. You can do it while writing backend logic for your Cloud Pages by introducing validations before continuing with the next steps of the process. Simple IF statements can catch an issue before it happens, handle it as expected, and log an error (with a proper error code, of course).

But it is not only about Cloud Pages! You can avoid issues by creating fallback content while personalising emails. Always provide a default value for attributes like FirstName in case the field is empty or default content blocks for subscribers that do not satisfy any criteria you defined to decide which personalised content block they should see.

Another great example is the RaiseError() AMPscript function. By using it in your email, you can skip the send for a subscriber if an error occurred for them. Make sure you do not overuse it though.

Include try/catch statement

Even if you have potential issues handled in the code, there is still one more thing you can do. Wrap your script with a try/catch statement. It allows you to handle all exceptions, in case an unexpected error happens. Bonus points for helping you deal with the worst nightmare - a 500 error.

Log error details

I have already mentioned error logging a few times, but I want to emphasise that it is vital for debugging as it gives developers better control over processes they build and maintain.

Create a logging data extension to store errors along with their codes and messages. Add SubscriberKey and other values that can be helpful during the investigation. However, avoid including PII in logs if possible.

Provide comments in the code

As already mentioned in the previous section, when I think about a “user” of the MCE solution, I don’t see only a subscriber. A user can also be your peer developer, who joins the project, or even your future self, who revisits your solution after some time.

It might feel like writing and keeping comments up to date is a waste of time. It might also be tempting to add some brief notes only on the most complex parts of a solution. And yes, I know what you are about to say: “Comments do not work in Query Studio!”. Actually, it’s even worse - when you add some special characters (e.g. an apostrophe) to your comment in a Query Activity created in Automation Studio, it will throw an error while trying to save it.

But regardless of how inconvenient or time-consuming it feels, providing descriptive comments alongside the code is vital for understanding the goal and logic of the solution, and it doesn’t matter if you write in SSJS, AMPscript, or SQL.

Below I’m sharing questions that will help you write a valuable comment.

WHAT is the goal?

While writing a solution, it is clear why you chose a particular Data Extension and joined it with another one. It is obvious what criteria are satisfied by a specific set of conditions in the IF statement of your AMPscript or WHERE section of your query. But would it be as readable to your colleagues? Make sure to provide a clear explanation of how particular bits of your code fit into the requirements and what their aim is.

WHY do I do it this way?

Does your approach address some limitations or dependencies that you’re aware of? Could an alternative approach cause issues? Is there a reason why a particular part of the logic should not be changed? Just write it down and thank yourself later.

HOW is it going to be used?

I find this question especially helpful while explaining conditions for assigning particular field values in a CASE statement within a Query Activity. Providing information on why you distinguish a particular set of records and how it benefits the later processing allows you to stay on top of the entire logic. It’s especially valuable while working with more complex, multi-step automations.

Of course, comments don’t have to answer all of them at once. Let’s think of them as focus areas that you cover depending on the scenario. This can also be a good exercise to challenge your solution design!

Wrapping up, quality comments will surely earn you the eternal love of your peer developers. They will also save you hours that you’d spend trying to recall why you did what you did. Additionally, by explaining the reason behind a particular approach, they can prevent developers from introducing changes that should not be made.

Let’s conclude

None of the practices above is a big, dramatic change. Consistent naming, thoughtful descriptions, solid error handling, and quality comments are small habits - but they compound. Together, they turn a Marketing Cloud Engagement instance that only you can navigate into one your whole team, and your future self, can pick up with confidence.

You don’t have to introduce all of this at once. Pick one practice, make it a habit, and build from there. Your peers - and future you - will thank you for it.