Summer Synopsis

As my internship comes to a close I reflect on the highlights of my summer and all of the new things I learned. To start, interning at Industry Dive was a very beneficial experience. The amount I learned about web design as well as the digital media industry and start-up culture was astounding. Here are ten lessons I learned this summer either from the intern program, the design team or from the company. Some of these may seem obvious or cliche but often times you have to experience something before realizing the truth in the statement. If you want more specific technical lessons and the projects I worked on you can find them in the rest of the blog posts.

  1. Office culture matters

    One thing that Industry Dive really brags about is their office culture and the fact they have been selected as a Washington, DC best place to work. I didn’t understand the importance of this until I started working here. Really enjoying where you work and who you work with makes the tasks seem much easier. Feeling comfortable to ask questions and recommend new ideas allows everyone to feel like they are a pivotal part of the team.

    Industry Dive employees on the company boat cruise!
  2. Never stop learning

    Our weekly company meetings surprised me in that I didn’t expect to enjoy them as much as I did. The meetings consisted of each department sharing what they were working on and allowed people to celebrate co-workers accomplishments. At the end of the meeting a different department presented what they do on a daily basis. The fact that everyone wanted to learn about each other reflects the overarching collaborative and inquisitive environment.

  3. Coffee is a way to network

    Another company wide event was the coffee challenge. The challenge tasks each new hire to take different co-workers out to coffee. The hope is to encourage all new hires to interact with other departments one-on-one and make personal connections. Since I am typically more of an introverted person this gave me a way to reach out to individuals and push myself out of my comfort zone. This taught me the importance of getting to know different people throughout the office even if they aren’t in your department. It also inadvertently taught me to tolerate coffee.

  4. Group projects will always be hard

    Part of the internship program was the internship project. The challenge was for the five interns to create a data driven featured article. In the end we were very proud of our final product but it wasn’t always a seamless process. Group projects will always face challenges around divvying up roles and solving unanticipated road bumps. The difference compared to school projects was that all of the interns wanted to succeed and contribute to the project. I found working with a group of intelligent individuals on a real-world project was much more satisfying than a grade.

    Industry Dive 2016 summer interns
  5. Dogs are great work partners

    A fun highlight at Industry Dive was the open dog policy where employees can bring their dog in for the day. Being able to work with a dog at your feet was definitely something new and brought smiles to everyone at the company. I grew up with two dogs so it was great getting to have some canine friends around. I also learned that I would probably never bring a dog in as I personally wouldn’t be able to get anything done.

  6. Resumes don’t have to have everything but the kitchen sink

    Part of the internship program was the resume review. I was given the opportunity to send my resume to my supervisor for feedback. Initially my resume included every accomplishment I had ever achieved since my freshman year. The review helped me focus my resume and set me up for success for when I decide to apply to jobs.

  7. Startups have a lot to offer

    One of the most impactful lessons from this summer was realizing the opportunities that startups hold. The variety and scope of projects I was able to work on wouldn’t be possible at a larger company where roles are much more cut and dry. Seeing just how the design team could offer up new ideas that were implemented in a quick time frame really opened my eyes to the benefits of small companies. While startups may not hold the prestige of working for a household name, being able to make a difference and shape a product is something that I have always considered a career goal.


  8. Career paths are not linear

    Another internship program event was the new hire panel. Note that at Industry Dive “new hire” is relative term since the company has doubled in size in the past year and new hires are abundant. During this event all of the interns were able to hear about how different individuals ended up at the company. The most surprising aspect was the fact that not many of the employees graduated expecting to be in the role they are in now. While I know I am interested in web design I understand I probably can’t predict the exact role I will fill come a few years after graduation.

  9. Gifs are still relevant

    One prominent part of the Industry Dive community were gifs. I quickly learned that my gif knowledge and experience are greatly lacking. While I still have a lot of room for improvement I have learned about making, finding and sending gifs.

  10. There is always a way to improve

    The final lesson I learned from the design department was that you can always be improving and optimizing. While I was here the process for different design team projects was continually being optimized and questioned. Rather than just settling on something that worked the desire to be constantly improving drove all the tech and design decisions. In just my ten weeks a new mobile site was launched, a new mobile application was drafted, a new desktop site was started and a new design workflow was developed.

    giphy (3)

