Transforming the way people book photoshoots

Shoot is a marketplace website for connecting photographers with customers that want to book high quality photoshoot experiences.



Technical Cofounder, Web Developer, and Product Designer at Shoot


Google Docs, Forms and Sheets

HTML, CSS, and Javascript.




August 2018 - May 2019



User Research

UI Design

Web Development

Project Management

Problem Statement
With our minimum viable product (MVP), we hypothesized that people wanted a service like Shoot and wanted to prove it.

Our research showed that booking a photographer is always a hassle and that customers didn't always know how to find the right photographer. They would either Google or ask friends and family.

Photographer websites would often not have the prices listed outright. They also did not have reviews, so customers did not know if they were making the best choice.
We launched during the Spring graduation season (March-July) of 2019. We had around 40 bookings and generated approximately $3500 in revenue.

We proved that the market wanted a product like Shoot and that it can serve even more people in more cities with the right team, tools, and funding.

It was my first time working on a digital product, while also leading the design and development. We were all based in Houston, but throughout the week we all worked remotely from wherever we felt comfortable. Less time spent traveling meant more time on developing our idea and peace of mind for all us.

We learned to use tools like Trello, Google Calendar, Google Docs and Sheets to learn how to work together. None of us had ever done anything like this before. After a few trial and errors, we were soon running like clockwork.
Roles and Responsibilities
I was the Web Developer, along with being Cofounder. After the departure of our graphics designer, I started teaching myself how to design and took over as the Product Designer.

I was also in-charge of project management, deciding which features to focus on during each sprint periods. All major decisions would involve all the team members before being added to a sprint.

Throughout the beta phase, I worked with Simbai, who was incharge of Business Development and Community. Alina joined before we were about to launch as Head of Marketing.
Users and Audience
Since Shoot was a dual-sided marketplace, our users were photographers and customers. Our customers for our beta phase were college students who are about to graduate and needed a photographer to capture their special moments.

How did we decide that?

We came to the conclusion after interviewing approximately 100 individuals of all ages, genders, and socio-economic status.

Our initial target were women early in their career. They understood what that professional photoshoots help amplify personal branding.

But we realized that with college students, we would be able to prove the viability quicker and easier. As college students, we had access to people who were similar to us.
Scopes and constraints

We had a short timeline. We decided in summer of 2018 that we would have to test the product and gather feedback before we officially launched during Spring 2019.

My technological skills were limited, so we decided to create our MVP as minimal as possible. We didn't have the funding for another developer or the time for me to learn full-stack web development.

The website ended up being entirely front-end coded with HTML, CSS, and JavaScript. It ended up being a good decision because it allowed us to focus on the value proposition and our users, and not just pack feature after feature.

The Process

User Research
Our initial research into the Houston photography market revealed that a lot of photographers did not having pricing information or any booking functionality on their website, or they didn't even have a website at all and relied only on Instagram.

With that hypothesis, we decided to identify our customers. We ended up with:
  • Women early in their career
  • College students

We started approaching our customers in coffee shops and the university student center and asked them about their photography experience, whether they even had to pay for any of it.

Competitor Research

We were able to find a few competitors that were offering a somewhat similar services in the United States and around the world, but we found out that the Houston market was unaware of them.
  • Marketed themselves as Uber for photography.
  • Seemed to be limited to just Silicon Valley.
  • Customers could not choose their own photographer.
  • Inactive social media.
  • Marketplace for booking photographers.
  • They marketed themselves as both a travel and photography service.
  • Customers could choose their own photographers
  • Also inactive social media
Creating the minimum viable product
With the information we had, we created a simple plan. We decided to focus on the Houston market; Houston photographers and college students who would be graduating in the Spring of 2019. We followed certain aspects of Scrum during the development process. We did daily standup calls and kept meeting notes.

We used Trello for project management and Google Docs for documentation. We kept a backlog of tasks, along with a to-do, doing, testing, and done list. We started with two week sprints, ending each with a retrospective where we decided what was good, what wasn't and how we could do better in the next sprint.

We looked at our available resources and started planning out exactly what needed to be built. Below is what we came up with.


  • Lists all the photographers from Houston, TX as clickable info cards.
  • Include the photographer's name and profile photo, and a portfolio photo.
  • Along with starting prices, and their specialty (graduation, couples, headshots).

Profile Page

  • Photographer's portfolio
  • 3-tier pricing packages
  • Location
  • Short bio
  • Booking button

Booking Page

  • A form and a booking button.
  • Customer name and contact information.
  • Calendar to pick the date of the photoshoot.
  • 3-tier pricing package selector.
Creating the home page
We created version 1 of the home page and we tested it out.

We made some mistakes.
Here is a screenshot from September 2018.

We thought it looked simple. You have the photographer's name, their starting price per hour/session, their specialty, and a portfolio photo.

I sketched it out and showed my team. Everyone agreed and I then coded it in HTML and CSS.

We decided to go out and test this with the users and see what they thought.

We noticed that our users had no idea what to do. They perceived the cards as Instagram posts and just kept scrolling. They didn't know that they were supposed to click the cards that it would then take them to photographer's profile. They also thought that the person in the photo IS the photographer.

We took the feedback and went back to work on our cards.
Our mistake was thinking like we are the users. Of course we didn't see anything wrong with it, we were looking at it all the time!

We added the "View Profile" button so the users know where the button is taking them and the card only provided a bit of information to entice them. We used orange for it as it was a brand color.

The photographer's name had a picture of them to go with it inside a small circle.

