oneShot

The Problem

Oneshot started after reflection on mobile photography and how the increasing features for automatization and the need to capture everything sometimes can be more predominant than the picture or the moment itself.

In this reflection, analog photography and analog processes appeared as a way to rescue the lost experience. Oneshot is an attempt to combine analog characteristics with mobile cameras to reconnect people with the experience of taking a photograph.

My role in the project

Oneshot is a personal project created between my developer-husband and me, the designer-wife.

We both acted as product owners defining the concept, goals, and features of the app. I, then, work on it as a UX Designer and UI Designer.

The Approach to the solution

We started with a contradiction about defining who our users are. On one hand, we saw ourselves as the typical Oneshot user. After all, we wanted to create this app to use it ourselves, but on the other hand, we are very aware of the "You Are Not the User" mantra by which people project their behaviors and reactions onto the users.

To resolve this, we abstract the characteristics we thought more users shared with us, and from there, we expand to similar profiles and topic related profiles. This way, we acted as users to design the app, but we have a view of other profiles and a clear need to validate these assumptions.

Ideation

We rounded this phase with an ideation session to translate the concept into an experience to overcome this situation.

Instead of having limitless possibilities, we started by putting a timer on the camera, so it would only be possible to take one photo every 3-5 minutes. We think that the pressure in only having one shot would enhance creativity.

We also wanted to remove any automatic camera presets and replaced them with analog features like obturation, having to select a film and type of lenses before taking the photo.

We also knew we didn't want to have users thinking about likes and followers. We decided to limit that by making photos anonymous and without comments. We want users to focus on pictures and not being influenced by any other parameter.

We realized that all of these features could be divided into two parts; the analog camera itself and the "instant" experimentation part.

Both aspects complement each other and are crucial for the experience we were trying to achieve. To define the MVP, we compared features against the app goals and voted out on those which were essential to reach them.

With this information, I could now start working on the wireframes to define the user's flow.

I listed every camera feature and grouped them by function, similarity, or moment of use. The aim was to present the features without overwhelming the user. I was also taking into account the full features as well as the MVP, making both user flows made sense.

I used an analog camera as a reference and separated those features that aren't easily changeable, like the film reel, or the camera lens. The experience starts with the user choosing these two setups with an option to learn more about these parameters.

Once selected, the user accesses the camera itself, where they can see the options to manipulate the camera. The traditional analog features like obturation, focus, lens, and diaphragm are grouped. At the top are the options to enable flash and sound.

At the bottom, I included a dock with all the actions regarding shooting, the shoot button, the film reel, and the option to select shot mode between normal or multiple exposures.

Once the user takes one shot, the camera isn't available again for the next 3 to 5 minutes, so the camera is replaced with a timer and also access to check the feed, learn more about photography concepts, or play with the camera presets until it became available again.

First Feedback

With this user flow materialized, we discussed the ins and outs.

About the user registration and access:

• The registration flow wasn't clear enough.
• Who can ask what?
• Ask for a login to see details?

From this feedback, it was clear we needed to define user levels better.

About the feed, we evaluate both layouts seeing that the main difference was that the masonry layout allowed us to have unlimited space to show the pic detail. We also needed to confirm if it was enough space in the portrait mode to show the detail behind the photo.

We were happy with the camera flow and the analogy with analog cameras, but we also have some new ideas to make it better:

• Include learning tutorials about photography relevant to the different features in the flow.
• Change some wording in the titles.
• The main thing we realized about the camera analogy, is that the lens in many cameras could be changed.
• We saw necessary to add the camera info selected in previous steps to the dock.
• We thought about using random values for the default camera as a way to get people playing with the presets.
• Use an entire film reel per camera before switching.

We debated about the idea that the users don't get to see the photo right after they take it, but instead, they'll have to wait until the reel is developed. We also think about removing the option to play with the camera while they wait.

I took the feedback included in the wireframes and moved to Figma to start prototyping.