Travel Photography Made Easy
Have you ever wanted to take better photos of the cool places you’ve seen while on vacation? vantagept is a travel photography sharing application that gives real examples of how you can take better photos on your next trip.
Your Typical Uninspiring Shot
A Much Better Shot
Don’t Know Where to Find a Good Vantage Point
We often don’t know what we’re capable of seeing and capturing on our cameras because we’re not standing at the right place or it’s not the right time of day.
I was the sole designer responsible for the project from concept to prototype.
My design process started with user research where I learn about my potential users’ needs and motivations through interviews and surveys.
Next, I generated feature ideas, examined the competitive landscape, and refined the scope of the project.
Finally, I spent the bulk of my time iterating and validating the design.
Onboarding, Searching, and Sharing
Create an Account or Start Exploring Immediately
I wanted to keep the onboarding as simple as possible and even allow the user to skip the creation of an account so they can get a taste of what the application offers before they commit.
Search for Photos on a Map and Pin Them to Your Board
To demonstrate how a user would search for photos and pin them to a Board, let’s assume this person is looking for inspiration for his/her upcoming Iceland trip.
Show Off Your Exceptional Photos and Help Aspiring Photographers Learn How to Take Better Photos
Let’s assume a first time user wants to share a picture that he/she took in Italy. The image has most of its EXIF metadata intact but does not contain geolocation information. During the upload, the system will prompt the user to pin the photo to a map so it can be more discoverable.
What Can I Learn About Photographers and Travellers?
The inspiration for vantagept came from a personal desire to become a better landscape photographer while on vacation. To appeal to a broader audience than myself, I needed to learn the needs and motivations of other photographers and travellers.
From the ten interviews I conducted and 11 survey results I received, I consolidated my findings into the following three personas and insights about the problems I could help solve.
Alex – the Hobbyist
Behaviours and Goals:
- Research locations in advance of travelling to determine where to visit
- Document travel memories
- Capture impressive photos to “wow” family and friends and satisfy own ego
- Learn how to take better photos
- Open to sharing learnings and techniques with others
- No intention of selling photos
Taylor – the Professional
Behaviours and Goals:
- Find inspiration for an upcoming project
- Spend hours and days scouting for interesting locations to capture
- Get exposure as a leading professional
- Get paid for photos
Sam – the Casual
Behaviours and Goals:
- Take photos while travelling to document for self and share with family and friends
- Capture interesting things while out and about
Problems I Could Attempt to Solve
- Unable to find the right angle to take a pleasing photo
- Unable and unsure how to capture what the eye sees
- Unsure how to capture scenes with fog, low light or other weather conditions
- Struggle to find an impressive shot that’s different than classic shot of iconic place
- Many current photo apps do not auto-categorize photos
Problems Beyond Scope
- Not having the right equipment on hand: wide-angle lens, wide-aperture lens, tripod, etc.
- Unforeseen and changing weather conditions
Job Stories & Potential Features
What Should I Design?
I came up with a set of job stories based on the interviews and survey responses from the user research. Each job story converted into a feature.
JOB STORY: When I go on my next vacation, I want to find good vantage points to take photos from so I can have beautiful and impressive images to remember my trip and share with my family and friends.
⇢ FEATURE: Search for photos by geography
JOB STORY: When I am in an unfamiliar location, I want to know interesting sites or better vantage points nearby so I can conveniently discover and capture more compelling photos.
⇢ FEATURE: Search for photos taken nearby using the mobile device’s location services
JOB STORY: When I upload a photo, I want critiques from fellow photographers so I can improve my skills.
⇢ FEATURE: Request for photo critique
JOB STORY: When I see something interesting, I want to know what camera settings to use so I can compose and capture scenes accurately.
⇢ FEATURE: Extract and display EXIF metadata from photos
JOB STORY: When I go on my next vacation, I want to know what equipment to bring so I can adequately capture the places I want to remember.
⇢ FEATURE: Collect extra metadata about photo not available in EXIF
JOB STORY: When I see a photograph I am inspired by but don’t know how to capture, I want to reach out to the photographer so I can ask them about it.
⇢ FEATURE: Messaging
Features in teal-coloured text were the ones I focused on designing.
No Mobile Photo Searching on a Map
Now that I understood my users better, I needed to understand the competitive landscape of photo sharing and travel applications. What I found was that no one was offering a mobile photography application that used a map interface.
Google Maps has a lot of poor quality photos to filter through, and one can’t see the photo’s EXIF metadata. Google Maps’ mobile application doesn’t have a photo layer which eliminates mobile use for location-based photo search.
Flickr has a better selection of quality pictures, but not all of the photos have EXIF metadata nor geo-coordinates. Their mobile application doesn’t have a map interface either.
500px has beautiful photos, but its purpose is to help photographers sell their work, so EXIF metadata is not always available. Their photos are also not pinned to a map.
Instagram has a lot of photos, some good and some poor quality, tagged by keywords but all the photos don’t have EXIF metadata nor geo-coordinates.
Airbnb does not focus on photo sharing; however, it does have an excellent user experience for travellers and its mobile application uses a map interface well.
Responsive Web App vs. Native Mobile App
The user research indicated that having access to the application while on-location is critical. In the ideal world, there would be a responsive web application for ease of uploading from a laptop/desktop and a native mobile application for on-the-go access.
However, time was a limiting factor in this project (and in most real world projects), so I had to decide which option to design first.
I proceeded with a native iOS application for the following reasons:
- A native application doesn’t always have to use an internet connection. Some content can be saved offline which is useful when travelling because of high data roaming charges.
- The user flow and experience of a native app is much smoother than a responsive web application.
- iOS over Android because I would only be designing for one operating system for now. In the real world, one team would rarely design and build for both operating systems concurrently. It made sense to select the operating system I was most familiar with.
Now to start fleshing out how the application will look and function!
vantagept’s Design Iterations
I went through each of the following steps to come up with the final design. However, it definitely wasn’t a linear progression. During user validation at the wireframe and mockup stages, I had to re-think the information architecture and the user flows again.
1. Information Architecture
How Should the Content be Organised and Consumed?
I wanted to focus on the two primary uses of this application:
- Contributing a photo to the community (aka, uploading a photo).
- Searching for inspirational photos and saving ideas for a future trip.
The user flows shown here were my original hypothesis at how the main user tasks should work.
From Rough Sketches to Medium Fidelity Prototypes
Now that I had a sense of how my users would undertake their tasks, I started to sketch out the user flows.
Rough Notebook Sketches
I started with sketches in a notebook to quickly dump UI ideas from my head.
Next, I created paper prototypes to iterate on the user flows by walking through them with potential users and making modifications on the spot.
The upload user flow required careful consideration because there were multiple scenarios to account for:
- The photo has all the essential EXIF metadata including geolocation information
- The photo has EXIF metadata but does not have geolocation information
- The photo has no EXIF metadata
I wanted to run a usability test to flush out the different scenarios, so I created medium fidelity wireframes in Balsamiq and exported them as clickable PDF prototypes.
Given the limited time and budget, I ran guerrilla user tests with my peers and TAs in class.
Outcomes from User Validation
Timestamps and Timezones
I didn’t consider how timezones make the timestamp in the EXIF metadata potentially inaccurate. Consider a DSLR camera configured in Eastern time. When it takes a photo in the UK, the timestamp is 5 hours behind.
My initial solution was to ask the user what time zone their camera was configured for during the first photo upload so vantagept could auto-adjust the timestamp for photos taken with the same camera. I’m the type of photographer who never adjusts the camera’s time, nor do I adjust the photo’s timestamp after the fact, so I thought I was clever by asking for the camera’s time once. However, that didn’t account for other photographers’ behaviours.
Some keen photographers adjust their camera’s time when they travel. Others may use software to change the timestamp after they take the photo. In these scenarios, the timestamp is already accurate so an auto-adjustment based on the camera’s original time zone is not sufficient.
I spent a lot of time trying to figure out how to solve this problem. Maybe I was wasting time fussing over a small detail when I could omit the timestamp? After all, none of the major photo sharing applications showed a photo’s timestamp.
I had to go back to my personas to determine if this information was critical to show. A goal of the Hobbyist is to learn how to take better photos and find the right angle to take a pleasing shot. Thus, it’s useful to know what time of day to take a photograph because the vantage point may only be good at sunrise and not sunset and vice versa.
I settled at asking the user during onboarding whether their photos’ timestamps were already correct. Later, in testing the high fidelity mockups, I discovered that this method also didn’t work. I will discuss this issue further in that section.
Simplified Content Model
I originally had the concept of “Landmarks” and “Vantage Points” to catalogue similar photos into bins. All photos would belong to a Vantage Point, but not all Vantage Points would belong to a Landmark.
When I transferred my rough sketches from my notebook onto paper prototypes, I came to the realisation that this relationship was too complicated and merged the two concepts into one concept—Point of Interest (POI).
Walking users through the upload steps using the paper prototypes and having users click through the PDF prototypes allowed me to see that my content model needed to be further simplified.
POI was devised to allow multiple images of the same landmark to be grouped together in a map interface. This grouping can be achieved using a combination of geo-coordinates and keywords on the back-end. Thus, I removed POI from the content model and used Photos as the base object to pin to a map. As a result, the upload steps became easier, the searching and browsing became more straightforward, and the database would be simpler to build and maintain. It was a eureka moment.
Generating a Visual Identity
Designing a Logo
Mood Boards & Style Tiles
I created two mood boards and their respective style tiles to explore where the visual design.
I chose the Airy / Minimalist / Clean option after running a user preference test on UsabilityHub.
Levelling Up the Wireframes
Now that I had a visual direction, I applied the style and colours to the wireframes to create high fidelity mockups for the primary user flows. I made sure to set up my Sketch file with text styles and symbols so that I could easily swap out icons, change colours and edit font styles. The ability to make a change in one place and have it reflected everywhere was a huge time saver. Below are a few examples of the screens I created in Sketch.
Outcomes from User Validation
Timestamps and Timezones Revisited
After showing potential users my first take at the onboarding screens where I asked if their photos had correct timestamps, I learned there was too much text for my users to read and I didn’t take into account user error outside of my application. One user told me that sometimes he would forget to change his camera’s time and so his photos may not always have the correct timestamp.
I had assumed at the wireframing stage that photographer behaviours would remain constant, but now it was evident that sometimes people would forget to change their camera’s time even if they were usually diligent. Did this mean I have to ask the user to confirm the timestamp every time they upload a photo?
After discussing the alternatives with a TA, I decided that it was best to still ask for the camera’s original timezone during the onboarding process. This way, the user can auto-adjust the timestamp during the upload process (should they choose) and can manually adjust the timestamp too (should a particular situation not reflect typical behaviour).
The time zone field would auto-populate based on the phone’s local time. If the user clicked the input field to make a change, the first suggestion would be “I change my camera/photo’s time when I travel.” This option would indicate to vantagept that the user doesn’t need timestamp auto-adjustment during the upload process but may require manual adjustment.
There was a lot of meta information to display on the photo details screen. My original mockup that included a map of where the photographer took the picture was very busy. The alignment and spacing of content were also inconsistent.
Returning to the principles of establishing visual hierarchy I had to ask, “What information do my users care about and what are they accustomed to seeing?”
There was no point in breaking photo sharing layout conventions, so I placed the photographer name and profile picture, how recent the photo was uploaded, and social interactions underneath the image.
As a person searching for inspiration of photos to take on my next trip, I would want to find out where and when this photo was taken to determine if I can include it in my itinerary. I would then scan the photo’s technical specs to determine if I had the equipment. Finally, the keywords at the bottom would be a useful quick search for related photos.
Reflections & Learnings
More Time on Idea Generation
I only came up with three ideas to solving the problem and then quickly jumped into the third idea:
- Create a review platform for professional photographers or photography tour companies that offer guided travel photography experiences
- Design an app that easily allows self-guided photography tours to be created, purchased and downloaded for offline usage
- Build a photo sharing community where all photographs would contain geolocation and key EXIF metadata which would help photographers learn from each other’s work.
In hindsight, I wish I had spent more time generating different ideas and validating those ideas with as many people as possible to find the best solution.
Need to Inject More Personality
During the branding stage of vantagept, I had selected a few adjectives to describe the personality of the brand: Inspirational but not Glorifying; Informative but not Academic; Candid but not Rude; Casual but not Goofy; Friendly but not Mushy. However, I did not actively inject said personality into the design of the application.
Personality is essential to creating trust and delight. Thus, the application should have had a persona as well. In the future, I would spend more time creating a persona and establishing the voice and tone of the persona.
Better User Research & Validation
vantagept lacked the budget and time to utilise a more representative selection of potential users. Other than the initial interviews and surveys where I engaged real hobbyist and professional photographers, the rest of my users during the validation stages were all classmates and TAs.
In the real world, I would schedule enough candidates from the target market with a lot more lead time to validate the user flows and the mockups of the main tasks.
Chicken & Egg Problem
This photo sharing platform has the typical chicken & egg challenge of needing to offer content for users to join the community but also needing users to generate content. In the real world, I would likely pre-populate the database by pulling geotagged, highly rated, and publicly available photos using Flickr’s API.
My design project also does not address the business model of how to ladder up the application to get it off its feet and then to grow and sustain itself.