Democratizing In-App Messaging
At Evernote, in-app messaging is a core mechanism through which we communicate important business-led promotions to our users. Naturally, the process of determining which promotions we surface and how we surface them in our product involves a number of stakeholders, including those from marketing, finance, design, product, engineering, etc. At a company the size of Evernote, however, it can be a challenge prioritizing promotional initiatives against other important product requirements, especially with regards to cycles set for designers and engineers. Resultantly, we had an overly strenuous process of coordination wherein marketing teams often battled the frustrations of having to rely on design and engineering teams that struggled to balance multiple priorities.
To truly grow as a company, we recognized the importance of enabling and empowering our marketing teams to create campaigns that included direct communication channels to users without having to endure process bottlenecks. In addition, it was important to relinquish design and engineering from repetitive tasks that could be operationalized.
Accordingly, at the end of 2016, we set out to address our messaging problem by building a technical framework — which would come to be known as Comm. Engine — that would enable us to send targeted in-app, web-based messaging through Salesforce Marketing Cloud. I was specifically tasked with designing a visual messaging system that would properly display messages across all five of our clients.
Setting Our Baseline
Before I could get started, we needed to first establish the design requirements for the initial release of Comm. Engine. As such, we began with an audit of past messages in Evernote and messaging in other products. Our objective was to identify components and layouts that we could reuse.
In our search, we observed 3 types of components that we had leveraged in the past and that other products generally used: full-screen modals or takeovers, cards, and banners. We believed these would be good, baseline placements to build as part of our initial release for two primary reasons:
- The messages we would be sending via Comm. Engine would be web-based (as opposed to native iOS, Android, Mac, or Windows components). As such, we wanted to ensure that our messages fit as best as they could into our current landscape of messaging by using components we had already used in the past.
- The placements naturally delineated when to use each one based on how important the message was. That is, fullscreen modals or takeovers demand user attention, so they should be reserved for the most important types of messages. Cards and banners take up less attention, so they can be used more frequently for low to mid priority messages. By tiering the components, we hoped to set precedence for a more complex messaging system in the future.
As for layouts, we noticed a lot of diversity. However, every message generally composed of 5 atoms: a visual, a header, body copy, a primary call-to-action, and a dismissal. Because we only required simple functionality with the first iteration of Comm. Engine messages, we found no reason to deviate.
Designing the Placements
With our requirements set, I was well-positioned to start thinking about how these placements were arranged in the product environment and how they would be presented to our users.
Thinking about how we had used the placements in the past, it felt natural to replicate how messages were already placed in the product environment. That is, full screen takeovers would require a modal placement on desktop or a placement that spanned the entire width/height of a mobile device, while cards and banners would find homes in the user’s note lists.
In addition to placements, we had to make considerations for how these components responded across different device sizes because they were web based. Naturally, some of the atoms could be easily tied to specific pixel coordinates, such as the dismissal or the visual in the mobile banner. Others, however, required relative locations, such as the visual and the copy for the fullscreen takeovers. Fortunately, I was able to sit down with a frontend engineer to determine the correct responsive behavior across our set breakpoints.
With placements and layouts configured, the next step was to think about what background colors we wanted to leverage for each of the placements. This was a particularly important task because we wanted to ensure that we established the correct color associations with promotional messaging. We also had vastly different UI colors across iOS, Android, Mac, Windows, and Web, so it was important that we made deliberate color choices that worked across each of the clients
Admittedly, we didn’t find much difficulty determining the background colors for the fullscreen and card placements. For the former, we leveraged a green background that had been used previously. For the latter, we found that a white background fit nicely into the neutral theming of the note list. However, the banners proved to be a challenge given that our Android client uniquely had a green header that occupied a large surface area. Accordingly, when we applied a gradient or a saturated color, we found too much dissonance. Our only option to accommodate the product discrepancies was to select a less saturated and bright color. We landed on a light stop of our brand green.
As we wrapped up the visual system for Comm. Engine, our last step was to provide guidelines to ensure that any individual who sent out messages through this framework was upholding a certain level of quality. As such, we provided specifications around the visual asset (e.g. level of detail, amount of padding, etc.) across each of the placements. We also provided detailed character counts to ensure that the placements did not break in the product.
Re-Evaluating the System
In the beginning of 2018, I was approached by members of the marketing team to re-evaluate the card placement in the Comm. Engine system. Though we had been mindful of setting rules around how to use this particular placement, teams were finding difficulty writing copy that fit into those constraints, especially due to localization. Accordingly, I spent some time redesigning the cards to allow for more character space. I also took the opportunity to update the banners and the fullscreen takeovers to right some of the visual wrongs I had made as a Product Design Intern (which was when I had initially worked on this project).
Updating the Cards
One the primary constraints we were facing with Comm. Engine in general was related to the behavior in the clients. From a technical perspective, we had built native frames in each of the clients that would call the web-based message. However, we had not implemented the native frames to respond dynamically to the heights of these placements. As such, if messages got too long, they would get cut off or introduce a scroll view — neither of which were ideal. Because we wouldn’t have any developer resources to update this, I needed to redesign the cards in their given constraints.
As a part of this update, I mostly wanted to adjust the card placement to feel more promotional and differentiate itself from the rest of the note list. Given the constraints mentioned, however, this was only doable on the mobile clients. On the desktop and web clients, the only way we could realistically adjust the space to include more room for copy was to remove the visual asset. As a result, I introduced a visual divider to help users discern their own content with the promotional message.
Despite the loss of the visual asset on the desktop and web clients, we were able to make a significantly large improvement to the character count.
Cleaning Up the Visuals
In addition to updating the cards, I took an opportunity to clean up the experience for all of the placements. Specifically, I adjusted each of the designs to fit onto an 8pt grid, which is not an established rule we are working towards across all of our products. I also updated the colors to be more neutral and less obnoxiously green.
Thinking About the Future
Comm. Engine is an important framework for the company, as it reduces overhead and empowers our teams to run full campaigns without having to go through the arduous processes of planning and executing. That said, the framework itself still struggles to be prioritized against many of the other competing product requirements. However, with some upcoming architectural developments, we should find the bandwidth to truly optimize Comm. Engine. When that time comes, these are a few next steps for us to take:
- Improve the behavior of the placements. Creating more dynamic frames that respond to the web view will ensure that marketing teams have the flexibility they need to create and run successful campaigns.
- Add more layouts for each placement to create a more robust and powerful messaging system. Who knows? In the future, we may even be able to expand the role of Comm. Engine to include in-app education, system warnings, etc.
- Conduct experiments on the effectiveness of each placement, as that will enable us to better understand what leads to successful marketing campaigns in-product.