There’s a ton of meaningful content on Yik Yak. We like to share this content with the world to not only demonstrate what our communities are like, but also to model what ideal content would be on platform. When we share this content to external outlets it can be in several different settings. It can be anything from an article on a news site to an Instagram post to a screenshot on the Apple App Store.

When I first arrived at Yik Yak we were using Photoshop files to create mocks of Yaks / posts in the app. All of our design work for what lives in the app is created in Sketch so having to maintain separate Photoshop files for all of these UI components added a ton of effort to what should’ve been a simple task.

I started the process by laying out each of the key components of our app in separate pages. I made the Sketch file accessible to anyone internally allowing all internal stakeholders an easy way to create mocks. This was before the days of Sketch Libraries and other glorious updates that have made this process easier over time.

The V1 of the templates was a little hacky when it came to resizing the symbols. It basically required different versions of component that would fit with the size of the content. For example, if a user was trying to render a yak that's content spanned 3 lines, it would be a separate symbol from a yak whose content only spanned one line. This translated to a crazy amount of card permutations in the symbols list.

But the Sketch gods smiled upon us. They released fluid symbol resizing pretty shortly after I put out V1 of our templates 🙌🏼. I sent out V2 of the templates the day the update was released along with updates to the walkthrough videos. It was a good day.

Since the template could be used by anyone in the company, I wanted to account for helping out users that might be new to Sketch entirely. After all, one of the problems I was trying to solve with this whole thing was reducing my overhead when these mocks needed to be produced. If I needed to walk people through the process every time they wanted to render content it wouldn't be a huge improvement.

So, I put together 5 super quick videos that walked users through how to install the template, how to leverage the assets I packaged it with, and generally how to render and export these mocks after they made them.

I’m incredibly proud to say the templates were a success. Over the first couple of weeks I made revisions to the template based on feedback. From that point forward the templates and the walkthrough videos took care of themselves. Whenever we shipped a build that had changes to the UI, all I had to do was update the main template file, then distribute it back out to the group using it. The entire process took a fraction of the time and ensured that all content renders we sent out were in line with the latest and greatest UI elements.

The second phase was where we brought in Tag management and creation. At one point we thought we were going to split management and creation up into two separate releases. This was due in large part to API and backend work that we needed to get done before creation would be possible on the mobile application. Here’s a look at some of the early work we did and the flows / error states on iOS. In addition to clickable prototypes, I often like to lay a flow out sequentially so that the team has better context for how all the steps relate.