UI Makeover – Data Part 2

As the internship project wrapped up, another exciting thing happened in the office this past week: the deployment of the new mobile application. Both the design and tech teams celebrated the successful launch of the new design onto the Utility Dive mobile site. Once the site seems stable and if no large issues arise, then the tech team will deploy it across the other industries. While I was not an integral part of the redesign, I was able to provide user feedback and help with the test of the site across platforms.

With both of these exciting projects coming to a close, I had to start making moves on the data visualization tool (which I introduced in the Internal User Testing post). I left off with the next steps for the internal data tool being to determine the requirements and prioritize them so that I could start implementing them. The first thing I did was take all five user interviews and list out all of the desired features and sort them into front-end or back-end. The front-end issues were the ones that I thought I could address before the end of the internship. I then further divided them into either a priority or reach goal. This allowed for me to show which goals the users had brought up that were good ideas, but were maybe not quite as feasible. I then added all of the goals (both priority and reach) to GitHub as individual issues. I began with around twenty issues but this number fluctuated as I learned more about Shiny applications and R.

Challenge and Approach

My challenge was to take all of the front-end issues and solve them using my HTML/CSS experience, along with learning how to solve them if it were a Shiny specific design issue. The issues I solved can be broken down into two categories: visual and accessibility adjustments. The main focus for the visual challenge was to incorporate an external CSS sheet so that I could have easier access to the design styles. I ended up using the ported SASS for Bootstrap since the Shiny apps are built on top of Bootstrap and Bootstrap is initially built with LESS. Once I had the SASS files I created a custom file to override the Bootstrap styles when necessary. While this is more extensive than just attaching a CSS file, it allows for easier customization in the future.

The visual issues involved not only adding a stylesheet but also figuring out how to responsively size the graphs and tables. I also addressed the complaints concerning the visual hierarchy of the tables versus the graphs and reorganized accordingly. The accessibility adjustments consisted of helping make the tables easier to use as well as indicating when the application was loading. To improve the tables I added default sorting from descending order, changed the labels to be semantic rather than the variable names, and made the sorting arrows more visible. To confront the loading issue (the user couldn’t tell when the page is loading), I added an overlay that appears whenever the application is either initially loading or recalculating. Overall, all of these small changes made a very large difference in the user experience.


Visual Improvements

The main visual improvements were the addition of a stylesheet as well as making the graphs and tables responsive. As you can see in the first screenshot, the graph extended past the edge of the screen.

Screen Shot 2016-08-08 at 5.31.19 PM

Screen Shot 2016-08-08 at 5.31.01 PM

I also updated the Dives page to better reflect the users priorities. Rather than having a table that showed only one data point I instead called out specific values.

Accessibility Improvements

With the addition of a loading screen, the user no longer has to wonder if the application has frozen or if it is just still calculating the results they requested.


As for the tables, the most apparent adjustment is the styles. There are also improvements in the sorting capabilities with clear column names and easy to find sort features as well as the removal of the non-intuitive bottom search feature.

I also added a legend for the graphs to help the user know what each line represents. In the left column I added helper text for the y-axis dropdown and added delete (x) indicators on the multi-select filter.


The Intern Project – Part 2

As the month of July came to a close, I continued working on the intern project and finalized the new email blasts. I completed three different designs for the email blasts based off of the original template: webinar, survey and lesson. Each template design borrows from the same premise of being easily customizable and attention grabbing, while remaining unique in style. The webinar template includes speaker profiles, the survey template has a call-to-action above the fold, and the lesson template incorporates iconography. Together, the emails create a consistent message but also allow for the ad operations team to include topic specific details for each email blast.

