Summary: Outclip is initially a mobile video messenger app built for remote enterprise teams. Initial design concepts and prototypes revolves around improving the usability of the Android app. Through iterative usability testing and product launches, Outclip has become a web app supported through Chrome extension to optimize bug reporting through video and screen recordings. With Outclip, users can quickly record and share visual and interactive bugs through a Chrome extension, showing tech support the exact steps in reproducing a bug.
Project Role: Cofounder, product designer
Tools: Axure, paper prototypes, Invision, Sketch, Webflow (landing page design), Zeplin, Adobe Creative Suite
Deliverable: User research, usability testing, paper prototypes, wireframe prototypes, hi-fi mobile and web screens, functional landing pages
Outclip is an enterprise video platform that lets employees at work to quickly share problems and updates with each other via quick video messages.
The problem that Outclip is trying to solve is that in a remote environment, the only way for teams to collaborate and communicate with each other is through either a text-based platform like Slack or email, or a real-time call/conference tools like Skype or phone. Outclip attempts to fill the gap between these two popular systems with video messaging.
When I joined Outclip, its first iteration is a Snapchat clone. The idea behind it is that, with Snapchat becoming a popular video platform, we should expect remote teams to find it fairly intuitive.
While the app is extremely quick in allowing users to record a video- it’s the first action the user can take as soon as they open the app, the video management system is extremely poor- the only way to access videos messages received is to tap through and view videos individually. Additionally, because Outclip is built on Java, it’s limited only to Android devices.
But before we began rebuilding Outclip, I suggested that we take a closer look at our markets and find out what our users needs in order to define a meaningful problem to solve for.
Before we began conducting interviews, we came up with a couple market beach heads that we wanted to test out. We made these beach heads as assumptions on the likelihood of these industries adopting Outclip in its current form.
Since we are based out of Houston, the oil and gas and manufacturing industries are our best bet. We assumed that quick video messaging would be extremely useful for field service personnel as a fast and easy way to show their work.
Our earliest subject is Mithra, she's a chemical engineer that works in a plant that produces detergents and agents that supports the oil and gas industry in Houston. Two major insights we got from her is that the plant has fairly rigid safety protocols- personal cell phones aren't allowed on the plant floors, and that plant operations depend on different shift work, when it comes to handing off work between different shifts, it's not without errors.
“Our operators work in 4 different shifts... shifts hand off work to each other through handwritten documentations. We get a lot of problems from mistakes in these documentations.”
- Mithra, Chemical Engineer
We then talked to a couple more connections who have worked directly in oil companies like Shell. We learned that oil companies always maintain a direct line between the main office and their offshore platforms, platform operators work around the clock in shifts to maintain operations and report any problems, and that safety is of utmost importance on a platform- personal devices are prohibited outside of living quarters.
While shift work handoffs could be a potential problem Outclip can solve, It seems that the manufacturing industry has extremely rigid safety protocols that prohibit personal devices, we might have to find another approach.
In the meantime, we began to interview contacts that work in software and IT.
The big insight: meetings suck.
"125% of my time is dedicated to meetings... My calendar is very very over scheduled."
- Cynthia, Director at Client Delivery
From our interviews, what we heard time and time again is that meetings and conferences are the biggest pain point. From scheduling these meetings, setting up these meetings, to participating these meetings, timing is never ideal. Additionally, nearly all of our users doubt the outcome of these meetings, since the average human attention span is around 15 minutes, a lot of content is often missed.
What's more, meetings are doubly worse when it comes to dealing with remote and offshore teams due to time zone differences. We interviewed Sonali, the CEO of a software company that hires offshore development teams.
“When a client has a request at 4 pm, we'd have to tell them we can't do it because we'd have to wait for our team in India to respond overnight... I usually send out requirements over email, but it doesn't feel urgent, so I usually stay up for video conferences to make sure."
- Sonali, CEO
At this point we seems to have a potentially good problem to solve for. But we wanted to explore further, we wanted to see if we can tie the problems of meetings with remote teams with field service personnel.
Around this time, we were accepted into Y Combinator's inaugural Startup School- an online mentorship for guiding startups to product launching. Throughout the course we received invaluable lessons in user research, user testing, and building a pitch for marketing our product. It's through Startup School that I personally learned that the principles in product design goes hand-in-hand with product direction and management. More on this later.
Additionally, we managed to get some very expensive passes to attend the big annual Offshore Technology Conference (OTC) in Houston. We hoped it would be our big chance in scoring an opportunity with a manufacturer.
We spent about 3 days walking around OTC to try to talk to every attending company there. Our strategy was simple: keeping in mind with what we learned about meetings and offshore teams, we would try to identify any potential problems or room for improvement when we talked to a company. We spoke to a number of companies that operated offshore teams. By the end we had a few lukewarm responses that we followed up, but ultimately we didn't get any replies.
The lack of response from these companies along with the insights we got from previous interviews tells us a couple things:
The lack of response from OTC meant that we really shouldn't try to get into the oil and gas/manufacturing sector. A valuable lesson we learned later on from Startup School is that we should start with what we know, we should start from where we are experts in. So we turned our attention back to the tech field.
“Solve for problems from within your field, start from where you are an expert of."
- YC Startup School, Peter Thiel, every startup basic lesson ever
We looked at all the research we've done so far, and all the insights we gathered and created an affinity map. Affinity mapping was also the lesson plan of the week from Startup School at this point.
We knew meetings is the big beast we're trying to slay, and we have good insights that answer the question "but what about meetings?" The affinity map helps us boil down our nebulous problem into several basic insights:
Then we came up with a problem statement that ultimately fits within our scope:
Conventional video conferences between teams across different time zones are often conducted with high overhead; companies often have to operate outside of business hours to conduct live video conferences with their teams, additionally, these video conferences are further constrained by scheduling and constant technical difficulties. Our users need a new communication platform that preserves the productivity and engagement while removing the overhead of conventional live video conferences.
Now that we're firmly focused on building an alternative to meetings, our product needs to make people feel like they're having a meeting. The current iteration has poor usability and does not let people feel like they're in a meeting.
I advocated that we look at existing messaging systems like Facebook Messenger and Slack, to give users the ability to cycle through and choose the messages they want to see; part of the reason why Slack became such a popular workplace tool is because it’s so intuitive to use, and Snapchat is arguably the exact opposite of good usability. I also suggested that we need to include an iOS app; I know from experience that companies tend to depend on Apple devices for work.
Clickable wireframe: nq0g9t.axshare.com/
The first concept I came up with is a tried-and-true chat room/messenger design. The wireframe prototype is built with Axure.
Users are organized into various channels and chat rooms either through invite or if they’re public (like Slack channels), and they can scroll through to view, or directly record and send a video message into these channels.
We took our wireframe and tested it with friends and users we interviewed in the past. The testers were to accomplish 4 major tasks:
The biggest feedback we got was the lack of affordance and ambiguous wording. Our testers were able to accomplish the tasks set out, overall they found the prototype to be fairly intuitive.
With these findings we proceeded with following through to developing high fidelity screens.
