When to add designers?

[Peter_DeMichele]

We are working to scale our digital marketing efforts at my company, building more campaigns, emails, landing pages, forms, etc. We have worked to developed a strong email 2.0 template as well as a pretty flexible landing page template with a 3rd party design team. Our internal creative services team wants to get more involved, working directly within our instance. We have talked about utilizing a sandbox environment for the design team to tinker, test and iterate, and we are still unsure if this will create efficiencies or just more work for our marketing ops team. Our design team lacks HTML experience, really would be designing in Design Studio instead of In-Design.

I'd love to hear from you how you are handling this at your companies.

[Kevin_Weisenber]

Hi Peter, 

It sounds like you are following the right train of thought in that designers can be both a boost to productivity and output or they can be a drain on resources (especially with limited HTML knowledge). I would approach this by understanding why the designers want access to the instance and what they think they can help you accomplish, additionally I would ask yourself similar questions and to share each others responses so each side is aware of the upsides and downsides with a shift in process. Keep in mind that the attributes you/your team currently possesses as marketing ops personnel likely does not include design skills (hence you farming this out previously) so there is a place for them in your team. 

When implemented efficiently into your work flows a stronger copy/design can have drastic changes to your conversions. My recommendation would be to approach this from a thoughtful analytical mindset doing lots of A/B tests or bringing over known successful copy from your targeted audience and continually making experimental changes to it. A good designer will be supportive of this and help you to iterate on this. 

[Natalie_Kremer]

We've established a partnership with our internal design team that has worked really well for us. They do not specialize in HTML (neither does our marketing automation team), so we've worked with them on the design of new email templates and then worked with an outside 3rd party to code the designs for HTML. I would encourage you to do some knowledge sharing with the design team so they understand the design limitations in Marketo and maybe there's a similar partnership you could come to agreement on. 

[Ronnie_Duke2]

IMO, unless your design team can quickly get up to speed on HTML, I predict having them tinker with your existing templates will cause more problems than it solves. Both Landing Pages and Emails can be extremely finicky when it comes to getting right for cross device/browser compatibility and even the slightest change can cause it to break and spend hours trying to remedy. 

One thing I've found helpful in the past is that if you develop the creative internally, you can work with most competent web developers by simply sending them the documentation for "Marketo-izing" the code.

Emails: https://docs.marketo.com/display/public/DOCS/Email+Template+Syntax

Landing Pages: https://docs.marketo.com/display/public/DOCS/Create+a+Guided+Landing+Page+Template

I know the initial instinct is to send to an experienced Marketo shop to set these up, but as long as the web team can follow the documentation, they do not need to be Marketo experts to build these. 

Having said that, there are some tricks that can be learned over time by building many of these templates such as using variables to change CSS code, or knowing when to use a variable instead of editable text. However, in my experience these concepts can be learned rather quickly by good developers (happy to send some referrals your way if you need).

Hope that helps!

Ronnie 

[Grace_Brebner3]

I predict having them tinker with your existing templates will cause more problems than it solves. Both Landing Pages and Emails can be extremely finicky when it comes to getting right for cross device/browser compatibility and even the slightest change can cause it to break and spend hours trying to remedy. 

Agree agree agree - keep users without email html knowledge away from the templates!

One thing I've found helpful in the past is that if you develop the creative internally, you can work with most competent web developers by simply sending them the documentation for "Marketo-izing" the code. [...] I know the initial instinct is to send to an experienced Marketo shop to set these up, but as long as the web team can follow the documentation, they do not need to be Marketo experts to build these.

But I would have to say I kinda disagree with this - or would at least extend a warning here. Email development is not the same as web development, and a good web developer with no experience in email is likely to find that developing for email is a different ball game (an extremely frustrating one, at that). A lot of things that you can do in web with three lines of code require 20 lines of code for email and a considerable amount of testing to get right.  

It is possible that a good developer will be able to implement Marketo's email syntax well without experience... But the "over time" bit here is really key. In my experience, it tends to require people who use the editor frequently to really get the hang of it to maximum effect.

The key question in my mind really is: do you need an internal capability for ongoing, ad-hock email development, or do you just want a template built that suits for now? The former would be a good case for upskilling existing resource, the latter arguably it's more cost effective to outsource to someone with the specific experience. NONE of this is to say a decent web developer couldn't do it - but that someone with email specific experience, and even better, marketo specific email experience, is likely to be able to do it much faster, be less infuriated by the process, and provide a better end result both in terms of in-editor usability for the marketer, and in terms of consistency of display across email clients for the eventual recipients.

If upskilling a web developer to do become fluent in email dev, they'll need a lot more time for the first couple of rounds, should work closely with users to test in editor functionality, and it'll be critical that they have access to a tool like Litmus or Email On Acid.

I actually wrote a whole post which summarises my thoughts on the subject much better than I can here... https://nation.marketo.com/community/champion/blog/2019/05/30/5-email-myths-you-need-to-dispell 