We tested it again with our users. It was a success. We noticed that people paid attention to the "View Profile" button and it prompted them to visit the photographer's profile. We kept improving it from there on out.

and dating
Because it was easy to replicate what we had accomplished with the graduation website, we turned our attention to professional headshots and couples photoshoots, another booming market we discovered during research.

We were not actively pursuing it, but the graduation photographers also did other types of photoshoots. We wanted to show that our website had range and was not just limited to college students and graduation.

At this point, we had three categories of photographers that we offered on our website and photographers were signing up to be on the Shoot website.
Final version of the home page
Each photoshoot category had their own subdomain. From each of those, we displayed four photographers chosen to reflect the different price points.

We also added the 5 star rating. We showed our customers that these photographers were vetted by us to be on our platform.

We added a tagline to each categories to reinforce the idea to the user of just how special it is to capture the graduation experience.
How the website performed on mobile was key.
Scrolling through three photographer cards, stacked on top of one another was not an issue for our users. Scrolling through eight of them? That was a bit much.

Especially on our home page. Four photographers per category. That's TWELVE cards!

Our best solution was horizontal scrolling. Cards were resized so while looking at one card, 2 other cards are peaking in from the sides indicating to the users there are more, along with the arrows and dots at the bottom.
So, what goes on a photographer's profile page?


Customers want to see a selection of the photographer's best photos for that particular category. For example photographer's listed under graduation will only have graduation photos.

Pricing Packages

Customers wanted packages which include:

  • Number of photos to be delivered.
  • Time length of a photoshoot.
  • Outfit and location changes.

Photographer Info

This would include a short bio to inform the customer who their photographer is, where they are from, and what other areas of photography they might be skilled at.

Presenting customers with all the information they need
We started off by showing the same information from the photographer's card on the home page, along with their other specialties. We kept the gallery very simple, alongside the option of full screen viewing for those that wanted to do so.

Our technical constraints prevented us from taking payment on the platform itself so we were only going to do photoshoot requests at no cost to the customer. So we were upfront about how clicking the booking button will not charge the customers.
Pricing Packages
We asked photographers for the bios. Normally, it is something they already have on their own websites so we copied them.

In most scenarios with pricing packages, users would click on the package they want. Once again due to our technical constraints, we were not able to do.

We also added a booking button at the bottom of the page, alongside a "go back" button. It was an odd choice because we wanted to see if we can the users to explore other options. They almost always scrolled to the bottom and click that booking button.
The real question: How does booking actually work?
A Major Test of Intellect
Our technical constraints were tested here. This was the first thing I worked on before beginning the project. I tried looking at every single booking experience I had encountered. Since I could not replicate their tech, I could replicate the experience. I started looking at some ready made solutions.

We had used Google Surveys for our interviews, maybe I can embed one? The problem with that was it would break the aesthetics of the websites. We also wanted the customers to stay on our platform throughout the booking process, so routing them to a different tab was out of the question.
Netlify Forms
We hosted the website on a service called Netlify and made use of Netlify Forms. The form submissions would be stored on Netlify, get added to a Google Sheets, and sent to any number of email addresses.

That way, when a customer would make the booking request through Shoot, all of us at the company would receive the booking request notification.
We added our packages from the profile page here as restyled radio buttons so the customer can select which one they want. We re-included all the information or else the customer will have to go back to profile page, and the back and forth is not a good user experience.
The Concierge Service
We had to make up for our lack of technical capabilities. After the customer clicks the book button, the first hurdle has been crossed. They have sent us, Shoot, the booking request. The next part is actually making the photoshoot happen. This was entirely customer service and was handled by my partner Simbai.

After getting receiving the booking request, Simbai sent the photographer the information to make sure they were available for that photoshoot date.

Then, he would send the customer an invoice with all the details and a link to Paypal or instructions for payment through Venmo.

We did that for each of the 40 confirmed bookings on our platform. You can see below how we received a booking request via email, and how Simbai used Mailchimp to send the customer to booking confirmation.
The Outcome: Was the website launch successful?
We launched during the Spring college graduation season of 2019 and it was a surprising success. Marketing was done on campus through flyers and word of mouth and on social media, primarily Instagram. We made around 40 photoshoot bookings during that graduation season. Revenue was approximately $3500.

We were able to prove what we hypothesized, that the market wanted a product like Shoot, and that with more funding and the more team members, it can expand to cities all across the United States.
What I learned from leading and launching my first ever digital product
Throughout the entire beta phase, I learned to be a designer, a project manager, and user researcher. I had to wear multiple hats and was forced to look at every design decision with constraints in mind. Just because I had a brilliant idea for the marketplace, didn't mean my developer skills would allow me to accomplish that. I had to pick and choose what I could do.

I learned to be part of a team. The success was by no means mine alone. If it wasn't for Simbai's customer service skills, or Alina's marketing skills, we would have definitely failed even before we started building it.
What could have been done differently?
We did too much "manual labor" during the beginning phases of project. There were multiple situations where photographers did not comply and did not provide information on packages or even send their portfolio photos.

We assumed because they get paid for their work that they had a system and all the information was prepared. We should have changed how we gathered the information when we encountered the issue.

As the designer and developer, it was a lot of work given the time on hand. I should have explored more low cost no-code tools that were available on the market (like Glide) to create a rough proof of concept and test it. We also should have had a more skilled developer on our team from the beginning to assist me with larger technical challenges.

The biggest problem was that I went from rough sketches to code, directly. If I had spent more time on prototyping using a design tool or even coming up with high fidelity mockups, I would have been able to reduce my workload.