The Information Technology Career Foundation Program (ITCFP) had an existing newsletter that distributed updates and information to program. The content in the existing implementation was not meeting the needs of the members of the program. I revamped the content and updated the design of the newsletter.
The ITCFP needed a way to distribute information to its members regularly and cover information that may not be address in the monthly staff meeting. Information changed often between meetings and the program needs to communicate those changes. The existing implementation was not effective in accomplishing that goal.
How might we redesign the newsletter to increase awareness of the program’s activities and updates to both former and current program participants?
This initiative began by the simple need for someone to takeover the responsibilities for the newsletter publishing and distribution. When this conversation started, I began to wonder what newsletter we were even discussing. The newsletter at the time was so ineffective for me personally that I was unaware of its existence. I hypothesized that I was not the only one.
Seeing an opportunity to make the newsletter not only informative, but something that participants would be excited to receive, I volunteered to take on the project with the caveat that I was not going to keep up the status quo. I wanted to see what others’ opinions were on the subject so I set up some User Interviews to see how we might be able to improve this product.
I created a script and set up some time with current and former members of the program to get out of my own head.
Questions that were included:
After 10 interviews we were able to synthesis the findings to some key takeaway:
Now that I knew what the people receiving the newsletter wanted to see in their inbox, we came up with the idea to have 4 major sections of the emails. We then decided to set it up to be sent bi-weekly so that the time between staff meetings would not lack updates. Because of this bi-weekly nature, we knew it would get overwhelming if there was too much information. We settled on giving small headline-type updates in 4 different sections with the ability for participants to read more if they chose to. This would allow for users to read about the things they were interested in without having to sift through so much to get there.
The sections that we decided needed to be covered were:
Program Updates
This was the most important section. Information that needed to be distributed to the members of the program needed to go in this section so that even if the newsletter was just skimmed, this section had the highest likelihood of being read. The section would include messages from the Program Leadership at the top, followed by updates from each of the Committee Leads.
Events
The program holds many events, whether they be social, developmental, informational or anything else. Participants wanted to be able to quickly glance at what is coming up for them in the next two weeks. Some of the user interviews brought up that they would like to see more pictures from events in the newsletter. They saw this as a fun way to see into how the program was operating at other sites.
Blog
This stemmed from the desire for others to see into what different participants were working on. This helped support another initiative to increase engagement with the blog by providing a quick link to the most recently published blog articles.
Spotlight
Along similar lines of providing a closer look into the personal work of other members, we wanted to utilize this section to honor the accomplishments and lives of our members.
From there I was able to sketch up a design:
To help visualize it better, I created a mockup in Sketch:
I was happy with the design and started to think about how we would be able to get it into an outlook email. Upon further investigation, I found out that Outlook does not allow you to simply send HTML in an email (at least the version we were using at my company).
At this point, I had a decision to make. I could simply compile a PDF to be sent out each month. This would be a pretty simple solution and would be easy to create a template that others could easily update. So I started to gather some feedback from participants to see how they would respond to that. Almost everyone said that if it was in an attachment that they had to download, they would be a lot less likely to open it and read it. Since I did not want to repeat past mistakes and create something that people ignored, it was essential to get it to display directly in an email.
After some research on Microsoft products, I had to convert the HTML to an ASPX file so that I could copy and paste the formatting from Internet Explorer (yikes) into the email. This created A LOT of formatting issues so I knew I had to simplify it.
After quite a bit of trial and error, I was able to get the following to render well in both live HTML as well as in the email:
The newsletter was almost immediately met with positive reactions. I received several emails exclaiming things like “This is the first time I have read through the whole newsletter” and “Thank you for focusing on making these updates short”.
While I have no hard data on how many times it was opened, bounce rate or anything like that (Outlook is very limiting), I can say that feedback that was being given to us was nothing short of positive. For the first time, the newsletter felt like something people wanted to read, and they were telling us that!
We soon started to send it to the alumni of the program as well to give them a snapshot into what the program is like since they have left. This expanded the audience and overwhelmed my inbox with requests to help other people come up with something similar for the various programs they were involved with now.
My biggest takeaway from this process was to not accept something the way it is if I think there could be improvements. However, just because I have a hunch doesn’t mean the users of whatever I am building agree. The process of validating my assumptions that the newsletter was not effective in its existing form through user interviews and understanding their goals was incredibly enlightening and led me down knew lines of thought that I never would have gotten without speaking with them.
This also served as a great way to educate the program on the benefits of User-Centered design. I was able to explain the process to the entire program and use it as an opportunity to show that designing with the user in mind leads to things people enjoy using.
As far as how to improve this for the future, it currently just uses a local HTML file that is updated via the code and then copy and pasted into an email. This process is not very user friendly, and while I knowhow it works (and am the one who compiles it), it is difficult to teach to others that don’t know HTML well. So, the main future improvement that can happen is a way of automating the information inputs and generating the HTML file automatically. The people who compile the newsletter are also users, after all!