Texas Civil Rights Project
Emergency Legal Aid Hotline
Background
I was assigned this project through Trestle Collaborative, a progressive tech consultancy for which I was their first UX Design hire. The Texas Civil Rights Project is a non-profit organization of lawyers and advocates founded in 1990. TCRP gained national attention for breaking the news about families separated at the border by the US government and fighting on their behalf. They have been leaders in the immigration space, as well as in voting rights and criminal justice reform.
Client
TCRP's Race and Economic Justice department wanted to stand up a hotline to provide urgent bilingual legal advice to migrants and their families in Texas in response to a recently issued Executive Order but didn't know where to start when it came to software.
Context
Because of my experience in both UX and CX, I was brought in to conduct discovery and provide a short list of software recommendations that would best support those at risk.
Being from Texas and a child of refugees myself, I felt honored to be a part of such a meaningful project.
My role
Scope
I was the Lead Researcher on this project working directly with TCRP's IT Specialist. I delegated responsibilities as follows:
Me:
- Create the research plan
- Design the interview guides
- Run the interviews
- Facilitate the synthesis and evaluation process
- Create and present the final deliverable to the client
Stakeholder partner:
- Facilitate communication/scheduling with the client
- Take notes for and de-brief interviews
- Perform half of the evaluation research
Overall, I really loved working directly with an internal stakeholder throughout this sprint. Their insight/expertise was invaluable.
Team
Week 1: Kickoff & Recruiting
Week 2: Interviews & Synthesis
Week 3: Evaluation & Output
Timeline
Research
Whatever software I recommended would need to accomplish both the end users’ needs and conform to TCRP’s capacity.
Project Goal
1. Determine what TCRP's goals are and how they will measure success.
2. Identify who the end users are and what they need.
3. Understand the scope of support TCRP is able to offer and how that support will look.
Research Goals
We conducted interviews with 5 people including internal stakeholders and external partners who could share their experience working with migrants at the border.
Due to language barriers and privacy concerns, we decided it wouldn't be possible to interview the end users themselves, so I prioritized speaking to people who had experience directly helping them.
I asked more procedural questions (i.e. budget, timeline, size) via a survey that could be answered asynchronously.
I also tapped my customer support network to get leads on relevant vendors.
Methodology
Synthesis
Since we weren't building a design from scratch but rather recommending an existing solution, I approached the synthesis process more like a requirements-gathering exercise.
To do this, we constructed 3 main use cases as we went along. Here's a brief overview of each one:
1. Impacted Individual - A shorter interaction that may be the only one, limited in time and access to technology if calling from a detention center
2. Family Member of Impacted Individual - A longer interaction requiring asynchronous investigation and follow-up, likely international
3. Researcher - Information tracking through custom dashboards for understanding new developments on the ground and formulating a broader legal response
I then split data on each use case into 2 experiences: the end user experience and the internal support experience.
Use Cases
Evaluation
Feature Prioritization
Having worked at Zapier, an app for integrating from a library of 2000+ apps, I had a lot of experience dealing with different app categories. So it didn't take long for me to understand that we were looking at features that could be found in Ticketing, VOIP, and CRM software.
Before choosing software to evaluate, we needed to decide:
- Into which categories do most of the features fall?
- Do we want to integrate 3 different systems together or should we find an integrated solution that combines all the features we need?
- What about a ticketing system with built-in calling but no CRM?
After bucketing the features, we determined that we were looking for software with:
1. Strong ticketing capabilities
2. An integrated VOIP feature for dialing/receiving calls
3. A lightweight contacts feature without the typical sales CRM frills
Keeping these features in mind, my partner and I searched the internet for different vendors in each category and evaluated them based on what we were able to find on their websites. For the stronger options, we scheduled demos to fill in the gaps and to evaluate more subjective/flexible variables like pricing, onboarding timeline, support, and UX/UI.
Market survey
Recommendations
After completing demos with 6 vendors, we concluded with a short list of 3, which included both all-in-one solutions and integrated solutions to meet the feature requirements.
We disqualified vendors that required end users’ access to a computer/internet and complicated UIs that would be difficult to onboard quickly.
Deliverables
The decision makers decided to continue conversations with the top 2 vendors we recommended. My partner and I made intros to the respective vendor teams and sat in on follow-up meetings with both. I then handed the reins to my partner to close out those conversations and begin implementation.
Deck & Shareout
After confirming expectations with the decision makers, I created the final deliverable, which was a Google Slides deck (presented over the course of an hour with Q&A).
Something I kept in mind was that this deck would serve not only as a presentation aid but also as an artifact referenced by all stakeholders involved in decision making. As such, I ensured that the deck itself was as informative as possible:
- Executive summary
- Overview of our use cases (and insights from discovery)
- Infographic showing use cases translated into features
- Summaries and screenshots of 3 final recommendations
- Recommendations comparison matrix
- Next steps
- Q&A
Result
Challenges
Surprisingly, scheduling demos - particularly on a short timeline - was one of the most challenging parts of this project. I figured sales people would be eager to hop on a call but after asking my sales friends for advice, I learned that the email domain I put into the demo request form plays a big role in whether I will be qualified. I was using my Trestle email, which would show up as a tiny non-profit, despite representing a much larger organization. I figured I was probably being DQ'd on size. So I pivoted my strategy to asking for demos through different channels (like support) and stressing the timeline/budget, which led to a lot more response.
Scheduling Demos
Something I'll do next time is share a mini-deliverable with the decision maker right after synthesis (and/or ask about the decision maker's preferred level of involvement before beginning research). This could've helped me come to demos prepared with more specific questions and create a more focused final deck.
Early feedback
I acknowledge and apologize if the use of the word migrant carries a negative connotation for you. There is a lot of debate developing over the correct terminology. I used the term migrant in accordance with UNHCR's definition, which includes people leaving their usual place of residence for any reason.
Language