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.
The hypothesis
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.
My role
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.
Survey
• 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?
Some insights
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.
Challenges
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
The Prototype
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
Challenges
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.
Lessons Learned
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
