Eloquence For Experts, UX/UI Case Study.

The Eloqi App

RED Academy, December 2016

Three UX Designers. Originating from Vancouver, Calgary and Dublin.

Opportunity and Challenge:

Eloquence, expertise, and encounters are key to a successful business person. An individual must be an expert in their discipline and dialect to be a productive professional. But what happens when a professional must change dialects? They must now learn a new language, but that entails more than just fluency and conversation skills. To be a multilingual professional, one must know specific jargon and terms associated with the trade in each language, not just cadence and fluency.

This is where Eloqi steps in. Eloqi aims to fix this problem harming our societies globalization. Eloqi does not only touch on fluency skills via one-on-one student to coach interactions but additionally emphasizes on developing multilingual professionals through sessions of teaching jargon and terms, not just the new language. Thus, helping further the Eloqi advantage.

Within a three-week timeline, we were to create a meaningful and developed experience for the coaches. By focusing on the coaches, Eloqi will have a strong foundation for any new user. The mentality behind this is that anyone can learn a new language, but not everyone can teach one let alone teaching industry-specific terms and jargon.


The coach user was very difficult to conceptualize. This being because the coach will have a user of their own, the student. Just like the movie “Inception”, we would have to think multiple layers down to gain access to a detailed mental model of the coach.

The two main competitors (Italki, Tandem)

To address this, we interviewed coaches and students that have used the Eloqi beta or other language learning apps. Allowing us to understand both users and other competing apps. Although the niche of language learning/teaching apps has been explored rather well (Tandem, Italki, Doulingo etc.), most users must go beyond the means of the platform to gain “new language professional skills”. This is where Eloqi wants to fill the gap.

The way we kept our research under control was through our affinity diagram. You can also see the lovely Jenny Lam who lent us her wonderful wisdom and advice to the project. Thanks Jenny!

Both Tandem and Italki are well developed and fun to use platforms. From our heuristic analysis of them, we decided that the energy and intuitive features present in them are why they are such strong competitors.

It’s not often you go into a project, conduct a competitive comparative analysis and find that the competitors have little to no flaws. They do a fantastic job in this area of language learning/ teaching platforms. However, they focus on fluency and conversation skills, not professional skills.

The interviews we conducted with past students and coaches of these platforms often remarked these aspects. We realized that having a simple and easy to use user interface with a light energy helped ease the use of language learning. Consider this. Face-timing or skyping with a stranger, then teach or learn a language with them and then have to pay per minute you are connected. It was found it could be very nerve racking for most people, especially when the aspect of was money involved.

The key aspects of the main competitors.

This is present in the two main competitors, the features, and energy incorporated in the design help eliminate the fears and pains that might be present with one on one voice calls. They turned out to be a great resource for us to adapt into our design. Hats off to the competitors of this domain.

Within our competitor analysis, we also viewed other platforms. Ones that are not directly in competition to Eloqi, but fit in the domain of asymmetric platforms. An asymmetric platform, meaning two users with similar motives and goals can use the same app in different variations is something we had to create in this project. We dissected and analyzed Uber’s driver platform and the hosting side of Airbnb to help understand what makes a great asymmetric platform.

What we found was that the platform must have a transition point for the user, to change for the needs and functions associated with that unique situation. Also, that it has to be clear that a switch has been made.

Additionally, one of our biggest discoveries from this phase was a concept;

A coach cannot become a coach, without being a student first.

Can you teach a musical instrument without learning how to play it first? Of course not. The same applies to a language or a skill. This was a revelation for our coach user, for they used to be the student. With this concept in mind, it was paramount that we kept the coaches multi-layered personality intact and capture an aspect of clean professional energy when entering our next phase.


This multi-layered concept carried to the flow of the app. To become a coach, you must be a student first. This is how we would capture the coach user. Our coach will be considered a student coming to Eloqi first, then decided to apply to be a coach. After the application is approved by the Eloqi team the user is now considered a coach. The app will now open up for them. Allowing access to the coaching flows and interface and the ability to post and market themselves to the students.

Hugo working on the user flow.

Seeing we had to consider our coach as a student first and the complexity of the platform, we had to develop an onboarding flow for all users. The coach side of the flow doesn’t actually take place until the very end of the flow. Having every user using the app and going through the same tutorials helps create a knowledgeable user base. Additionally, having each user go through the same initial profile set up and vetting creates a defined and precise ecosystem of users. Although the platform is for anyone that wants to learn new languages and skills, The Eloqi team did not want the wrong people using the app for ulterior motives (dating, sales etc.)

Digitized user flow. Notice how the user must want to become a coach and that the system does not lead the user to it.

Grady and I working on the fine line of a “must have” and a “nice to have”.

While imagining our user flow, we listed current and potential features or elements that could appear in that stage of the flow. After completing the flow, we came back to the features listed and copied them into post it notes.

With all kinds of features and ideas together, we prioritized them into three categories of must have, nice to have and not needed and coloured coded them accordingly. This technique worked very well for my last project, (YELL) but rather than putting them into a sitemap, we grouped them into three major areas that the user would have most traffic or dependency.

Green dots are features that are “most needed” and the pink are “nice to have”.

This exercise furthered our understanding of what will appear on each page or section of the app. By doing this within our user’s mindset, we eliminated any discrepancies between team members and personal biases to how we thought the app show work.

More importantly, afterward we were confident that our design would be effective and complete by incorporating the “must haves”. Then pleasant and developed by including the delightful and clever “nice to haves” features.

We learned many key indicators that formed our persona and in app features from our research phase. It was now time to apply them to the user. But who is the user?

This is Jessie and she was present with us throughout the whole project. Anytime we had a problem or couldn’t agree on a choice, we would run back to this asset and often had a print out of her on the wall to remind us of the right choices to make.

