Designing StoriesAds.com
Thoughts and process behind designing a website from scratch
When you work in a company, things don’t always go as you want them to. Changes tend to come at times we don’t expect (or want) them to come — many times those changes being pretty radical too. Often when those changes strike, your existing schedules and plans are rendered irrelevant, sometimes even forcing you to halt on what you were working on so far. Working as part of the dev team in a startup, we’ve sort of gotten used to such changes, and we’ve grown our skills on how to deal with abrupt changes in schedules as fluently possible. Many times did we have ambitious projects that were ‘now-or-never,’ meaning that if we couldn’t make it by the deadline the project would lose its effect significantly.
This time it was a similar situation: a very harsh deadline, as usual. But if we could pull through, the project had the potential of giving us a significant boost in Shakr’s reach and the value we deliver.
So we took on this new challenge.
Challenge Accepted!
Mid-April, we started working on “StoriesAds.com”. It’s a microsite that focuses on showcasing our latest new vertical video designs made to be used on Instagram Stories. And the time we had for this was 2 weeks. Yes, you heard 2 weeks right! To be accurate, it was only 7 working days until the deadline that was given to us to make this project happen.
After the initial meeting where we discussed the details and schedule, we concluded that, after allocating at least 2 days for pre-launch testing, we really had just 5 days to get a website up and running from scratch. Although we did get help from various people in the team along the way, essentially only 4 people were actively involved in this project: 1 for design (that’s me!), 2 for frontend and 1 for backend and ops. Since we had no time to waste, we came up with a tight schedule with minimal dependencies, so that every person had something to work on simultaneously.
To spoil the fun: we actually did make through the insane schedule! It was a truly remarkable achievement as a team. I believe it was only possible because everyone in the team had an accurate understanding of his own and the teammates’ capabilities and limits, and thanks to the seamless collaboration skills honed by the months and years of working with each other. Personally I felt very proud for our team and accomplishment (I’m pretty sure that other teammates will agree too!) which is why I decided it would be nice to leave a written record of this milestone and the process we’ve gone through to make history happen. Unfortunately, my part in this project was just design and frontend coding so I can’t really explain about the other parts that are out of my expertise. Hopefully that will be covered in another post written by the appropriate people — but here, I want to focus primarily on the design process, the challenges we had to go through, sharing some thoughts about why we made certain decisions.
Brand Identity
Yes I know, ‘brand identity’ and ‘design language’ are not something that should be ever taken lightly. It’s what becomes the bone of all things to come, so it should be given a plenty amount of time to think through. But in this case, because we had no time to spare, I only had a single day to come up with a design we’d be using for the website and the brand.
Given the purpose and character of this project, the website would have to be a rather impactful presentation, grabbing visitors’ attention. Naturally the image that came to my mind was something bold and flashy. The reason I decided this project would have its own new design style was because the existing design language for Shakr is rather subtle.
Now then, it’s time to pick the assets that would give this ‘bold and flashy’ look.
Choosing a font
I started off right away by looking for a font family to use in this project. We use TypeKit as part of our company-wide Adobe CC subscription, so it’s a good place to head to when looking for fonts to use in a design.
The fonts I had in mind were bold and geometric, so I filtered fonts with relevant options. Font families that do have an extra-heavy weight variant almost always have a regular font weight too, but the other way around — not all fonts have a heavy weight variant. So I narrowed my way down by choosing the ones that do have a heavy weight.
Brings me down to these. I liked the single-story letter ‘a’ shape of Futura, but I thought Futura was rather too common since it’s such a famous font. (Similar to the reason why I rarely use Helvetica in production design although it’s still one of my favorite fonts.) Proxima Nova is also a great font, but I took it out of consideration because it’s also pretty commonly seen everywhere these days, especially on the web.
After testing out some candidates, I decided to go with Filson, which I felt it had a look somewhat in between the lines of Futura and Proxima Nova, with a slight touch of individuality (like the curved legs of the letter R).
I especially liked the bold and italic variants of Filson — I imagined they would be great for headers.
Choosing colors
Personally, I’m on the rather conservative side of design when it comes to trends. I wasn’t a huge fan of the recent wave where brighter and saturated colors started to take over. Trends aside though, the image we were aiming for in this project was ‘bold and flashy’ — where a color that stands out wouldn’t be too unreasonable. So I decided to challenge myself this time a bit to try out a more vibrant color scheme. After testing out a few colors, I chose a bright magenta and purple as the two main colors of my palette.
Coincidentially, (I know right?) Instagram since their redesign in 2016 has been using similar colors too, so given our target audience for StoriesAds.com, it seemed like a pretty good choice.
Design and Layout
Following decisions from the initial meeting, the website was going to be essentially a one-pager. Our simple flow for the website would be:
- User visits site, watches preview video, chooses design.
- User clicks on a call-to-action button that opens up the Shakr Video Editor.
- User finishes making video, we send the user the finished video through email.
I took these points to come up with a page layout that included the necessary elements: video preview, call-to-action button, and of course some header/subheader text that introduces the website in a glance. Because this wasn’t a full-sized project with multiple UI components and complex navigation, I thought I didn’t really need to plan out everything in detail. I skipped the wireframing step and started doing layout and visual design simultaneously. I used the good-old Illustrator that I’m comfortable working with to get the quickest results.
After several hours, I could come up with a fairly satisfactory output detailed enough that I could work with. I used a lot of rectangular blocks under the text to give them a ‘floating’ feel on top of the gradient background. While the content would be generally centered on screen, I set slight offsets to textboxes so they would add to some asymmetry to make the page more interesting.
At this point the other frontend devs had already finished initializing the repository and set up the development environment, so I could jump in right away with actual HTML and CSS markup.
UX decisions
Now, converting the design to actual code was probably the easiest part of the whole process — it took just a few hours. Because the page was rather simple, I didn’t have much trouble adding CSS overrides for narrower viewports to make it responsive. The difficult part was making some UI decisions that made more sense in terms of UX. We had to change a few parts of the page as compared to the initial draft due to various reasons, sometimes because of time constraints and/or technical limitations.
Carousel
Most noticeably, this simple website’s primary feature was going to be the preview display for the vertical videos. Since we were going to showcase a few (but not too many), I thought a simple carousel-like interface for scrolling through the different videos would fit naturally.
Initially, the interface had arrow buttons floating on either side of the phone screen frame. That would be your typical carousel UI, but we knew perfecting the UX of a carousel is very difficult and takes much effort. We learned this the hard way when we developed the banner carousel we have in Shakr.com Market main page. There’s just so many things you have to take into account to do this right: proper infinite looping, natural touch swipe interactions, animations, button placements and sizing… We had limited time for this project so we made the call not to spend too much time on just carousels.
So for the final result, we left out everything that would take too much time to implement and kept only the most important parts. We decided to take a simpler approach of clicking the screen to skip to next video, instead of arrows. Actual Instagram Stories takes single taps on screen as a skip too, so it made sense along those lines too.
However, this meant we’d be giving up the ability of directly going back to previous video, (the list is looped so you would eventually come back to the same item if you keep clicking) but I thought it was a reasonable sacrifice for the simplicity of the interface. It would have been difficult to take this approach had the number of videos we showcase been large; thankfully we had less than 10.
Not having a bullet-point list was actually beneficial in a way too because you didn’t have a set order of items they show in, we could randomly shuffle the list every time the site loads, giving an equal chance to different designs being showcased on page load for different visitors.
Modal or no modal?
Another part that didn’t make it to the final product was the ‘Confirm Modal.’ We needed some sort of way to ask the user about his/her email address to we could send the finished video. For that, initially we thought we’d have a modal that would overlay on top where we’d place the email address field. I felt having an email field visible right away on the main page may feel a bit intimidating to the visitor, so it was a clever way of hiding the input inside a secondary view.
However as we developed, we realized this posed some UX complications like the awkwardness of the user not being able to preview the video once he/she clicks on the ‘make video’ button, and a modal-on-modal situation when the editor is opened (because of the way our SDK Editor works.)
After some discussion, we came up with an alternative way to show the confirmation step along with the email input:
We liked this method because it wasn’t as obtrusive as a modal that covers up the existing view. The switch between the two contexts felt far more natural thanks to the transitioning animation. Going back and forth between confirm state and initial state felt easier because your cursor would have to travel less distance than having to close a modal.
This also naturally solved the problem of video preview, since we could keep playing the video even when the user enters the confirm view. (In normal state, the video auto-plays and automatically skips to next video when it finishes playing. When user ‘selects’ the video, we set the current displaying video to loop.)
Testing and Fixing
At this point, feature-wise, the website was complete. We successfully connected our Video Editor to the website, made a finish page that would appear when the user finishes making a video, and confirmed that the email with the download link was being properly sent.
We also made sure the website looked and worked as intended on different browsers. Chrome, Firefox and Safari had no issues, but Edge (as we had feared) had some issues with video playback, so we had to fix that.
All seemed mostly fine on desktop browsers, but mobile browsers required more attention. It hasn’t been too long since inline HTML5 video playback became possible inside a mobile browser for iOS. It was introduced less than a year ago, when iOS 10 was launched with the WebKit engine in the new version of Mobile Safari, which changed the policy regarding autoplay and inline-play.
Since everyone on the dev team was running iOS 10 (we usually upgrade within a week of a software update release) we failed to catch the fact that autoplay wouldn’t work on devices still running iOS 9.
Not being able to autoplay video meant we needed to add back manual controls for video playback. Since the most natural place for the play button to be was over the video, it meant we could no longer use the ‘tap screen to skip to next’ behavior. After a bit of thought we came up with an alternative UI for legacy browsers that shows the play button and a persistent ‘next’ button that would be used to skip to next design.
We also discovered that regardless of OS version, in-app browsers had different policies regarding inline video play and autoplay. Facebook, for example supported inline-play but not autoplay; Twitter supported neither inline-play nor autoplay. So we had to apply the ‘legacy UI’ for these browsers as well. The challenging part here was not with the implementation but more with the testing. Since you can’t type URLs directly in these browsers, we had to outsmart them by posting private posts on both services with a local IP link of the dev server, and then clicking on the link on the mobile app.
Launch
And then, after days of hard work came the deadline. For the final time we deployed our latest code to our test environment, passed the link around to everyone in the office asking them to test on their devices.
Then we pulled the switch. StoriesAds.com went live!
These were some of the challenges and reasoning behind the decisions that we went through. Note that not all of the things that we went through would apply to all cases, especially since we were so limited by time in this occasion. Time-attack driven development is definitely not what you want to encounter often as it’s difficult to maintain the quality of the project — as well as the sanity of the team members.
But with great effort comes great reward; if you manage to pull it through, you may gain valuable experience that will help you step up a level as a team. I believe that was the case for us, and I can never emphasize enough how thankful and proud I am to be part of this fantastic team.