The rest of the week I focused on the internship project as we prepared for the featured articles to be published. The editorial intern worked hard to finish each of the pieces and have them reviewed by publication editors while the tech intern and I kept busy finalizing the layout and design details. We met multiple times to discuss what the design requirements would be and how the aesthetic would be consistent across the three publications.


Previously, I had broken down the project into three parts: design aesthetics, data visualization, and compartmentalized articles. While I drew off of these inspirations for the final iteration, I also had the challenge of recognizing the necessity of stepping away from some of the more intricate ideas. Most of the deviation stemmed from the fact that the content management system restricted the scope of the design customization and also that the article needed to be stylistically consistent with previous featured articles. With that being the case I focused primarily on the pull-quotes, chart design and graph stylization.

Approach and Results

Pull Quotes

The approach for the pull-quotes was to look at pull-quote styling throughout other publications and see what made them successful. Using my inspirations, I decided that I wanted a headshot of the speaker to incorporate more photography throughout the piece. I also wanted to include a little bit of red to make it stand out more.

Screen Shot 2016-07-20 at 10.28.51 AM.png


The table took a few iterations before the design successfully supported the data. The challenge here was that while I wanted to incorporate color, at first it caused more confusion rather than helping the message. By removing the strong color from the first iteration and emphasizing the US data over the state data I found the chart to be more successful.


Finally I tackled the graph stylization. The first challenge for the graphs was that the data itself was not what we had anticipated. Initially, we wanted to use line graphs to show the difference over time of worker populations. However, we soon realized that the difference was not significant enough to show visually in this manner as it was often less than 1%. I then tried different ways of communicating the same idea such as the percent difference. While this was interesting to look at it, the graph was even more confusing. Finally I decided on a donut chart; though this chart is less powerful due to less data, it is more direct in its purpose. The chart now allowed the user to see the worker profile of the current year in a clear way.

Check us out!

Utility Dive

Construction Dive

Education Dive


Responsive Images

While the intern project is still in full swing, I have also been working on GitHub issues for the front-facing websites. This was my first time using GitHub for a multiple person, large scale project. While I’ve dabbled in it previously for school projects, I had not used it at its full capacity until this project. The hardest part of getting into GitHub was remembering the terminal commands and knowing when and where to use them. After a couple iterations, I was able to smoothly interact with the version control system. One aspect that I really appreciated while working with the Industry Dive repositories was the streamlined process. All issues and pull requests had templates, creating a consistent bug and solution reporting process. Another thing I was introduced to with these projects was Sass, a CSS extension language. The only adjustment that I had to make when using Sass was making sure that I understood all of the variables and nesting structures.

Two of the issues I was assigned concerned responsively serving images. My only experience with responsive images up until this point was with retina and non-retina images. To fully understand the breadth of options for responsive images I took the Udacity course Responsive Images. This helped me understand possible solutions to make the images responsive. Another great reference that helped after I had taken the course was A List Apart’s article Responsive Images in Practice. Together both of these resources helped me pick the best solutions for my issues.

Screen Shot 2016-07-21 at 12.28.48 PM
The Respsonive Image Udacity Course


My task involving serving responsive images was more complicated than I anticipated. Both issues involved three types of images: background images in CSS, fixed size icons, and fluid width images. Each one of these required a slightly different solution given their specific case: the background images needed media queries since they were in CSS; the fixed size icons would just need to have a retina and non-retina option; and the fluid width images would need srcset and sizes. The fixed size icons were the easiest because they just need two sizes and the background images were straightforward as well since I had used media queries before. The most challenging issue was the fluid width images.


The approach I took for the fluid width images was to first figure out all of my use cases. I ended up boiling it down to five options: small (non-retina), small (retina), medium (non-retina), medium (retina) and large.

