Nationally, nearly 10% of all adults in the United States struggle with the English language, in some areas this can be much higher, up to 25% in large metro areas. And including all age groups this population is well over 20 million people. Federal guidelines guarantee translated materials and interpreting services for any organization that receives federal funding. Interpreters providing those services are highly qualified and certified individuals that get the interpreting jobs through agencies that pay them only 20% of what they charge and in spite of having full availability, they struggle to fill their schedule.
To solve this problem, I could create a solution that would help match interpreters and customers for interpreting jobs according to their location and needs, giving interpreters control of their time and payment and providing a voice to the customers when and where they need it.
Interlingua was my capstone project for the Springboard UX Design Course. As a result, I took on the role of user researcher, information architect, interaction designer, visual designer and usability specialist.
The design process
I followed the D School 5-step design thinking method
Finding Empathy. To better understand the problem, user’s needs and their behaviors, I conducted a mix of research that included a survey with 16 participants, 10 in person user interviews of 30-minutes, analyzed 15 competitors and a usability heuristics analysis of the 3 only competitors that matched the goals. The goal of the research was to gain a high-level understanding of the parts of the user journey and understand their expectations, challenges and frustrations. I aimed to derive quantitative and qualitative insights that would help answer some key questions.
• Why do customers use interpreters? • What information impacts their decision? • What are their challenges? • For how long and how often do they use interpreters? • What do they expect from an interpreter? • How do they communicate outside the organizations that provide interpreters? • How do interpreters get jobs? • How long and how often do they work? • What do they expect from a job process? • What do they expect from an agency? • How do they get jobs outside agencies? • What are their challenges?
More than 90% of interpreters use only agency to get jobs to give the scheduler as much availability. All participants stated they like the job because it allows them flexibility, but they would like more hours. Interpreters stated that agencies often have hundreds of interpreters in their pool because most of the appointments overlap between 8 and 10 am, which makes it hard to give jobs to everybody after that timeframe. Interpreters want control of their schedule and income.
Customers expressed their frustration. Feeling powerless and angry because they were treated like they are dumb, and insecure about if they are being treated fairly. They have to rely on family members that might not translate everything or limit their interactions to their communities. They want a voice, someone they can trust, almost becoming family They are grateful to interpreters and value their presence, advocacy and skills. Because of this, we can understand there is an unmet need of interpreters in their everyday life.
It is not because I don't understand their language that I am ignorant.
I have worked with many interpreters, but I like working with the ones that feel like family. I trust them.
My best interpreters share my same culture. They understand me
Affinity Map and Empathy Map were essencial to ensure that the user needs where always central through the process, I had to define both users: the customer and the interpreter. An empathy map to helped me portray the needs, actions, goals and frustrations of LEP customer. The affinity map helped me understand the interpreter goals and pain points. After laying them all out, I categorize them into three main themes. For the interpreter: income, agencies, schedule flexibility, types of work. For the customer, the pain points were around insecurity and frustration, and the main goal was trust and reliability.
Sonia: has been a full-time interpreter for 13 years. She had a full-time
job in hospitality when she first arrived twenty years ago with her brother.
Thirteen years ago, she got laid off and her father got sick. Now she travels
to Argentina three months a year to spend time with her elderly parents.
She needs the flexibility. Her brother, also an interpreter, does the same.
Delfina: has been in the United States for 14 years. She relies on interpreters for her children’s school and the medical appointments for the children and herself. Both children have ADHD and receive IEP services in school plus weekly therapy. Though her children, now teenagers, speak English fluently, they are not as fluent in Spanish. They help their mom when they are around, but communication is lost in translation. She tries to move in the Spanish speaking community to avoid communication in English.
The User Stories and MVP roadmap provided insights on how the product could be used, the minimum features that could be needed to achieve goals and fulfil their unmet needs and understand other needs that could be solved in future iterations.
To understand the end to end experience, I had to map all the
touch points for the interpreter AND the customer journey to make
sure all the steps were accounted for in a mobile experience
At this point it was clear that the solution had to go hand in hand for both users. And though they shared common touch points, their experience, goals, pains and gains were different. And though I designed the platform for both, the first iteration of testing was only with the interpreter’s view, leaving the client’s experience for a following round
The categories came together through the MVP and the stages during a
interpretation session. Based on the outputs of the study,
I developed the sitemap and information architecture, as well
as the key user flows.
Developing and iterating the site map was extremely helpful to understand the experience, define the user flows and later to design the screens; especially with the complication of designing a solution for both users.
It was difficult to test the low fidelity sketches because it felt putting out something unfinished to be judged, but the feedback was very helpful as it showed quickly the screens I was missing and the ones I didn’t actually need. I also learned the importance of testing early and fail fast. Using Google Material Design library proved to be incredibly useful to not reinvent the wheel and spend too much time designing the elements, when my goal was to test the concept or the flow. Sketch component library feature was also extremely valuable, even if I spend a lot of time creating the library, because it streamlined the workflow and allowed the changes through the iterations to be solved very quickly in all the screens at once
Though I had experience with Axure and the adobe suite, I used Miro, Sketch, Marvelapp and InVison to build the create and build the prototype. Sketch was a fantastic tool that streamlined updating the design though the libraries and symbols. InVision didn’t have all the features Axure has and did not make screen replacement easy through test & iterate, but as the design thinking method promotes, build fast, fail fast, redesign and test again. At the end InVision allowed to build a testable prototype that gave me the learnings I was looking for. Using Invision, I created prototypes from the high fidelity mockups and I conducted 3 usability tests with set tasks and scenarios for each of them to go through.
After validating the user flows with the wireframes, I prepared the elements for the final design. I gathered elements that had the feeling I wanted to convey. A look and feel of multi culturality, a hint of networks and connections, a sense of collectivity. For the first round of visual design, I produced a Style Guide that included typography, color palette and UI patterns.
Once I had set some objectives for the exercise, I ran moderated usability
tests with 4 participants. The prototype was used on a mobile device
in a home setting to help with contextual observations.
Participants were asked to complete 8 tasks. I wish I had defined
the objectives and tasks ahead of building the prototype, as a
lot of time could have been saved building flows that were unnecessary
for the test. Lesson learned. Only build what you need to test.
Usability Testing Scenarios
You are an interpreter, using a platform to help you manage your jobs. Tasks:
1. Your client wants you as an interpreter for his doctor appointment and asks you to be his interpreter. Make sure you take the job.
2. Find a job to include it in your schedule.
The day of your client’s doctor appointment initiate your morning job and continue the process until you complete the job.
3. The Doctor says the test he is running could last just over 2 hours. Make sure your scheduled time covers the test.
4. The test finishes briefly after it was extended, and you can stop the job
The main challenges about this project was to design a solution that would solve the interpreter and the customer needs, having both of them very distinct goals, pain points, and over all experiences The other challenge was the complexity of the actual interpretation session, that involved the possibility of paying by the minute, and having both parties to agree on start, extend and end. Other apps in different business charge by the service, which is tied to a duration. And either the customer is present or not, he or she has to pay.
I really enjoyed all the parts of the project. Though some more than other (design over research), I am glad to have done it all. I see the value in each part, And I can talk about all the stages with confidence. • Test concepts. Be flexible to change your initial hypothesis • Test early and often. It will guide you to the best solution. • Zoom out, zoom in. Think wide, consider the end to end experience • Quick sketches are invaluable. To prevent wasting time and spend time where it needs to be spent • Build what will fill an unmet need not what you want, or it will never be used