Ada Lau is a Product Designer living and working in New York City
Cover_Loop.jpg

Loop by Eko

 

 

Loop By Eko

At Eko, our teams were spread between offices in NYC and Bangkok. Since we worked in different time zones and locations, it was not always easy to have quick chats or check-ins on each other's progress. We wanted to find a way to get an okay confirmation from our colleagues before a task moved along towards the right direction. For example, a designer might need an iOS developer to look at mocks on iPhone and iPad to make sure there are no red flags. In another situation, a copywriter might need a marketing associate to approve a promotional copy before doing translation. These simple approvals need to happen quickly for projects to move along. 

We envision a tool, aptly named Loop, that allows users to send a request to a specific individual, track its progress and be notified when a response is received.

 

Overview

Initially we wanted to create Loop as a new feature within the core Eko app, but an executive decision was made to build Loop separately and to target clients specifically in Thailand.With a team of 4 engineers and 1 designer, we were tasked to create Loop in 6.5 weeks in order to fulfill a commitment to a company for a soft launch.

 

My Role

As the sole designer on this project, I was responsible for the overall experience of the app from the interface to the interaction design. I led brainstorming sessions with the entire team, maintained constant communication with our Thai colleagues oversea and conducted guerrilla testings locally in NYC. Due to the tight deadline, I jumped from sketching to high fidelity mocks in order for developers to start building the app simultaneously. 

 

Research

While conducting competitive analysis, we found that poll was similar to Loop in a certain way. A user creates a question and opens up the poll to a mass audience to vote on. For Loop, instead of arriving to the answer by voting, a user creates a request and seeks a respond from just one particular individual. At the end of the analysis, we didn't find any product that offers the solution of "ask a question, get an answer" in a simple and direct way like Loop.

 
 

USERS

The two types of users we have on Loop are the sender and the receiver. After the sender sends a request to the receiver, he or she needs a way to keep track of the request status. On the other hand, the receiver needs to be notified when a request comes in and promptly respond to it.

 

The Interface

Sign up and verify

All new users must register with their company email in order to be connected to their company domain. Upon the first time signing in, each user will receive a verification code as a security measure. 

 

Create a request

Sender creates a request by tapping the pencil icon at the bottom right to pull up the contact list. After a recipient is selected, sender composes the request and hit send.  

 

Respond to a request

Receiver will receive a notification when a new request comes in. He or she can either approve or disapprove the request with an option to attach a message. Once the request has been responded, it will be automatically archived. 

 

CHALLENGES

The states of a request

To simplify the architecture, our team want to flatten the hierarchy so that all requests (the ones that need approval and the ones that have been approved/disapproved) would be shown on the same page. A request can be in four different states:

  1. Pending - when a request is waiting for the receiver to approve 
  2. Approved - a request that is approved
  3. Disapproved - a request that is not approved
  4. New (from the receiver's perspective) - a request that has yet responded to

Iconography were designed for each state for users to quickly recognize the state of each request is in. We conducted a guerilla testing with 12 participants found in our office building. The test was to ask each participant to match each icon to its appropriate state. All users successfully matched the icons to the labels.

 

Color

Since Loop was designed for our audience in Thailand, we were mindful of their culture in terms of color choices used in the app. The most intuitive choice of colours for approving and disapproving were green and red respectively. However, it is uncommon for Thai to respond a flat out 'no' in any situation because it is perceived as too aggressive. To test out the suitable colour for 'disapproving' a request, we created 3 colour combinations and asked 9 of our Thai colleagues to pick their choice. 

Most participants expressed that black was too grim and orange felt too positive for a 'disapproval' button. At the end, the blue-gray option was chosen. When asked how they felt about the colour blue-gray, participants responded that the gray tone suggested a sense of rejection without too confrontational.

 

Results

Loop was launched in December 2014 to a medium-sized corporation in Bangkok. We monitored the adoption rate for the next 4 months and the results were disappointing. As a team, we thought hard on what went wrong and how we could have done better.

 

Retrospective

Given the aggressive timeline to launch the app, we did not spend enough time validating our problem. We did not conduct enough research in Thailand due to language barrier and several of our meetings with Thai testers fell through. We made assumptions that our use case of sending frequent requests for approvals also applied to our Thai audience. We simply did not have enough evidence to proof that Loop was sustainable as a product on its own. 

Perhaps our team should have pushed back harder and built Loop as an added feature within Eko. Since we already have a steady user base on Eko, we could have easily get data on the usage of Loop and iterate from there.