Once I determined the options, I then had to figure out what breakpoints the site was using. It turned out there was a specific rem size for a small and medium breakpoint. Then I had to determine the largest image size needed for each option and resize the images accordingly. I then implemented either the media queries for the background-images or the srcset and size for the fluid width. The last step was to test that each device was being served the correct image. I used the Chrome developer tools to test the site on different devices. The one caveat was that I had to make custom non-retina devices to test those use cases.


The results were images being served correctly. Below is the code for an example of one of the fluid width images. The sizes are calculated based off of the grid being used. The .66 is the 66% that the image is taking up of the screen and the 1.875rem is the padding around the image. The final size is 100 because in mobile it takes up the entire screen. I ended up only needing three image sizes for the five use cases since the large (1200) could be used for both large and medium (retina) and the medium (800) could be used for both medium (non-retina) and small (retina).

<img srcset="/brandstudio_600.jpg 600w, 
/brandstudio_800.jpg 800w, /brandstudio_1200.jpg 1200w"
sizes="(min-width: 40.0625em) calc((.66*100vw)-1.875rem),
(min-width: 64.0625em) calc((.66*62.5rem)-1.875rem), 100vw"
src="/brandstudio_800.jpg" alt="Responsive"/>

The Intern Project – Part 1

To start, the first thing I’ve learned this week is that I will take a dry hot day (aka Colorado) over a humid hot day any time during the summer. As the heats been rising this week the design and development teams have stayed inside preparing to start internally pushing out parts of the mobile redesign. While that’s been their main focus, I have been meeting with the other interns to start making real progress on the intern project. The task for the summer interns was to produce a data-driven feature article that is applicable to multiple industries. Some essential tools for this project were examples and inspiration articles. While a data-driven feature sounds straightforward, it helped to see how other news companies have addressed these types of stories. My main resources for research were the Washington Post Graphics, New York Times Graphics and the Brookings Essays.

For this project there are five interns: data analyst, front-end development, editorial, audience development and myself, front-end design. All together we form a miniature editorial company. The project was presented to us broken down into five steps:

  1. Choose the topic
  2. Find data
  3. Build a story plan
  4. Report and design
  5. Build a publicity plan
  6. Present to the company

We are now on step four, as the past few weeks have focused on steps one through three. The hardest part of those three steps was to choose a topic with easily accessible data and a reasonable scope. A lot of our concepts either sounded really good on paper and then didn’t have data readily available, or had readily available data but were very broad and could easily get out of hand. The overall concept we chose to move forward with was the changing demographics of workers in specific industries.


Once we got to step four I had to start finding inspiration and developing a game plan for the design of the story. Since the time frame for the reporting of the story is so short, we have found that all the interns have to simultaneously work on the project. The challenge for myself and the front-end developer intern is that we have to try and anticipate the types of things that will be needed to help support the articles.


Our process began with the front-end developer intern and myself sitting down and analyzing the current state of the project. We realized that while we knew the article topics we didn’t have a ton of specific information to go off of just yet. During our meeting we agreed on our expectation for what we could produce in the time frame and the goals for the articles. The second time we met we brought inspiration we had found and specific ideas concerning the article. I contributed ideas concerning: overall design aesthetic, data visualization inspiration, and examples of compartmentalized articles.


My results are the examples and inspirations that I have found for the design concept.

Design aesthetic: The examples I found for aesthetic inspiration helped show the rest of the team what I am envisioning and what I felt was manageable in our time frame. I found that I was leaning towards examples with large usage of white space, vector based graphics and minimal color.

Screen Shot 2016-07-14 at 3.09.46 PM

Courtesy of NY Times

Data Visualization: The aspects I focused on when looking for data visualization inspiration were examples with clear purpose and easy to scan. I also tried to find examples that were consistent with my intended design aesthetic.

Screen Shot 2016-07-14 at 3.14.32 PM

Courtesy of NPR

