After a crazy week in the office, during week four I finally moved beyond orientation and felt more integrated into the team’s workflow. Similar to last week, there was still a lot going on in the office, but the rain and amount of work on everyone’s plates made the overall atmosphere more focused. This week I found myself concerned with the user interface (UI) for multiple ongoing projects. UI is the visual, front-facing side of design. The UI designer has to make sure that the user’s preferences are considered while creating a cohesive, visually pleasing design. There were three projects that involved designing the user interface:
- Phase two of the email design
- Newsfeed mockups
- Mobile application sign-in mockups
For all three of these projects the user experience (UX) had already been determined through wireframes or storyboarding.
My main task was the second phase of the email design, which consisted of coding the mockups. The tools I used for testing were Email on Acid and Campaign Monitor’s CSS inliner. The inliner takes the CSS and embeds it into each HTML element; this is necessary so the email clients can read the formatting. I then took the inlined code and inserted it into Email on Acid. Email on Acid then shows how the email looks in different email clients. In this case there were 30 different use cases.
After finalizing the email wireframes last week, this week I was tasked with actually implementing them. The first difficulty was that the email layout needed to be easily edited by the sales team as they will be using it as a template for multiple email blasts. Another roadblock was that only certain styles are recognized by specific email clients and so some design concepts may need to use hacks. Even when keeping best practices in mind, I had to remind myself that there would probably be issues when I got around to testing the code.
I started by taking the wireframes and coding them using HTML5 and CSS3 to see what they looked like on screen. After developing two of the wireframes, one was chosen to move forward based upon the fact that it was easier to alter and more eye catching. The next step took the most time: perfecting the email UI. The email needed user appeal while also highlighting the paying sponsor without coming off as an advertisement. It also needed to be easy to scan and make the user want to click on the call-to-actions. After using some popular examples for inspiration and creating many different iterations, the design was finalized. It was then put into Email on Acid.
There were obviously some inconsistencies that needed to be addressed after client testing the email. A few that I ran into were: the typeface changing to Times New Roman, the sponsor logo stacking rather than staying inline, and image warping in only Outlook 7.
Email on Acid – Issue #1
I knew the typeface I was using wasn’t going to work for all clients but I didn’t know why it wasn’t defaulting to “sans-serif”. I ended up needing to add “font-family: Arial, sans-serif;” to my conditional styles for Outlook even though it was already stated in the normal font declaration.
Email on Acid – Issue #2
For the sponsor logo stacking, I took the two elements and put them in separate table cells rather than using positioning styles.
Email on Acid – Issue #3
Finally, for the image warping I added a height specification to make sure that client knew how tall the logos should be. There were other issues I ran into including content width irregularities, footer styling and header hierarchy.
After all of the small adjustments the email was ready to be passed on to the Ad Operations team so that they could use it for actual email blasts. They will now be in charge of email client testing it before every send to make sure that no issues pop-up.