Web Analytics
Aida – Case Study Aida - Case Study - Brendan Ho

How might we make it easier for non-native English speaking remote workers to write and communicate more effectively with businesses in North America?

  • Sketch
  • User Research
    User Testing
    UX/UI Design
    Product Design
  • September 2018 - April 2019

The Problem

Today, there exists an unprecedented growth of non-native English remote workers in the digital workplace. These workers face communication barriers between themselves and the businesses they work for in North America. This project aims to make it easier for them to learn and construct business English emails, secure meaningful and better-paying work, and ultimately interact more effectively with businesses in North America.


Aida is a web application that helps and teaches users how to write business emails. Users fill out fields, learn as they write, and then receive a pre-formatted, structured message based on the fields they completed. These messages can then be fully edited, copied to a clipboard, or saved as a template for future use.

Process Overview

This project all started in the form of research. From there, it went into prototyping and design. The process, in a nutshell, is summarized below.

1. Research
& Understand
2. Design
& Prototyping
3. Testing
& Refinement
4. Review, Reflect
& Reiterate

Growth of Foreign Remote Workers

From a mix of personal experience and secondary research methods, companies turn towards hiring remote workers for a number of benefits: saving costs, time, flexibility, and being able to access larger pool of talent. One prominent sector of this market includes offshore and foreign remote workers. Many businesses in North America are now increasingly employing workers in India, Phillippines, and other overseas countries (Sutton, 2018).

Non-native remote workers are at a disadvantage due to their command of the English language. Specifically, their ability to secure meaningful and well-paying work is compromised due to their limited skills in English language. In both local and online gig markets, they regularly face lower pay rates, experience issues with clarity and understanding, and are often second to those who speak English natively. Additionally, there exists a lack of efficient systems for creating and reviewing their written English messages before being sent off to their native English prospects.

Research Questions

During my research, I set out to address the following questions:

1. What effect(s) does being a non-native English speaker have on their success in finding remote work?

2. What specific area(s) (grammar, spelling, layout, etc.) of online English communication do they have the most trouble in?

3. What are the main scenarios (proposal, introduction, etc.) in online business communication that they’ve had trouble completing?

4. What solutions do they currently utilize to ensure that their messages are correct before being sent off?

Conducting Primary Research

Primary research was obtained using a variety of research methods.

Research Results

Results from my primary research activities are summarized below.

Empathizing with the Users

After conducting my primary research, it was important for me to understand and empathize with my targeted audience. Based on the interviews completed, I put together various user personas to further solidify my understanding of my potential users; the people who would find value in using this tool.

Journey Mapping

Taking it a step further – I mapped out an emotional journey map that a potential user would go through. It was important that I understood the stages of a user’s experience from they initial moment they feel the need, all the way to the desired outcome and benefit. Empathy is crucial in design; I tend to adopt it in any project I’m working on. It’s all about their experience and how the end product can make their lives easier. It’s certainly not what I like or might want.

Desired Functionality

From there, it was time to define what functionality my solution would encompass. I’m a big believer in keeping things super simple, and gradually adding onto it later. It doesn’t make sense to build and include everything from the get-go in phase one. Start small, test, talk to your users, refine, and build as you gain insights.

Defining the Core User Flow

From there, it was time to define what functionality my solution would encompass. I’m a big believer in keeping things super simple, and gradually adding onto it later. It doesn’t make sense to build and include everything from the get-go in phase one. Start small, test, talk to your users, refine, and build as you gain insights.

Branding & Identity

I proceeded to create actual, visual elements and components for my solution - knowing that these would be tentative, tested, and refined.

I chose blue as the primary colour. Blue symbolizes trust, loyalty, wisdom, confidence, intelligence, faith, truth, and heaven. Blue is considered beneficial to the mind and body. Aida ultimately provides users with confidence and peace of mind - knowing that the emails they’re sending out are professional and can yield beneficial returns. Green is the main colour for my call-to-actions. It pairs well with the blue, and serves as a gentle action or confirmation step button that isn’t harsh or too overbearing.

When it comes to selecting style, every designer has their own preferred design aesthetic. In my opinion, you can’t force your own design style onto another. Instead of pushing your own design agenda forward, you need to consider who your actual targeted user is, and what they’d feel most comfortable with.