Compartmentalized articles: These inspirations were helpful to show how to break up stories and have a consistent design across different ideas. Since the project consists of three articles with three parts, making each story unique yet still consistent within an overall design theme will be important.

Screen Shot 2016-07-14 at 3.16.10 PM

Courtesy of Washington Post

Internal User Testing – Data Part 1

With a short timeframe due to the holiday, this week was a mix of finishing up dwindling projects and starting new ones. One project that has been consistent over the past few weeks is an internal project for the data team. The project concerns a web application for data visualizations of the company’s subscriber population. Though it is mostly the data team’s assignment, the design team was now tasked with improving the overall user experience (UX).

This internal site is written in R and uses Shiny to create a web application; R is a programming language for statistical computing and data analysis and Shiny is an open source R package that lets you create visual web applications. While our data team had taken the time to layout the application so that it was usable, they did not have the time to customize or optimize the framework. While I have never worked with R or Shiny, there is extensive documentation about customizing the appearance of the applications but that will be a challenge for another week). The task for this week was to have the application undergo usability testing to see how our internal teams use this data to find what they need to know. Usability testing is part of UX design and tests to make sure that the site is successful in letting the user achieve their goals.  

Screen Shot 2016-07-07 at 5.34.24 PM
An example Shiny application UI


The task for this project was to bring in different internal users and see how they use the site. The first step was to make sure that all potential users were being tested, so the final interview list consisted of Sales, Editorial and C-level executives. My job was to then take an example usability test script and apply it to these interviews to make sure that we were answering all the questions needed for the redesign. The challenge for these interviews was to actually conduct them and effectively follow the script. I had to cover all of the necessary questions but also draw on past interviews by bringing in new questions that people had brought up. For example, the idea of an email alert had been discussed and I needed to adjust the script so that we could see if that would be helpful for other users.


For the interviews I followed a 5 step interview process:

icons-051. Explain the purpose of the meeting – 
The key was to make sure that the user understood the product but also didn’t have too much information. If I explained too much then they wouldn’t be able to make their own assessments or judgements.

icons-012. Ask the user about his/her goals – 
I found this to be a very important part of the process because it brought to light new requirements. While I had a general idea of user goals, their answers always had a few things I hadn’t considered.

icons-023. Find out how the user is currently trying to obtain these goals – 
This step allowed for me to understand how often the user would be using the system and which pieces needed to be more easily accessible if they were used frequently.

icons-034. Test UI of tool – 
Testing the UI tool was the meat of the interview. It showed how the user currently uses the tool and where they run into problems. It also allowed for the interviewee to critique the currently layout and verbalize their thought process when using the interface.

icons-045. Find out if anyone else should be interviewed – 
This question helped with defining the users to be tested and let me know who they thought might have a different take on the application.


While there are still a few more interviews to go, each interview so far has brought to light new issues and goals. The next step after user interviews is determining the requirements for the new design and prioritizing each requirement as needed. After that it is to start either mocking up pages, if the changes are dramatic, or start implementing the actual adjustments.

As for the interviews so far, some large takeaways include:

  • Minimizing the graph sizes because users want data first and foremost.
  • Summary statistics can be more powerful than all of the data at once.
  • Some features may seem intuitive, but without direction details can be overlooked.

Mobile Application Sprints

Leading up to the Fourth of July in Washington DC, energy was high throughout the city. While the design team was mainly focused on timely issues, we were also looking ahead to design a new mobile application.I came on board during the middle of the process, after they had discussed initial requirements and created very rough wireframes, but there were still a few more steps to get through. The first was to create high fidelity mockups to use when pitching the new application to the founders. Our process for making these mockups was to have two applications sprints: one for the on-boarding process and one for a potential newsfeed design.

