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.

[Vikram_Ramesh]

Hello Peter,

I am one of the Product Owners with Marketo. I do understand that this post is a couple of months old. My intent here is to understand the usage of editors and to enhance it. I do realise that the tone of the conversation here is a tad bit different, but nonetheless I do feel that there are definitely some areas here that I could focus on. Things like, how can we engage our users within bounds of Marketo and less on 3rd party design tools. Also, what would our users need to get things done within the scope of our editors. 

Also trying to understand- what if a HTML formatter is provided in the editor, would it suffice? Or having a set of predefined templates helps? Please do let me know if we could connect for a discussion to understand your usage more. 

Best Regards,

Vikram R

email: vikram.ramesh@adobe.com

phone: +91 988 607 4356

[Grace_Brebner3]

Hey Vikram Ramesh, if you're genuinely looking to enhance the editors, then personally I'd really like to see a survey or discussion posted asking the wider community for their opinions rather than just singling out specific users on months old posts. This is a really valuable & important conversation to have, & lots of people have great thoughts & insights (like Dave's response) but you're going to generate more conversation and get a more representative response that way.

[Vikram_Ramesh]

 I have created a new Discussion here. Kindly provide your inputs. 

Best Regards,

Vikram R

[Vikram_Ramesh]

Yes Grace Brebner‌. My intent initially was to check the health of Design Studio, thus started off with older posts. 

Would be super helpful if we can discuss on all things email (and Design Studio overall). 

Best Regards,

Vikram R

email: vikram.ramesh@adobe.com

phone: +91 988 607 4356

calendly: Calendly - vikram avadhaani 

[Dave_Roberts]

Hey Vikram, here's my two cents...

Also trying to understand- what if a HTML formatter is provided in the editor, would it suffice?

I think the biggest help here would be to take the EM 2.0 framework and apply it to landing pages. It's nice to be able to format the html but those tool would probably need to be more open-ended so they could be dialed into more specific brand requirements. The Rich Text Editor is really either A) slowing down anyone who knows html -or- B) confusing a lot of folks that don't know html (things like copy/pasting from word, the way the editor handles styling w/ spans, divs, etc). 
An example of something more like the EM 2.0 framework w/ LPs might be as simple as adding in similar variables - list, number, image - to allow a user to choose a color from a dropdown instead of using the RTE to add add'l html to color the text. There's an idea in the community here:   that's along these lines.

Overall, I think the biggest challenge with designing in Marketo is two-fold -- 1) getting it right the first time (a solid foundation) and 2) being able to make changes that are more "error proof". 
Editing emails was always a pretty thorny subject until EM 2.0 came along and now with the combination of modules and more variables, it's easier to make design-type (color, font-size, etc) changes without impacting the overall code-base. Something like this might be a huge win for Landing Pages as well and address the same problem with a proven solution.

Or having a set of predefined templates helps? 

Templates age.... quickly. I think providing a collection of templates is something that either needs to be more crowd-sourced or maybe something internal that a team would stay up on and support (but this is more expensive for sure). Once upon a time, shortly after the release of EM 2.0, Marketo ran an email template contest that I thought was a pretty good example of how to get the community involved and provide more current template code to "update" the library. Perhaps there could be some kind of "badge" in the community or something that'd help folks who do make templates get recognized and maybe earn some new business in the process. Check out https://themeforest.net/ for inspiration - they're a template marketplace (so maybe some big-picture ideas here) and if you check out any of the templates, you'll notice some badges for the authors that help to "certify" their work over time (eg. "street cred").

Regardless of the approach here, it might also be worth it to think about this issue in terms of "modules" rather than templates -- they're more granular so updates can be singular or en-mass which makes them more manageable and it might also allow users to create their own templates which might be the biggest win overall here. 

In the simplest terms, a "module" would be the same thing as it is for Email 2.0, just for Landing Pages. Maybe in a more "futuristic" application, you could drag-n-drop modules onto a template and those modules would be preset with all the variables, CSS and HTML you'd need for that specific piece. In this way, modules could be used to build templates once the blocks were setup and/or they could be used to add/edit the actual Landing Pages similar to the EM 2.0 experience now.

[Vikram_Ramesh]

Thanks Dave Roberts‌.

Point noted on extending Email 2.0 sort of features to Landing Pages. My rationale behind the HTML formatter, was to aid the (seasoned) HTML developers. Yes, not everyone is inclined to edit HTML and there must be enough to guide others to create templates as they'd like. For that, similar tools as Email 2.0 might be a good start.
On templates, I hear you. They do age. I was hoping that, templates could be frequently updated to mitigate this. I believe that Designers come in at this stage. But yes, not everyone operate this way. Having a modular approach to create their own set of templates, like you've pointed out, could work well.

