An early-stage startup contacted me to help them bring their idea for a VoIP app to an MVP. They had the core idea laid out but not many resources, so they were looking for someone that could create the visual design but also do research, handle interviews, and create prototypes to test hypothesis.
I'm always open to challenges and I like helping early stage startups to bring their idea to reality. Although there were budget restrictions, we were able to create a working relationship that was beneficial for both parties.
• User Research
Being an immigrant myself, I use several types of apps on a regular basis to keep in touch with friends and loved ones. Most of them perform the same functions with some variety in their visual design and user experience.
Nearly all tested subjects held conversations with family and friends who lived in a third-world country, which meant they didn't have access to a good and stable internet connection.
Video calls were a rarity or very laggy to make the experience enjoyable, although some reported somewhat stable connections that allowed for quick 15-20 minute calls before the video quality started to suffer.
The idea was to offer users a way to communicate with their families while still letting them share images and videos easily through the app.
The app would use the telephone network for the voice call which offers better and stable audio quality, while using the wifi connection for sharing media files since they consume less bandwidth than a video call.
Time and resources were the main constraints I had for the project. Keeping the project going forward while testing, designing and working on other projects were definitely the main hurdles I encountered during the process.
After interviewing users and gathering all the information I begin to get a better picture of the target user and their behavior as well as some basic questions like, how many similar app do they use, how often did they use those apps, what were the most common tasks performed and how?
I also happen to know a good amount of immigrants, which could help get more information on their habits and the friction points they experience with similar apps. Most importantly, I would have regular access to them to do interviews and test my assumptions throughout the process. A total of 20 participants were interviewed, helping define three main group of users.
Heavy users: those who use the apps on a near daily basis, with each session lasting from 30 minutes to 90 minutes. A good example of these users are new parents, who want to share with their family in detail.
Medium users: those who communicate with relatives or friends at least twice a week with sessions ranging from quick 10-20 minutes, to much longer 2-4 hour calls.
Light users: most of them are senior people who want to keep in touch with their family but are not fond of using these apps or are hesitant to adopt the technology because of the steep learning curve most apps have.
We started out by creating a list of the product requirements. This brought focus to the core functionalities and gave us an idea of what an MVP looked like.
From the initial interviews with stakeholders, it was clear they wanted to create a stripped down app with a lower entry learning curve that could appeal to a large audience, especially older users, an important demographic that uses this type of apps.
Once the wireframes were created, we tested and iterated until we were happy with the user flow and confident enough to move up to hi-fi mockups.
The onboarding process is crucial to get users to try the app, explore it and make a decision about returning for more or leaving it for good. Completely removing that first friction point of creating an account or linking one from other services, allows the user to try the app without committing much time in it.
After the splash screen, the user is presented with an offer to try the app by giving them 20 minutes to use for free, prompting them to enter the phone number they want to call or to import their contacts into the app.
Both options allow the user to make a decision according to their preferences. Entering a number might slow them down if they don't know the number by memory, causing the user to drive away from the app to look for the number, but it also represents a safe option if they don't want to share their information at this point.
Importing contacts from their phones requires the user to share information in exchange of a better experience, but it also gets the user to be more invested in the app, something that can ease friction later in the process when they are asked to create an account.
When users arrive at the contact screen, they are presented with two options, to add contacts manually or import them from their phone. In the case the user had already imported their contacts from the onboarding process, the screen will be populated with all his contacts.
Keeping the option to add the contacts manually makes it more manageable for older users who in average had 3-5 contacts they used on a regular basis, or users who still are not comfortable giving access to all their contacts.
By tapping on each contact the user is presented with additional options such as call, edit profile or delete the contact, tapping on the contact's picture or name gives them access to the profile. They can also make any contact a favorite by just tapping the star on its side.
Calling & Sharing
Calling is the main function of any app of this kind, but I wanted to also focus on sharing. During the round of interviews, nearly all the participants shared some form of media (mostly images but also videos to some extent) every time they used the app. I wanted to give users quick access to that functionality while also keeping the design clean and simple.
After placing the call, controls for the two main functions take the bottom-center of the screen, keeping them accessible throughout the call.
Users are introduced to the sharing functionality with clear, visual instructions that guide them through the process of sharing media with their contact.
A photo strip from the phone's gallery is shown, providing easy navigation and access to the pictures. Additional controls to the phone's camera were added to give the user the option to take pictures.
One of the most critical components of any app that requires some form of payment is the checkout. It's where any point of friction could frustrate the user and make them abandon the process. That's why it's important to eliminate all unwanted distractions and keep the user focused on the task.
Having three pre-defined amounts give the user quick options to choose from, keeping the process moving forward.
When the user chooses an option, inline help shows them how many hours they will get with the selected amount based on the country they are calling to. This data could be taken from the calls made with the free minutes provided. The data could be updated to represent information that is more relevant to the user.
An option to enter another amount was added to give the user more flexibility on how much they spend.
The user is presented with two payment options to choose from, the information needed to complete the process will populate the screen according to their selection.
On the interviews conducted, most of the users said they would buy credit before making a call instead of after. Presumably, because they didn't find it necessary after using the app and made more sense before making a call since it represented an obstacle for using the service.
To leverage this behavior, a call-to-action to Make a call was added to the end of the payment process, which would take users to the recent calls screen.
The visual style needed to communicate the same friendliness and ease of use of the app. I created a set of illustrations using rounded shapes and simple forms to give the app that approachable feel I was looking for.
From the beginning, I knew that prototyping was going to let users interact with something more tangible and help me gather more detailed feedback. Often times I would find friction points where I wasn't expecting them, like a flow that didn't make much sense to some users or how eliminating the top navigation bar improved the payment process by reducing the amount of exit points.
As with most personal projects, resources were limited to the time that could be invested after my regular job and the number of participants I could find to test assumptions and keep the project moving forward.
I learned a good deal about running interviews, how and when to ask questions to the users or to avoid the urge to show them how to perform a specific action. More importantly was to know how to take the feedback provided and translate it into a better solution for the user.