Understanding how this feature fit within the product and organizing information
Prior to this project on the roadmap, existing email templates were updated to a fresher and more modern look and feel. These emails were used as the source of truth to understand what type of components are necessary within the email design editor. They were sorted in terms of HTML and CSS but were further refined based on how usable it can be for users with low coding knowledge.
Going from premade collection of emails to understand all the various editable components within the email
Additionally, I conducted market research in order to understand how our competitors were solving this problem. There were a lot of email editors out there, however, they were much more built out and acted as an email builder. Our current scope was different since it only let users edit designs of all emails; changing the copy and implementing design templates would come later.
Sectioning off different component cards
Once the information architecture was finalized, different HTML and CSS elements were placed in their appropriate component cards. Some were straightforward, however, some had a lot of nuance. For example, the Star feature allows users to interact with stars within an email to provide a rating. However, some email browsers did not support this type of interaction and a fallback option is required. These small but nuanced features are confusing to users and we had to provide explanations in the form of a tooltip or design extra interactions.
Throughout the design process, I was in contact with my PM and developer and it was especially helpful during these times since we got everyone on the same page and made sure all of the features made sense and were feasible.
There would be a few main sections: logo, background color, typography, button, and input
What resulted was an intuitive UI that controlled email designs, but that was only half of the solution
The next step was finding a way to show users what they are editing. Here was where we ran into a technical constraint: we wanted to give users the ability to see how their email would look in real time as they make edit, however, live edits could only be seen on one type of email at a time. Users would not be able to see live edits on every type of email.
My initial way of thinking was that since the editor would not affect emails with no live preview, the two components would need to be separated like below: either in a modal or a new tab as shown below:
Iteration 1: Modal
Pros:
Users can quickly see a preview of all of the different emails in one look
Users may be more familiar with this flow since it is similar to competitors
Modal is disconnected from the editing experience, clear separation between what can and cannot be edited
Cons:
May also need to implement skeleton screen to make up for slower loading times to render out all the emails and they may not even need to view every single email.
Too many different levels of previews: the original preview, preview within the modal, and a larger preview
Iteration 2: External link
This version was slightly different since it allowed users to render the email preview in a separate external link.
Pros:
Allow users to send it to their team for review.
Cons:
If users are sharing links to emails, why not just send a real email?
Seamlessly integrating the editor component with the preview section
The final design was a complete shift from what the modal/external link was trying to achieve. My "aha" moment came during usability testing when a user brought to attention the following logic: users can still make edits, they just cannot see the edits for all emails. This got me thinking about how instead of removing the user from being able to make edits with a modal or external link, we can still allow users to make edits while viewing the preview, we just need to notify them that what they are seeing needs to be updated. This got me thinking: instead of restricting the user from making edits through a modal or external link, we could still allow users to make edits provided there is a prompt indicating that what they're seeing might need updating. When users make an edit to an email with no live preview, they are presented with two options:
Reload button - Refreshes the email render so that it reflects all changes made to their design; or
Go to live preview button - Gives users the option to go back to an email type that allows live previews.
This design provided more harmony between the editor and preview functions and was a better reflection of what the email design editor provided without needing to hide disabled components behind a modal. It also had a lower lift and set up nicely for when users can choose individual emails to change copy later.
Where are we at now and how do our features fit in the product roadmap?
Throughout my design process I kept a few things in mind:
Balancing development cost and value it brings to users
What we were building towards and what needed to be built right now in the moment
Provide options within the design when we introduce more features such as changing the copy and implementing design templates
With my current understanding of the roadmap, this design would nicely transition into the next phase of this editor where we would allow users to edit copy and create multiple email templates. Also, if devs ever happened to have time, the additional email types with live emails could slowly be added.
How would I track the success for this?
This feature would have a slow release, initially used by our technical services team so that they can slowly port over their workflow to this email design editor before a wide release to customers as a self serve model. This would help with understanding if the editor and preview components are easy to use and if we need to add any vital features.