[Ronnie_Duke2]

You are correct - email development is WAY different than standard web development. Most shops I have worked with in the past have been fluent in both, so I didn't think to specify. But yes, I would not go to just any web developer and expect them to be able to develop a fully responsive modular email.

I only meant to say that in my experience, giving a competent web/email developer access to the docs for the Marketo syntax, it wasn't much of a stretch for them to wrap certain areas of code to make them editable in Marketo or swapping out placeholder text with variables. I suppose the caveat was that I had already had a lot of experience using templates in Marketo so I was able to communicate what I wanted so it didn't take too much back-and-forth to get it across the finish line. Obviously mileage may vary depending on the developer 😉

You are also correct that a Marketo consultant may be able to do this more efficiently, but it will also come at a cost. My point was to say that there are options, that's all.

Thank you for the clarification!

Cheers,

Ronnie

[Grace_Brebner3]

Yep, unfortunately most people who don't have much involvement with email dev just don't understand how complicated it is. Expecting a web developer to be able to do what an experienced email developer can do as successfully in the same time frames (which those without an understanding of the differences might do) sucks for both the web developer who gets stuck with an impossible deadline and the email developer who doesn't get the recognition their skill set deserves 

The developer can have less experience with the syntax if the person writing the brief has lots and is able to be very specific about functionalities they want - that's totally true. There's a next level up to using the syntax super effectively around other marketo features (e.g. tokens and snippets), combined with knowledge of how things are actually used on the regular (e.g., where modules should start & finish) that typically does really require a lot of experience + critical problem solving. 

You're right that a consultant will come at a $$$ cost - and absolutely yes, there are options. Unfortunately in my experience, many people get their internal web developer onto the task because it's "cheaper" - i.e., there's no hard $$$ cost associated with it - just the cost of the person's time. It might take their web developer 2-3x longer (time they're not spending on other areas of the business) and their version might not be ideal and require many more revisions, and eventually be more likely to be fully replaced sooner. The latter option is often actually at a greater cost to the business - that cost just isn't reflected in an invoice 

It's also worth noting that external resource doesn't have to be crazy expensive, either - there's quite a few third parties with strong marketo experience who can turn around custom template dev quickly & at a reasonable cost - I haven't personally used them myself, but I've heard good things...

[Ronnie_Duke2]

The developer can have less experience with the syntax if the person writing the brief has lots and is able to be very specific about functionalities they want - that's totally true. There's a next level up to using the syntax super effectively around other marketo features (e.g. tokens and snippets), combined with knowledge of how things are actually used on the regular (e.g., where modules should start & finish) that typically does really require a lot of experience + critical problem solving. 

For sure - I suppose this also comes down to project requirements. I've done projects where there was advanced logic needed for multi-branded orgs where having a solid understanding and pushing the limits of the Marketo syntax. This is of course way different than a simple newsletter template where the user needs to simply swap out the banner image and edit some text. Choosing the right path that matches the need is clearly a factor here. 

You're right that a consultant will come at a $$$ cost - and absolutely yes, there are options. Unfortunately in my experience, many people get their internal web developer onto the task because it's "cheaper" - i.e., there's no hard $$$ cost associated with it - just the cost of the person's time. It might take their web developer 2-3x longer (time they're not spending on other areas of the business) and their version might not be ideal and require many more revisions, and eventually be more likely to be fully replaced sooner. The latter option is often actually at a greater cost to the business - that cost just isn't reflected in an invoice 

Agreed. Again, it just comes down to the complexity of the project and long term needs (as you mentioned in your previous post). An internal dev might be able to handle a simple demo request page, but if the need is to create templates for an entire resource library, having a solid understanding of the Marketo ecosystem would definitely be beneficial here.

I've also seen situations where outside consultants are brought in but don't know anything about the business and the back-and-forth can drive up billable hours there too...it can definitely go both ways. 

It's also worth noting that external resource doesn't have to be crazy expensive, either - there's quite a few third parties with strong marketo experience who can turn around custom template dev quickly & at a reasonable cost

Very true 🙂 

[Grace_Brebner3]

All of this is very true

I think the tl;dr comes down to: understand your business' needs, decide which solution is best suited to those needs, and then create a very clear brief!

[SanfordWhiteman]

I agree completely, Grace.

An otherwise experienced email developer will still not promptly understand tokens, modules, editable areas, variables and reserved variable names, dynamic content, and snippets, let alone Velocity. They can adapt, but will mess up bad along the way. A Marketo-fluent email developer knows these things from day one. It's not a negligible skill set.

An otherwise experienced web developer who hasn't worked on email is bound for a long period of study. I'm a JS developer, teach classes on Velocity, and have long understood semantic HTML and "proper" CSS for the web. But I never build email templates myself because I know what I don't know!