Having interned at a creative company before, I had heard the terms used in agile development like “sprint” and “scrum” but I hadn’t done sprints exactly like these. Generally, a sprint requires that a specific task be completed and ready to review in a short amount of time. How our sprint worked was to define specific design requirements and then have each creative member design a possible mockup in a short set timeframe. Important resources I used for this process were Keynote, Appealing and Mobile Patterns. Keynote was used for the actual creation of the mockups and, having never owned a Mac, this was my first time using it. The difference between Keynote and PowerPoint (and the reason it was our program of choice) is the magic move feature. This allows you to animate the mockup to mimic how the transitions would look after development. Appealing was used as inspiration for these animations because it provided examples of transitions that people have used in design. Mobile Patterns was used for general inspiration concerning mockup design to show the different ways common mobile app features have been designed.

Screen Shot 2016-06-30 at 5.20.43 PM
Screenshot of Appealing – Used for transition inspiration


There were two different app sprints that we went through for design development. The first was the on-boarding process which involved how to create an account and create a personalized news feed. The second was to design the actual news feed with filter options. For both of these sprints, we were given only an hour and a half to create the mockups from scratch. The only thing we were provided with ahead of time were styled buttons, form elements and Android/iOS standard features. The limited time frame would be the biggest challenge, but learning how to use Keynote magic move and creating clean designs quickly would also be tough.


My process for these two sprints varied slightly as I learned from the first one and made changes to my process for the second. I realized after my first try that I should have looked at more inspiration for the animations and mockups. My first sprint design was very standard and did not push the envelope in terms of design and aesthetics. I also learned that I should go for quality over quantity. I tried to achieve all of the requirements in the first sprint rather than doing a bit less and having better looking designs. When designing, I also had a tendency to get caught up in insignificant details which is not ideal when working on a very short deadline. For my second sprint, I took more time looking at inspiration and made sure that each slide looked well formatted before moving onto the next. I also cut out the features that could be designed later. The biggest challenge for the second sprint was conceptualizing how the sorting and filtering features would work for the news feed.


Overall both of my sprint mockups were helpful for the team in deciding where we wanted to go with the designs. Small things like including a “skip” button or a “select all” feature are the key take-aways we were hoping to find from these sprints. While the actual app will not look like my designs, it will borrow from their ideas and the challenges they overcome.

Sprint #1

Sprint #2

Implementing Email Design

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:

  1. Phase two of the email design
  2. Newsfeed mockups
  3. 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.

Screen Shot 2016-06-23 at 11.24.38 AM
Example of Email on Acid Output


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.

Screen Shot 2016-06-23 at 11.51.41 AM

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.

Screen Shot 2016-06-23 at 11.51.47 AM

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.

Screen Shot 2016-06-23 at 12.04.36 PM

Final Design

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.




Intro to Email Design

As the end of week three approaches, the office has been abuzz with happy hours, Nationals games, and multiple projects at work. One topic I have been focusing on has been email design. For front-end designers, email design is typically received with groans and reluctance. There are two main challenges that cause this negative response:

  1. You have to throw out all conventional training in design and go back to using tables.
  2. You have to adapt your code to an endless number of email clients.

E-mail design isn’t as thoroughly researched as typical design standards so solutions are harder to find.  However, there are three main resources that have helped me along in this process. The first is Campaign Monitor. Their extensive blog covers a wide array of topics and suggests tips not only in design but also marketing. They also have a Guide to CSS which illustrates which elements each email client supports. Litmus is my second resource which also maintains a blog that discusses helpful tips and all things email. The last resource is Really Good Emails,a site that compiles a list of well-designed emails. Overall these resources have been enough to help me get through the initial design stage of email development.

Screen Shot 2016-06-15 at 4.50.48 PM
Screenshot from Really Good Emails


My task following the introductory email design meeting was to take an already existing email design and re-imagine it. The email needed to be optimized because it is repeatedly used but the design does not significantly change between sends. This repetition results in a lower open rate and less active subscribers. The goal was to design an email template that can be easily adjusted by the sales team to look significantly different so as to appeal to the user every time.