Please feel free to engage me in a detailed discussion. This could help me in getting a better understanding.  Appreciate your effort in jotting down your requirements with this much detail. 

Best Regards,

Vikram R

email: vikram.ramesh@adobe.com

phone: +91 988 607 4356

calendly: Calendly - vikram avadhaani 

[Karyn_Hill]

Our designer is involved from the very beginning. She draws out what she wants and then I code it. She reviews it and we change as necessary. When someone needs a module that doesn't already exist, we follow the same process. We have a style guide that determines much of the look of things but she's the one who determines how it should all be brought together. To my understanding, this is the normal procedure in most places. Designers aren't brought in as an afterthought when everything has already been built; they're a member of the team from the start.

I'm the only one where I work with any coding knowledge and we have only one designer so that may make the process easier to follow than it would be for most companies, but not by much.

[Dave_Roberts]

The best "integration" of design that I've seen is when the design team works to create an "ecosystem" of visual communication - the bits and pieces (think legos) that can be put together to create different use-case layouts by the Marketing team. A clearly defined set of elements and styles (and some brand enforcement along the way) goes a long way to allow the flexibility that the marketers need when building out new pages without compromising the aesthetics or branding. This might look something like your creative team doing an audit of all the assets (EM, LPs) you're using currently to get a feel for the required bits and pieces. From there, they can work their creative magic to weave all of those assets together - eg, if we do a "Main Headline" anywhere, it's always bold, purple, 32px and Arial font. 

Where I'd expect this to fall apart is when the marketers need an element that doesn't exist in the template / asset already and have to resort to the dreaded one-off. Instead, this is where they can reach out to the design team for a suggestion or have them work on a new solution (element) that fits within the context of your brand ecosystem. If you take the extra time upfront to audit and capture current (and even some future) requirements, you'll really limit the number of times you'll need to create something new down the road.

Two things to try and avoid:

Design-minded (creative) Marketo novices being in charge of creating things in Marketo. They'll usually end up looking good, but often not function as well as if they were built by an experienced Marketo practitioner. 

Experienced Marketo practitioners being in charge of doing creative things in Marketo. They'll usually end up looking really off brand, but will function well in terms of the Marketo-ness of it all.

For my time and money...

I'd task my marketing team with creating a list of examples that point to anything they've used in the past ____ mos. This would look like screenshots or links to all the emails and LPs we'd want audited.

I'd task my designers with an audit of those examples and have them hammer out an ecosystem of elements that could be used (think modules) to create all of the different elements you'd use in any communication (EM or LPs). This would look like everything from headlines to buttons and might include more "complex" components like a "Speaker" block, or "Save the Date" module. In any case, this'll get marketers and creatives speaking the same language and that alignment might go a long way to help your design team's learning curve within Design Studio.
From there, I'd take all of that to an experienced Marketo developer and walk them thru your existing use-cases (Marketing) and your new designs (Creative) and have them build out the technical pieces of each. This'll give you a great foundation to grow upon. Your design team will enjoy the leg-up of being able to start with something solid and learn how their designs translate into Marketo coding as they go, and your marketing team will enjoy the leg-up of having creative resources that can help with quick things in Marketo without having to reach out to a developer. Teamwork makes the dream work!

[Grace_Brebner3]

I'd task my marketing team with creating a list of examples that point to anything they've used in the past ____ mos. This would look like screenshots or links to all the emails and LPs we'd want audited.

I'd task my designers with an audit of those examples and have them hammer out an ecosystem of elements that could be used (think modules) to create all of the different elements you'd use in any communication (EM or LPs). This would look like everything from headlines to buttons and might include more "complex" components like a "Speaker" block, or "Save the Date" module. In any case, this'll get marketers and creatives speaking the same language and that alignment might go a long way to help your design team's learning curve within Design Studio.
From there, I'd take all of that to an experienced Marketo developer and walk them thru your existing use-cases (Marketing) and your new designs (Creative) and have them build out the technical pieces of each. This'll give you a great foundation to grow upon. Your design team will enjoy the leg-up of being able to start with something solid and learn how their designs translate into Marketo coding as they go, and your marketing team will enjoy the leg-up of having creative resources that can help with quick things in Marketo without having to reach out to a developer. Teamwork makes the dream work!

This is a really great way of framing it Dave Roberts‌ - I hadn't really thought of it in this framework, but it aligns pretty closely to the approach I've always found most effective.

[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 

[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!

[Grace_Brebner3]

Oh yikes, I didn't even think about the velocity aspect. Yep. this.

[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!

[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. 

[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.