Email Signature Program Maintainability – The “Swiss Army Knife” Approach
4 March 2024 / Rex Weston / Article Originally Published in Digital Agency Network.
A multitude of factors must be considered when designing an email signature program – things such as:
- Should users be allowed to edit their signature?
- Should a more streamlined signature be utilized when replying to messages?
- How will the signature appear when displayed in dark-mode?
- Should there be an option to include user’s headshots?
- Which social media platforms should be featured?
- How will the “plain-text” version of the signature be prepared and installed?
- Which data fields should be mandatory and which ones should be optional?
- What’s required to create a visually outstanding, but also reliable, design?
- and many more…
The design phase is of critical importance, not only in terms of the initial project’s success, but also because oversights / mistakes at this stage can have serious adverse consequences down the road. On the low end of the continuum these can manifest as increased complexity and difficulty in managing the program, and on the high end, in an outright inability to add features due to database “dead-ends”.
It’s easy to get so wrapped up in the near-term project requirements that the long-term implications are overlooked. As good as your program may be on day-one, if it becomes increasingly difficult to manage over time you may find yourself needing to go back to the drawing board to start over. So, how can the down-the-road “gotcha” problems be avoided?
These two simple rules will prevent a program from getting out of hand:
- Avoid excessive “user specific” customization.
- To the extent possible, minimize the number of templates you’ll need to support.
Avoiding excessive “user specific” customization will be discussed in a future post, here we’ll focus on minimizing the number of templates in use.
Avoid Unnecessary Templates
Generally speaking, the quickest and easiest approach to satisfying diverse requirements is through the construction of a new template option - little thought is required, just clone your existing template, add (or remove), some content option, and voila, job done! Creating two “single purpose” templates is usually the quickest way of meeting dual requirements.
Take heed though, you’re likely to pay many times over, down the road, for this quick shortcut taken today.
Why? Because your email signature program will have a lifespan measured in years, and over these years, maintenance will be required. This maintenance can take on many forms:
- Changes to branding – new logo / colors.
- Changes to social media presence – a decision to remove Twitter, etc.
- Changes within social media presence – Twitter becomes X, Instagram updates its icon.
- Technical changes to email – “dark mode” emerges / O365 web drops support of “nowrap”.
- Changing legal requirements – corporate attorneys require updated confidentiality language on your signatures.
- Changing external landscape – fax becomes obsolete, online meeting scheduling become ubiquitous.
- And many, many, others…
While these changes are generally easy to execute, they require one or more touchpoints on every template in use. So, if you’ve built your program around a minimal number of multi-function templates, you’re golden. Conversely, if you’ve allowed your template library to grow unnecessarily large and find yourself needing to update ten or twenty different templates, even the smallest of changes can become aggravating. Larger changes, that require testing, can become downright daunting.
Think “Swiss Army Knife”
To minimize future maintenance efforts, use the “Swiss Army Knife” approach – create one (or just a few), massively flexible, template(s) to accommodate all user requirements. This can be done by providing users with a set of options in whatever signature configuration portal you use. These typically cover items such as:
- Inclusion of a headshot
- Location
- Logo (if the signature program is for multiple brands)
- User customized social media links
Let’s take a look at a few of these, starting with a multi-brand example:
In this case, a considerable amount of programming went into the development of a single drop-down menu to control not only the logo, but also the font color of the user’s name, phone number labels, linked text and the color of the social media icons. The result of this is that what would have normally been six templates to maintain, has now become one.
Because this email signature program required an option for users to include either a rectangular or round headshot, this was programmed into one template (at the configuration level), rather than splitting the template into two:
Regarding locations, there are multiple approaches that can be used – often the easiest is to just provide fields for users to enter their location – street, suite #, city, state, zip code. However, this leads to potential inaccuracies and inconsistencies, and sometimes just generally bad data entry (caps lock was left on, Los Angeles is entered as “LA”, etc.). To create the best results, it’s best to pre-code the address information for the user to select from, rather than asking them to type it in themselves. This is best done as a “locations” feature in the signature configurator (rather than creating and having to maintain multiple templates).
This company has 50+ locations, so clearly the menu select feature makes sense compared to the alternative of a specific template for each location. In some cases, you may find that individual users need to feature their own social media, rather than to company’s social media (especially true in the real estate industry). By building options into the template, this can be accomplished without the need for a customized template for each user.
The four screenshots above illustrate the use of a single template, covering all the needs of a complex signature specification for a multi-brand, multi-state, mortgage broker. While the initial programming required to set up a template like this is considerably more complicated, the down-the-road maintenance is massively simplified. This pays off in three ways:
- Less time required for maintenance tasks.
- Less stress each time template maintenance is required.
- Reduced possibilities of mistakes (and the adverse impact they have on users).
Unless you specifically think about it, it’s likely that you won’t notice the upside of minimizing the number of templates in your program. Conversely though, if you allow your template library to grow unnecessarily large, you will absolutely notice the downside – over and over again!
If you’re not sure how to build this type of flexibility into your program, using an email signature service like Dynasend is an easy way to ensure that the platform you’re providing is designed for efficient, stress-free, maintainability.