Although Eloqi has two different users we only had to make one for this project. Making two would have been ineffective, for they would have been the same user but at different points of the user journey.

One way to understand better this is user goals. The success of a student learning a skill is also the success of the coach who taught it. Both user goals are the same. The student wants to learn and the coach wants the student to learn too. However, the motivations behind the goal are different.

Again, coming back to the enigma of asymmetric apps and the “Inception” user layering that was Jessie.

Thats me coming back to the user flow for reference.

The two main user aspects we kept coming back to where:

Goal: Create engaging lessons

Frustration: Scheduling

These were recurring trends in our banter and when moving into the next phases kept popping up. For not only where these two common themes in our research, but also the most difficult to design for.

However, we decided to stay within the planning phase longer than discussed at the beginning of the project, and it helped set us up for the more difficult parts and time-consuming tasks of the process. If we didn’t choose to take the extra time in this phase, our finished product wouldn’t be anywhere close to complete on time.

Design and Testing:

Now my favourite part, the visual design, and iterations. With the research and extended planning phase complete we started with the design studio exercise. This where we could flex our creative muscles and finally see what our work will look like. And we started with the design studio exercise. Seeing our features and elements were filtered and grouped by the feature prioritization, the design phase was agile and streamlined.

We could reliably know what we would be drawing will have a positive effect on the user. Each area had its own elements and features already placed and categorized. It was just a matter of what those elements, would look like and how they would interact with each other.

To “studio” a problem, we assembled 5-minute stints of silent sketching. After time was up, we shared ideas and went again. Thus, leading us towards thoughtful and creative user design as a group. These then developed to paper prototype pages and feature ideas.

For our final prototype, we knew we wanted to create a clean, polished IOS native app in a small-time frame. We utilized an IOS 10 bootstrap kit for Sketch then adapted its assets for our project. So, when drawing the first paper prototype, we followed IOS design language and trends that would be present in our final prototype.

From the whiteboard to the sketchbook we made a paper prototype to test and iron out the key three areas (these were grouped in the feature prioritization).

-Sign up/Onboarding

-Session (one on one voice call)

-User Profile

Seeing there were three of us, we divided and conquered one area each. Rapidly developing, testing and iterating our paper pages respectively. Then came back together to report findings and changes. This allowed the prototype to become a version we converted into a digital Medium/high-fidelity prototype.

The majority of the iterations and changes came from areas of the prototype that strayed away from IOS design trends. Adapting the design needs to match the common design trends was the hardest part of this phase. We walked the fine line of creating a design that is intuitive and familiar but also innovating and unique. Where we could, we chose to keep the design simple and familiar rather than overly creative and off the beaten path.

Although that may sound detrimental, we found by doing so we could focus on other areas that there is no existing format or trend and really stretch the boundaries of a native IOS design.

Moving up in fidelity, we carried the notion of an IOS native app with us and converted a design kit to our needs. Seeing our paper prototype was based of IOS app trends, converting the fidelity was very straightforward for us. Just like the previous prototype, we stuck to our previous key areas designed, we again divided and conquered then came back for team alignment.

Remember the two major user aspects we had difficulty with? Scheduling and creating engaging lessons for students? Here is how we addressed them.

For scheduling, we were considering creating something new and fresh rather than a clone of an existing trend. The reason being that our user wouldn’t be needing what the trend was meant for. The trend we would utilize is Apple’s “ical”. Though its thought-out and clean, it wasn’t ideal for our user.

The trend is made for selecting events or specific times of a day and not developed so much for reoccurring events or periods of availability. Our user would have to select what times they are available and if it would repeat certain days or weeks. Our final choice was to use the trend that “ical” created but adapt it for a user that would need to be selecting availability rather than individual times or events.

The user chooses the days and times they are available and if this availability repeats and saves it. Then the students will be able to request a session with them by choosing a session length with the coaches’ saved availability.

For creating engaging lessons, we found our self in a deep rut. How can you reliably make this part of the user experience delightful and efficient? For it would be different each time for every user with a new student.

From our research that when you want to teach something to someone it is invaluable to incorporate the student’s interests into the lesson. This helps the lesson stick in the student’s mind.

Do me a favour, pretend you and I are going to have a conversation on a skill you want to learn. How would you start that conversation? How would you make sure that we wouldn’t be wasting time (or money in this case with the pay by minute video call)? Wouldn’t it be nice to have a list of common interests in-between you and me? Maybe some friendly icebreakers to get the lesson going?

This concept came into our design through interest matching and in call session notes. By having all users fill out general interests in the very beginning of the user journey we can later match students and coaches when they are gearing up for a session. After being accepted for a session the coach with be shown a list of common interest between them and their future student. Then, the coach can create session notes that will be present in the video call. The idea here is that a coach can now keep the session on track with the common interests between users reducing “dead time” in a lesson.


All together this was the most stressful, engaging and rewarding project I have done in my career yet. We chose to pour everything we had into this project for it would be the last one we will have as students at the RED Academy. Our strong work ethic and sprint mentality helped create a final product we were all surprised and delighted with in the end.

Our instructors, clients and fellow designers were blown away by the level of detail and thought we went into for this project. Even looking back now at the final prototype makes me second guess that I did this work. Three months ago, I wasn’t capable of anything of this caliber and now I am. My time at the RED Academy will be with me forever. Personally, I am very proud of my work here. I was able to push my limits as a professional and team member in this project while expanding my focus to more than just UX design and into UI design as well.

The number one take away I will remember from this project is that an extra day or two within a phase can make all the difference down the road. Although in the sprint mentality, taking a second to ask yourself “wait, did we get it all?” is invaluable in making a design successful. One way or another, a complete product will come forward for those who do not cut corners, regardless of the timeline.

Want More?

Visit my portfolio!