The first step I took was to look at the current email template and evaluate what could easily be improved. I had a few specific critiques that I developed into questions to answer with the new design.

Current Email Template
  1. The top header banner detailing was getting lost. How can I better include a header? One option might be to reduce the size and put a larger emphasis on content.
  2. The well-designed pdf that the email blasts are selling is not being incorporated in the design. What is a way to highlight the visually appealing product?
  3. There is no call-to-action at the top of the email and instead the user has to scroll to the bottom. Where can I position the call-to-action so that it immediately catches attention?


Using my analysis of the current design, I produced three sketches. 

Concept #1

This concept enlarged and highlighted the iPad mockup displaying the product so it was at the front of the design. It also included full width color banners to allow for easy design changes for each send.


Concept #2

The second concept included a second call-to-action button so there was one on both the top and bottom of the email. This concept was the most similar to the first design but it allowed for easier manipulation.


Concept #3

In this concept I modularized the design through containers so that the email has easily defined sections. This concept can be dramatically changed as the entire background color for the whole email can be altered.


All three of these concepts can be modified by the sales employee by either changing the color in the sections or replacing the image. By leaving the entire color scheme variable for each send, the email will stand out more to the readers and not get lost or considered repeat content. The next step with this process will be to take one or two of the designs and mock them up in code.

Week #1 | Automation and A/B Testing

As I finish up my second week at Industry Dive, I realize I’ve already been exposed to so many different concepts. In general, these ideas have been centered on automation and A/B testing. I have little experience with both of these topics, because my previous projects were smaller in scope. I have been introduced to automation through tools like Grunt and GitHub, which clean up my workflow and allow me to be more efficient. Other projects in the office implementing automation include ad design and newsletter image creation. As for A/B testing, I had the chance to work directly on a project for the news articles that would be tested using real site visitors. We used Visual Website Optimizer (VWO) to create the A/B test, and I learned about the features it offers — the coolest being a heat map of user clicks. For this project, I was in charge of designing and coding an inline newsletter sign-up section for news stories. This would then be A/B tested to determine the design that leads to more customer conversions.


My task was to design an inline call-to-action that flowed well with the articles and did not disrupt the reader. The goal was to create even more leads on user sign-ups for the site’s daily newsletter. The main challenge was making the section stand out in the middle of the story without distracting or annoying the reader. Along with this, if it were too similar to advertisements in the right-rail then the reader would instinctively pass over it.


The first step was to gather different examples across publications and see which were working and how they could be improved. I found three publications using similar strategies to what we wanted to implement: The Washington Post, CNBC and The New York Times. All three used slightly different tactics. The New York Times used a call-out box on the side. This solved the issue concerning breaking up the story, but it could be easily missed while reading. CNBC used a more graphic approach and incorporated an image. While a full picture may be distracting, this concept converts well to possibly using an icon. Lastly was The Washington Post, which used a clean, horizontal approach that flowed well but could be easily lost as it was very understated.


After playing around with different designs and hierarchy, I came up with three designs. Each one was modeled after a different example seen on the web but was adjusted where necessary to be more effective. The most challenging part of the design was finding the proper sizes for the text and button. For example, my instinct was to create a large call-to-action button, but this came off as distracting rather than effective. The first design was chosen to be A/B tested. The test includes three test variables: two with the design but different copy and then the control with no new inline text. It will take at least a week before we can analyze the results.

From these first two weeks, I have learned the importance of looking at competitors and evaluating their tactics and using them as inspiration. I also learned the effectiveness of A/B testing and how user interaction is the best way to see if something is working. Moving forward, I hope to keep learning how to use automation and get more comfortable with Github to be more productive.

Design #1

Screen Shot 2016-06-08 at 10.21.53 AM

Design #2

Screen Shot 2016-06-08 at 10.23.28 AM

Design #3

Screen Shot 2016-06-08 at 10.34.32 AM