Blens Shoot. Blend. Remix.

Collaborative art making for everyone,
directly at your fingertips.

Stay up to date with Blens at


Blens is an iOS app that connects friends and strangers from around the world through the digital equivalent of a film swap.

The act of blending photos allows us to discover intersections and juxtapositions across moments in our lives. The app experience removes a level of control from users by hiding their photos from each other until the collaboration is complete. Blens thus creates a sense of surprise in the act of superimposing unexpected images.

Home Icon

Your Feed

Check out the latest collaborations by the people you follow, as well as curated feed of particularly amazing images from the Blens community.

Capture Icon


Take photos directly or choose images from your library. Pick one of the stunning filters to apply to the images in your set.

My Profile Icon

Your Profile

See your past collaborations and jump into your active ones. Manage the sets you have yet to finish and upload to the cloud.


The Origin Story

A number of years ago, sometime around 2003, I used to be part of a small online creative community which was comprised of print designers, early web designers, photographers, copywriters. This was well before your cellphone could run apps more advanced than Snake and before it could take pictures bigger than a megapixel. Nearly every year in the community there was an activity called "The Film Swap." A film swap was the very analog process wherein individuals collaborated to create superimposed images by both taking pictures on one roll of film. Part of the draw to the activity was that much of the individualistic control we were used to in digital photography was removed, and a good measure of surprise was added.

35mm Film

The mechanics of this film swap were pretty straightforward: you shoot a roll of film, rewind it, and send it to a friend. They load it into their camera and take pictures on the same roll, thereby creating double exposures. The individual receiving a roll of pre-shot film did not know what images existed on that particular roll of film. Everything about the latent images would be unknown: subject matter, lighting, pacing, etc. The uncertain elements of the process were where the magic really came from. Receiving the roll from your partner. Taking pictures and wondering what might lie beneath that particular frame. The delayed surprise in developing a finished roll. Seeing the fusion of imagery from disparate cities—and countries, as was sometimes the case—was all very exciting in the happenstance nature of how the two component images that make up each frame intermingled.

Best Practice #1 Begin, the rest is easy.

Many times I found that the hardest part of a new project is just simply starting. This is especially true when I’m trying something new. But objectively, what’s the worst that can happen?

Just jump in. Explore. Go after the low-hanging fruit and see where you end up.

Best Practice #2 You don’t have to do everything yourself.

Big projects are daunting, especially when there are components and skills not in your wheelhouse. It’s very infrequent that things like books, products, apps, or services are created and run by single individuals.

Reach out to friends and find collaborators. They can help you learn new skills while also helping to make your final output that much better.

An example that sticks out in my memory is one particular collaboration in which one individual had shot evening urban street scenes (brick boulevards, classic motorcycles, closeups of signage) and their partner had taken photos at a carnival (bright lights from rides and games, fireworks). There was something wonderful about the interplay of lively carnival color on top of gritty urban gloom.

Blens Collaborations

Fast-forward to a few years ago: I had since left that creative community, and I’d begun to pursue creating my own products for people to use. I had gotten a small taste of creating apps for the iPhone and of course my vision and ambition being greater than my skill, I started to dream up all sorts of apps that I thought might be really fun to use, and ideally turn a profit. I thought back to that online community’s film swap, and I thought I could transform that analog, time-consuming, and somewhat expensive process into an app. I imagined I could make the process cheaper and faster and yet still get that je ne sais quoi result in the end.

How could I capture that magic in an app?

How could I make this app a pleasure to use, something that wouldn't be a flash in the pan, something that people would want to come back to again and again? I sketched out the objectives for the app, a rough list of the views I knew I'd need, and, because I couldn't help myself, a few interfaces ideas. After sketching only a few pages, I had to turn my attention to my day job and more important activities, and the time I could devote to the pursuit of this project dried up.

Best Practice #3 Uncover a need and then solve for it.

Finding an idea to turn into a compelling product can be difficult. Look for unmet needs in niche groups or the general population.

Uncovering needs lead to new opportunities, which will in turn lead you to concepts.

Best Practice #4 Minimum Viable Product

It’s better to launch a well-designed simple app and then introduce new features over time than it is to release a half-baked complex app.

Creating an MVP allows you to test the validity of your solution before investing too much time.

From Idea to Development

Once in graduate school, I had the opportunity to revisit old ideas from my sketchbooks. I had time to invest in a big self-directed project, and I decided that this double-exposure app would be that project.

