The power of sharing: Timehop feature design and iterations


Timehop is a platform that thrives in two things: nostalgia (looking at your old generated content across all social media platforms you have used) and sharing (letting people know how awesome or lame you are or how much you have grown).

These is a series of work and proposals I worked on as the only designer there for a while.

UI audits and figuring out a design system 

A design system is one of the few things that can be easy to pitch to any digital product out there. It offers substantial positive returns on time saving, organization and pattern consistency.

The challenge of figuring out a design system for a mobile app the size of Timehop wasn't the time that it was going to take me or the time the team needed to implement and deprecate old patterns. The challenge was selling the idea that we should halt our release schedules to allow the required maintenance the app had long been yearning for.

Beta version of the initial style guide and pattern library.

First version of current system at the time I joined.

How can we keep expanding and iterating on features when we can't even recognize where to take the first steps to start? I took on the responsibility of doing an UI audit and presenting the obvious discrepancies, pursuing the idea in product development to always accomplish the most with the minimal amount of effort. We work smarter, not harder.

The UI audit helped us find problems with the experience and inconsistencies with the patterns that we were even designing at the time. Before I had spent 90 days in the company, we already achieved a consistent design system for iOS and Android, an efficient process to support 8 different resolutions across, a revamped color system, and we had processes in place to cover for red lining and specs. This was all before I discovered Sketch and Zeplin, while also having to manage iteration of new features and releases.

Part of the audit for the Android side of the app.

Every style guide, pattern library and any basic design system always come with compromises. There were many patterns that had to run on double maintenance by development because one of them were using some sort of legacy code that we weren't ready to get rid of. So there were some places where media types displayed slightly different depending on how old or new the media type was. Feature enhancement some times took longer due to the dilemma of "doing it the right way" when many times we had limited time available, which is equals, in most cases, to crunch time.

Media types sample exploration.

At the end of the day, the recommendation is to always try and define your systems and patterns as early as possible. Do not let patterns have too many variations, just for an excuse to design more or to design something new.

Design relies more on the order and structure you display information to the user, rather than justifying having 5 different kinds of solid buttons or taking 16 hours to name all your colors uniquely.

Feature: Flipagram

Flipagram was a great small feature designed in under two weeks. The goal was to let the user create a small slideshow video to share with their friends with their pictures as the content. Ideally, the user will use images from a year or months before to showcase change, cringe or as a form of memento that can be shared with their friends.

The MVP was simple: make a selection of pictures, preview and share. 

I was able to build prototypes on what my vision was in creating the video. I defined experience logistics as in limit of pictures to select, behavior on picture selection, animation, and video preview (actual content being shared).

Prototype ready and future enhancements. 

UX Wireframe exploration.

Standardizing Photo Sharing Challenges and Proposal

Cross platform sharing presents its uniques problems when it comes to sharing images. One of the main problems regarding cross platform sharing is consistency. If you want to stay true to platform format and quality, there is a lot of design and development resources that needs to be put into it. Now once you multiply that in two mobile platforms, then it creates a bigger mess.

Part of Timehop's strength is to aggregate different platforms into a single place that is consumed in a consistent timeline. Check ins all look the same, locations all look the same, images and albums, etc... a real pleasure. The challenge comes when, considering Timehop's life circle of user's content, that same content that came into the app will leave the app. To simplify, how is Timehop going to aggregate content, let the user consume it, and then let the user share it back again to the same or different platform.

There are some questions that arise when thinking about this. If the content came from an specific platform, and now is on Timehop, does the content belong to the Timehop now? Or does the content still belong to the app where it was originally shared? What happens with content the user wants to share to a new platform, even though it came from a different one?

The answer to this is that the content actually belongs to the user. Timehop is the mediator the helps the user have the content in one place and lets the user share the content again to other places. If the user is the one in control, the user is expecting a consistent sharing experience. If the user wasn't interested in this, they would have gone to the platform's original post and share it from there, but they didn't.

One thing that we didn't have was an heavy branding presence outside of the app. While we wanted to give more flexibility to the user with the use of stickers and custom text, we still wanted to have an unified experience. My proposal would solve 3 things:

  1. Consistent branding outside of Timehop app. 
  2. Consistent media sharing across different platforms.
  3. Consistent export quality between several social media outlets.

These will give us the ability to prepare the tools for both iOS and Android that are quick and easy to maintain, while also having a strong Timehop presence sneaking through the web.

Media types as image sharing. 

Output exploration.

Assets and Proposals for prototype.

Final proposal.

Chat + Comments + Likes

One of the first projects I undertook at Timehop was the feature of allowing the user to see history of comments and likes from an old post. The idea was to simply let the user know the piece of content they are seeing has comments and likes from other friends.

We iterated on the concept of inviting friends to the media type, which will directly increase signups. However, inviting means that we had to build a notification system, backend support for cross user comments, a system to share and unshare content (since content viewed by the user is private) and a way to standardize who has access to the content from the source if the user has been tagged or added to the media type. Since we wanted increased interaction inside of the application, there were some extra exploration done to the internal chat system.

A project of this caliber only made sense with more time on our hands. We opted for the to go with the simple: The ability to read comments and likes in any post that supported it, excluding tweets replies (which is another beast on its own).

UX Exploration for information architecture, text density and chat bubbles format.

Exploration of sharing conversations with friends.

Finding content with comments, expanding content and viewing comments and likes.

Final simplified likes and comments view.