“Aida” Name Choice

The name “Aida” was chosen very deliberately.

1) In the copywriting world, the acronym “AIDA” is a widely known formula and stands for attention, interest, desire, and action. Highly relevant to writing a business email, and an approach I always use whenever writing copy of any sort.

2) The name incorporates the word “aid”. This solution is helping users, after all.

3) The name also incorporates the word “AI”. This tool would eventually utilize AI frameworks (such as the open-source TensorFlow or ApacheSpark, the same technology behind Grammarly).

4) The name sounds and is pronounced the same as the name “Ada”, a girl’s name that’s friendly and pleasant - and in a similar vein as Cortana or Siri.

5) It is also named and pronounced after Ada Lovelace, an English mathematician born in 1815 who introduced many computer concepts and is widely considered as the first computer programmer.

UI Components

After developing my first and initial prototype, I opted to focus more on the UI components. I wanted to create elements that were consistent, repeatable, and scalable. As I continue working on Aida, I will be building a more formal and structured design system.

User Testing & Effectiveness

Over the course of this semester, I was able to show and test my prototype to relevant users at different stages. Below is a small sample of the participants who helped influenced the direction of Aida through feedback and testing.


I also ran surveys and showed my final prototype to several relevant users.


97% of participants


100% of participants


90% of participants


87% of participants

Marketing Landing Page

Aida would initially be launched and marketed as a startup. I designed a landing page to garner interest via email capture, and to communicate a few of Aida’s features and benefits. Coded landing page: https://brendanho.com/aida/

UI Designs

I consider these to still be a work-in-progress.


1. Focus on a single, core audience - and expand as you learn.

Throughout this project, I kept bouncing back between my core user audiences. Would this product focus on small business owners by making it easier for them to understand the foreign remote workers they hire? Or, would it focus more on the non-native English speaking remote workers and making it easier for them to write?

Moving forward: If a multi-sided audience is involved, stick and commit to one first. All marketing, messaging, and design choices should support the audience you've initially committed to. You can always go after the other audience later.

2. Do research in conjunction with building.

I felt like I needed to wait until my research was “done” or felt thorough enough before I actually proceeded to building anything. When I look back, I could’ve easily began building and refining as I gained new insights from the research conducted.

Moving forward: I'll do just enough initial research in the beginning, but I shouldn’t feel like I need to “finish” researching in its entirety before starting any actual design work. Research can be ongoing and occur simultaneously with design. Instead of seeing it as moving one piece at a time - see it as multiple pieces moving at the same time.

3. Don’t bite more than you can chew.

Scope creep plays a lot into this. Sticking with my risk management plan allowed me to stay pragmatic about what I was able to achieve in a given timeframe.

Moving forward: I should stick to the most simple, bare-bones product. If I have ample time, then I can add things gradually, and only when necessary.

4. Test as soon as you can. It’s important to get those insights quick and early. They should feed into your design direction.

I feel like I waited a bit too long before showing my prototype to actual users.

Moving forward: Next time, I will involve users into the design process as much as I can. Instead of seeing design and testing as two different activities that occur in phases, I should see them as activities that work in tandem. I will be thinking about how to get user testers the moment I start designing. Again, this goes back to the mentality about having multiple pieces moving at the same time.

5. You’ve got blindspots. Be aware of this.

After working on the product for months, having a fresh set of eyes and perspective can be really useful.

Moving forward: I will be more aware of my own biases and that other people will always bring a unique and fresh perspective. This can be very valuable.

6. It’s not going to feel “complete” and that’s okay.

I felt that the thesis presentation deadline was the day that my thesis should be fully finished. I felt that I needed Aida, as a product, to be “completed” since thesis was reaching its end. In hindsight, this was the wrong mindset. It caused a lot of unnecessary stress.

Moving forward: Accept that design constantly involves iteration and refinement. Products evolve and change all the time. Just because thesis is ending, it doesn’t mean I can’t continue working on Aida and improving it. Additionally, I will stop faulting myself for feeling like I’m doing something wrong, or if things don’t go smoothly. Accept, learn from it, and carry on. Don’t spend any time beating myself up over it.

Got a project in mind?

I’m currently available for one-off projects or remote positions.

Contact me