I set forth with the following in mind:

  • Facilitate collaboration.
  • Narratives told through images would be more powerful than single moments.
  • Let users establish the boundaries of their social networks, but blur the edges a bit.
Identifying a Market

I sought out articles and blogs on the topic of developing services, creating new products, and product design in general. This reading, plus experiences in several of our workshops, all revolved around the same advice: develop your product for an identified market. That is to say, identify a need, figure out the type of person your product will solve this need for, and then design a solution. I knew I wanted to operating in a segment of the market of collaborative tools, as opposed to tools that have no social relevance (this describes most photography and image-processing apps). Additionally, I wanted to target creative, art-making users, and lean away from the kind of user that is primarily interested in sharing selfies, photos of what they're eating, and snaps of their pet.

Finding a Name

Directly after I started graduate school, a competitor launched an app with similar intent as the one I was creating. The name they had launched with was much too close for comfort to the tentative product name I had written on the tops of the few pages of notes and sketches I had at that point. Thus the search was on for a name I could own.

It turns out that this is much easier said than done.

Beginning of the name search.

The name needed to be snappy but not imply "snaps" (low-value, quick pictures). It needed to imply melding, layering, synthesis, or swapping. It ideally needed to imply that the app was image-focused and social. And the kicker: it needed to be short, memorable, not trademarked, and something I could get the domain name for.

I started with five main words: Film, Swap, Double, Exposure, Chance. I went through the dictionary and thesaurus and wrote down every word I could find that was a synonym or tangentially related, and then I looked at related words for each of those. Nothing really struck a chord, and the names that did were either already products or were too long to be considered viable product names. I considered but rejected the following names: Mixie, Mixposure, Chromagratic, Kismet, Happensnap, Twindle, Lume, and Stratum, among others.

Weeks into the project, I still lacked an identity for my app, which meant I could not start the design work: an unfortunate position for a designer to be in. In a session with our writing professor David Barringer, the word blends was thrown about—and then lightning struck: remove the "d," and you have a portmanteau of blend and lens. Angels sang, balloons and confetti fell, and I finally had the name I was searching for: Blens.

Best Practice #5 Research, design, critique, refine, and repeat.

Through an iterative design cycle consisting of investigation, design sprints, introspection, and modification, you can hone in on and refine your solution. Everything in your product should have gone through this process several times over.

Best Practice #6 Don’t reinvent the wheel.

Human-interface guidelines, design patterns, and general conventions largely exist because they work. There’s no reason to spend a lot of time coming up with new navigation and interaction paradigms for the sake of being different.

Start by going down a trail already cleared to get a better handle on the core of your project, then blaze your own path.

Pencil, Paper, & Pixels

I had my market position identified. I had my name. I could then move onto better defining a few potential user personae to help me design for a set of diverse users with varied needs and desires. With these personae identified, I could map out how these users might achieve their goals in using Blens. Do they want to actively participate in collaborative art making or just take on the role of passive observer? Do they want to capture images or just choose images from their library to upload? Do they want to seed the system with fresh rolls for others to shoot over, or do they want to find rolls and be the second half of the collaboration?

I started to write out a list of views and their purposes that would have be navigated in order to achieve these tasks. Eventually, a crude flowchart-style map of the app appeared. Redundancy abounded, and the proposed navigation was too complex. But after some purposeful distillation—and a bit of fat trimming—the wireframe solidified.

Early Wireframe
Early iteration of the wireframe.

In the wireframing process, I sketched each screen, and the visuals started to take shape. Would this information be better in a list or in a grid? Does this button live in the navigation bar or elsewhere in the screen? Should [bar] appear under [foo], or should it exist on its own view? Would a specific action trigger a push transition or a modal transition?

To facilitate speedier iteration, I moved to the computer and created a set of low-fidelity, black and white interface components to act as placeholders. Images were represented by boxes with lines crossing in the middle, text was represented by heavy lines, and iconography was reduced to simple geometric shapes. Different fill colors of white, black, and shades of gray allowed me to indicate different content or button states. Through this process, I could quickly lay out screens without getting too absorbed in the design details. I arranged these simple screens on the canvas as visual representation of the earlier text-based flowchart and added arrows that indicated parent/child relationships and actions the user might take.

I may not have known it at the moment, but the process of defining user personae, creating user flows, and doing low-fidelity wireframing was absolutely crucial and really the foundation on which this project was built.

Best Practice #7 Give your users autonomy.

Let your users make choices in how they want to use your product or service. Don’t place every user into the same user persona, forcing them to use your product in one specific way that you have defined.

