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.
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.
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.
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.
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.
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.
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:
- Pending - when a request is waiting for the receiver to approve
- Approved - a request that is approved
- Disapproved - a request that is not approved
- 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.
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.
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.
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.