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

Challenge

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.

Approach

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.

Results

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

Advertisements

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

Challenge

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.

Approach

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.

Results

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.

Playbook_email_blast

 

 

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

Challenge

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.

Approach

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-1b
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?

Results

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.

concept1-1b

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.

concept2-1

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.

concept3-1

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.

Challenge

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.

Approach

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.

Results

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