Give both active and passive participants ways to interact with the product, but also with each other.

Best Practice #8 Keep it consistent.

Visual consistency is key to an effective interface. Menus, buttons, typography, color, and transitions should all look and behave similarly throughout your whole product, unless there is a special reason for it to break the pattern.

Users rely on consistency and predictability to understand how to interact with your product from view to view.


Before this project, I had a bit of experience in programming for for iOS, and while some of the basic interaction elements just work "out of the box," there is still a lot of code that goes into making even some of the simplest interactions work. Even just setting up and styling the interface exactly how you want it can take an inordinate amount of time, and if you want to tweak anything later, you will spend a lot of time rewriting code. Prototyping is not only necessary to get a better feel for your application, but it will save you (or your engineers) countless hours writing code. When you can visually demonstrate in motion how a particular interaction should happen, the path to implementation becomes much clearer.

Eventually I moved from simple boxes representing my interface to actually creating a whole coherent visual language system. Eventually, though, I was just spinning my wheels. A lot of the "realness" of the interactions inherent in using an app wasn't coming through, I need more than static representations. I needed to create dynamic prototypes to get a sense of what it would be like to interact with the app. In came the following tools: Quartz Composer and Form.

Both Quartz Composer and Form are visual, patch-based prototyping tools in which "patches" represent various resources, numbers, actions, processes, and you connect outputs from one to inputs on another. These programs allowed me to test my designs under conditions of actual interaction, but even more importantly, I could change a few numbers or inputs/output connections and have very different interactive experiences.

Prototyping Tools
Quartz Composer (left) and Form (right).

Initially, beginning to prototype was stressful because I felt that I wasn't making much progress while trying to figure out these new applications. They were just so different than most of the software in my day-to-day that getting them to do what I wanted was troublesome. Once I got past that initial hurdle of learning the basics, I realized that these programs would be indispensable to the further development of Blens and would become go-to applications in my toolkit.

You can design all the screens you want and visually mockup selected or active states for a variety of your interactive elements, but nothing can replace actually scrolling, tapping, and swiping the interface and getting animated feedback for your actions.

Failure ≠ Failure

I have come to regard the collaborative aspect of Blens as a metaphor for why I did not accomplish my original goal, which was to create a working beta of the app by the beginning of the second semester. I didn’t succeed because I didn’t collaborate. I tried to do everything myself. I tried to work too far beyond my abilities, given the accelerated time frame of the project, and any app or service this size would undoubtedly have multiple individuals working on the product from both the front end and back end. The project was still successful. I learned a lot. I learned a lot about product design. I gained new technical skills. And I was able to use this project to showcase my skills for job searching after graduate school.

Best Practice #9 Research through making.

You can certainly learn a lot about techniques and best practices by doing more traditional research. Don’t underestimate the power of learning through the process of creating.

It’s when we actively begin to make that we really learn the important details and understand the nuances of the skills we employ.

Best Practice #10 Create new meaning.

Gaining new insights into ourselves or our data through a process we already do is an attractive proposition.

Try not to make something that is only efficient. Instead, find a way to transform an input, a task, a process, or an output into something with new added value for your user.


An app is not necessarily a project that easily lends itself to exhibition in a gallery setting, especially so a speculative app that is more of an exercise that focuses on the process of UI/UX in product design.

I was torn between wanting to show process work (how I created the real project) and selling the idea (what the users would be able to create). Showcasing the possibilities of results from the app would be an impactful moment to be sure, but so would showing interface and highlighting the collaborative process involved.

I decided to have a large projection of images merging to form double exposures as a visual representation of collaboration. Additionally, I developed a kiosk iPad app to show and describe the interface, plus hold an interactive simulacrum of the collaborative experience of using Blens.

Isometric Phone View

Next Steps

The exhibition is over, and I have graduated. Blens, however, will live on. The road isn’t entirely clear, but I have an idea of where I need to go. I know I still have considerable work to do on the interface and the user experience of the app. Several parts of the overall user flow need to be locked down, and I have several views to design that I had neglected. I need to find individuals—server-minded folk, mainly—to help me make Blens a reality. This search might involve a pitch deck or two and several presentations to venture-capital firms to raise funds to acquire the necessary talent. I will also search for friends to collaborate in building a fun app during our evenings and weekends.

I do not end my masters program satisfied that I put the required work in and walk away with another diploma. I end my masters program excited for the work that is still to come.

Let’s make some art together.