ТОП30 любимых фильмов

Kirill Zakharov

Kirill Zakharov

July 12, 2016

Over the past few months we've written about a number of new features on Unsplash. Things like our API and Collections.

And while it's great to get an in-depth look at the why behind building some of these features, a question I get a lot is how do you decide what feature to build next?

And once you do, how do you go about actually building it?

Today, I wanted to quickly run through the process of how we take a new Unsplash feature from idea to execution, using our Collections feature as an example.

Step 1: Defining the basic flow

Every new feature that we roll out on Unsplash starts as an idea (kept as a backlog in our Trello board).


Unsplash Product Trello board

While some of them come from us, a lot are actually born from requests from our community. (It's all about giving the people what they want!)

Smaller features are grabbed by whoever's available and are released fairly quickly, while bigger ones tend to go through a series of discussions before we even get our hands dirty.

Once we've decided on a feature to build, we have a product designer (myself) mock up a few possible flows—either on paper or as a quick wireframe in Illustrator/Sketch.

This can be one of the trickiest parts of the process since it requires the most thinking. There are always a few questions we need answered, such as:

  • Where does the feature start?
  • Where does the feature end?
  • Are there any dependencies?
  • Are there any blockers?

Here's a look at the first draft of the collections flow.

Rough draft of the collections information architecture

At a quick glance you can see that the main end points have been defined: where the flow starts, ends, or gets blocked. Essentially, I work my way through the flow and make sure it makes sense. It's almost inevitable that more questions will arise once the flow has been more of less defined, which is a recurring part of the design process.

Step 2: Crafting the visual design

As soon as I feel confident about our flow, I hop into the visual design stage of the feature.

This is where I spend time in Sketch and mockup the 'dream' version of the feature. I try my best not to think of development limitations and simply explore and experiment.

The idea here is to let your imagination go wild and come up with as many iterations as possible.

Most of the time the feature will be based off elements from an existing design (pulled out from our style guide template). If it's a completely new feature, I'll design it from scratch and include it into our master template once shipped. In the case of collections, new elements had to be created.

Unsplash master Sketch file

Eventually, one path usually stands out and as soon as I’m more or less happy with the direction, I'll have some back-and-forths with my teammates and discuss what works and what doesn’t.

Often times, the first solution is usually the one you come back to and iterate on.

For this stage of the process Redpen is my go-to app for quick single-page feedback: drop the design, add some annotations, and share link with your teammates.

Step 3: Building an interactive prototype

Now it's time to get an idea of how the flow, design and user-experience will behave in the real world.

This is where I put my designs together into an interactive prototype platform—InVision for complex flows and Marvel for shorter ones.

Original Unsplash collections flow in Marvel

At this point I like to get feedback from an outside party (someone outside of our team) to see if there's something I'm missing from being too close to the project.

It's easy to get tunnel vision when you've been working so intently on one thing, and there's nothing more enlightening (and sometimes frustrating) than hearing an outsider say 'this doesn't make sense'.

With all that feedback in mind, I mock up the final flow and drop it all in one final prototype that will act as the main reference point moving forward.

Step 4: The development phase(s)

Now that we know what our feature looks like and how it's going to work, it's time to dive into our text editors.

(It's also important to note that in some cases, the backend development team is a step ahead of me and has already been working on putting together the structure of the feature and/or API endpoints).


Unsplash collections: early GitHub commits

We usually split development and roll-outs into different milestones, or, as we like to call them internally, phases.

Each phase brings us a step closer to the final version of the feature.

In the case of collections, each phase brought us closer to having the feature fully rolled-out to the public and made available to everyone on Unsplash.

Here's an idea of how the development of Collections went down:

Phase 1: Getting the content ready

While the front-end team focuses on building out the design components, the backend team pulls out existing data and makes it available in our API.

Pre-collections, Unsplash still had 'collections' (you can read more about that here), but they weren't accessible. So our first step was to take all of this content—past curated batches of photos, collections made by our team—and make them accessible.

Early Unsplash collections. Also known as batches.

Once this phase is ready and we're happy with the experience, we rolled it out to the public so users could browse existing collections and see who curated them.

As a user, this is where you start hearing about collections for the first time.

Unsplash collections populated in a list

Phase 2: Test how it will work internally

Every feature on Unsplash is first heavily tested internally.

So in this phase, we developed an internal interface for admins that allowed them to create collections, browse photos, and add them to existing collections.

This interface is usually almost identical to the user-facing interface, but with a few extra features.

Playing around with this flow it helps us to see what works and what doesn’t and be able to iterate on that. The admin interface is rough and far from being polished (missing most animations, loading states, empty states, etc.) but the idea is to get it working.

Here's the first version of the add-to-collection modal designed by our backend developer Charles.

It’s buggy, but it works. Sweet.

Towards the end of phase 2, we’ll slowly polish up the UI and start focusing on the subtle animations and transitions.

And on the public side of things, we'll ramp up awareness of the feature by doing things like rolling out collections that we’ve created internally. All of a sudden you see collections created by Unsplash and our close friends pop up on /collections.


First collections by the Unsplash team and friends

In this stage, the team is up and running full speed and opening/closing pull requests and issues on Github. Most bugs are usually crushed before they’re spotted by the public.

Phase 3: UI optimization (aka make it pretty for the people)

In this phase we focus heavily on UI optimization in preparation for a soft launch.

You’re now able to request early access to collections and some power users are helping to populate the collection list with some user-created collections.

Think of this as the 'Collections Beta' phase. We take all the feedback we can and fix most major bugs. At this point our Early Access list has grown to a few thousand people. We slowly start rolling out collections to the public.

Phases 4, 5, 6...

At this point the feature is live, bugs are spotted and fixed, and we're happy to start heavily promoting it.

But it's still in its infant stage.

This is where we go back to that initial spec and see what's missing from our 'dream' version of the feature. Usually over the course of actually building the feature more and more of these 'dream' elements become clear.

Building and testing is the best way to get ideas.

And while these might not always get done (some get put on ice, some are blocked by unreleased features, some might get killed off as the product evolves and never make it to public) just knowing that you can take something further than the basics is an important part of how we see features at Unsplash.


Final rolled out version of the add-to-collection experience

Adding new features is always a bit of a risk. Especially for something like Unsplash, which is known for its simplicity and minimalist design.

So every time we add a new feature we need to make sure that it's not just a nice to have, but is something we know our users want and will make the experience of using Unsplash that much better. At the core of our process is always the user. What they want. What we could make better for them. And what will make them happier Unsplashers.

I hope you enjoyed reading about our process. It’s not perfect, but it works for us.

We’re currently looking for awesome folks to join our team and help us build the next features on Unsplash, so if you're interested please get in touch!

And if you have any questions, comments or want to chat anything-design, feel free to hit me up on Twitter.