If you’ve known me for a while, you would know my interest in side projects. I like helping out anyone who needs a hand, especially on anything focused on social change.

This article’s me trying to walk you through one such amazing experience. It’s also a peek into the frustrations and the mistakes I made and reflections on how to do some of these things better.

☕ P.S. This one’s going to be a long read, would recommend you grab a cup of chai/ coffee. ️

How it all started

Around a year ago, I saw a post in one of the many design groups I am part of on Facebook. It sounded like the person was working on a fascinating problem. I felt could some spare time and I’d be okay with supporting them. (Regardless of whether or not I’ll be financially compensated for my time.)

I reached out to Bradley with a quick intro (interestingly, within 20 minutes as the screenshot suggests.) My usual pitch involves a lot of description, and I expressed my interest in helping out for the project. She replied and I got to know a couple of others were already keen and had reached out.

It was good to see a solid problem getting the attention of many peers. However, I was also bummed out as I had never been exposed to this problem space so far in my career. The situation sounded very intriguing and I still remember a lot of the keywords used in the description. I wanted to help.

I acknowledged the wait, and as life would have it, was contacted again by Bradley. She was able to get a service designer but they still lacked visual design support, so I excitedly hopped along.

TL;DR — The situation

To avoid writing about the mundane play by play, I’ll summarize the whole journey in a couple of paragraphs to the best of my ability.

The (messy) problem and context
Migrant and indigenous communities in the west (Europe for the purposes of our project to be specific,) currently have a lot of problems in getting access to relevant healthcare. One major cause of that is a language barrier. Inability to communicate leads to a lot of wasted time and frustration at best, and incorrect treatment at worst (due to misdiagnosis.)

Currently, institutions attempt to mitigate this problem through in-house translators. Unfortunately these only cater to a minority of cases where the non-English speaker is speaking the ‘common non-local’ language. From the research we know there are less than about 10 languages which are sufficiently covered.

There are tech based solutions like Google Translate, which cover about forty languages, but unfortunately the quality of the translations for non-mainstream languages is questionable. In this context a bad translation can actually cause a lot of problems.

Product
This platform aims to build a database for translations in over 7,000+ different languages. These will be crowd-sourced through volunteers. In most cases, these will be medical students, in training, or doctors.

The end goal is to empower doctors and first level medical attendants. The translations from this tool will assist with diagnosis and and eventually treatment. This was a noble direction to pace towards. However, tech was just one of the many mystical creatures the team had to overcome in order for this to become a reality.

Issues with what was done so far
The project has been going on for a while. The current prototype had already been developed by a passionate team of developers. However, when it got through to the users, there were fundamental usability issues. Unfortunately, this meant that the project in its current state wasn’t good to release. The team was advised to get a ‘UX designer’ to support with the ‘User Experience.’ This is what led to the initiation by Bradley which you see above.

Lack of awareness of how tech works
Bradley and the team’s journey started with a problem to solve (the ‘what’,) without a lot of visibility on the ‘how’. Like any epic with countless obstacles, tech was a beast of its own. She is an academic by profession, and has a noble cause at heart. However, the dev and product side of things were something which was missing as it was an unknown unknown. This included things like platform security, web standards, engineering best practices. There was a need to understand how some product decisions may completely break as the platform would scale.

Starting fresh with a blank slate

Alright, so you have a bit of context of what all was happening. Now it’s time to shed some details on some of the things which we did when ‘UX’ was brought into the mix. Luckily, for a few weeks, we got the support of Rose*, a seasoned service designer. We worked together to debrief and gather everything we knew about the project. We got to work and probed ourselves to start asking some fundamental questions.

(*Full name hidden for privacy.)

What were our objectives? What became our new objectives?
The end goal of Twig was to become a volunteer driven platform which medical professionals could reference from. This would help with their day to day diagnosis and treatment . The objective remained the same, but I feel we broke the end goal into a series of micro tasks which helped us march in that direction. Our ‘new’ objectives intended to reduce the scope just enough for us to release something small. This had to be a good start, as it helps validates our hypothesis. In tech terms however, it wasn’t the traditional MVP.

Who’s our user?
Our platform is designed for anyone who can be categorized as a healthcare professional. However, in order to have better focus, we have narrow the focus to students who are towards the end of their professional education. It’s a platform driven by volunteer medical translations. According to the collective research we had gathered, they were best suited for the role. They were ambitious in terms of giving back, had the time and competence for it. More importantly, this could become part of the extra credit which can support with their overall education. It’s a win-win for everyone.

What do we know about the problem so far?
As mentioned earlier in the writeup, Twig went into development but didn’t see the light of day for long due to some core constraints. It was this realization which connected me to Bradley. She’s been working in this space for a while, and is very clear on the ‘Why.’ The scale and complication of the problem is clear. We know that there aren’t a lot of solutions currently and the existing ones are missing a lot of the fundamentals. These include basics like a coverage of languages, as well as more nuanced needs like the contextual translation of medical terms.

What do we want to learn?
With learning to unlearn as the foundation of what we’re doing, we wanted to continuously update our world views. We wanted to learn about our personas the best we can.

This includes the volunteer and what a day in their life looks like.

This includes the doctor and how they would eventually be using the translations in their day to day.

This includes the indigenous community who are eventually going to be recipients of the donated translations. It’s extremely important that they’re able to understand the content for all of this to work.

Lastly, this includes us, our team and all internal stakeholders working together to make this work and become something meaningful.

What are the important questions we need to ask?
We believe this will be a never ending list, but there are core questions for which we keep on seeking answers. These also help us update our own understanding of the situation. Some of the questions we keep on coming back to:
- What problem are we trying to solve for?
- Who are we doing this for?
- Why’s it important to do so right now?
- How will the user interpret this?
- Is there an alternative approach to doing this? Is it really important to do this in the manner suggested?
- How do we know this will work?
- How can we validate this? What feedback do we have?
- How does this happen currently? What other things are they used it?
- Where does this belong in the overall flow? How does it help the user in the grand scheme of things?
- Again, what problem are we ACTUALLY trying to solve?

On a glimpse, the nature of the questions is similar. We really want to understand the root cause of things, and evaluate the cost against the potential benefit from doing/ not doing something.

Collaboration, tooling, and the ‘design’ process

Twig’s set a great example for teaching me why some popular ways to collaborate work well, and which ones need some revision. Just giving the team a high level overview on how tech generally works was followed by a bunch of ‘ah-ha’ moments. We tried to plan our phases and next steps. Introducing agendas in meetings was not just specific to tech, but we felt it really helped us work better and more efficiently. We were split across 3 locations and timezones, regions and cultures. Given limited/ no budgets, we obviously had a bias for free tools we were already accustomed to.

A summary of the tools we used to work together:
- G Sheets — Found this one the most surprising. Generally served the purpose of what otherwise would be done on Miro. Helped us compile everything quickly and the tabular format ensured we keep it brief and factual.
- GMail — Comms/ ‘official’ stuff. We didn’t opt to have a realtime platform like Slack because all of us were not really working on Twig all the time. Email was surprisingly an okay mode of communication which everyone was already used to. For times where more active communication was required, we’d jump on a quick call.
- Figma — Mockups / ideation/ workspace/ sandbox. As always, helped me visualise things to present during meets and get the team to drop their feedback and comments as well.
- Meets/ Zoom — General discussion, meeting, bottlenecks, walkthroughs. We had to switch to Zoom in some cases

Learnings and reflection

I’ve had this bias for offering a helping hand to those who do their fair share in expressing interest and seriousness in whatever they’re after. Besides the social impact, a great incentive for me has always been reflecting back on the process and learning new things. I’ve tried to list out a bunch of facts I have been reminded of, as a result of this journey, with more to come as time progresses, which I’ve categorized by theme.

Tech, digital products, and processes:
- A LOT becomes irrelevant and sounds stupid when you remove profits out of the picture. Naturally, that brings sustainability at risk, but that’s not the focus at this time.
-Not everyone who wants to build something meaningful has access to venture capitalists (or in fact even aware of their existence.)
- Working with PHDs and medical experts from academia is going to be world’s apart from the tech industry. The type of context required is very deep as compared to the counterpart in tech which we’re used to, in relative terms, of course.
- All industries create silos in order to emphasize and the appreciate the nuances. The sense of other-ing, however, magnifies as well. This becomes a problem during onboarding external stakeholders.

Communication and collaboration:
- Working on Twig made me wish I could speak a few more languages. The languages which we see on mainstream media is less than 1% of total languages spoken across the globe (7,000+ lanuages!) View them here. - Not everyone is familiar with how tech works and the cadences it brings along the way.
- Communication is key. Not only the act of communication, but also sharing knowledge and context where it’s otherwise missing. You’ll also have to keep coming back to the foundations.
- Have all major discussions in real time and on-call. Video calls make it even better. NOT LOOKING YOUR BEST IS OKAY.

Design, values, and personal growth:
- There is an unexplainable feeling of fulfilment which you get when you help someone and see their vision come alive.
- Figma is beyond a design tool. Working on Twig is where I’ve really stretched my understanding of Figma as a tool for facilitation.
- Communities across the globe can use all the help they can get to make the world a better place for them.
- G Sheets is a solid tool in terms of being easily accessible and enabling you to start something.
- It’s a surreal feeling to see something you create/ re-create from ground up, actually being used. First hand feedback from actual users and them appreciating it is a high on its own, and it’s addictive.
- Resisting pixel perfection is difficult, but necessary for understanding what truly solves the problem at-hand.
- A lot of folk outside of the tech space don’t have much information of the science behind good experiences. The onus is on us to proactively find such people and reach out.

What’s next

Development is still underway, and it’s still far from complete, but we’re making steady progress. We’re hoping to get more traction in terms of grants. These grants fund the project and support what Bradley and the team are up to!

If you’re an EU based organization which can support the team through a social development grant, feel free to get in touch with me or Bradley.

Visit our makeshift website here. Get a summary of the action through the out-dated kickstart campaign here. View more details on the official chain of events on the about page here.

View Bradley’s peer-reviewed paper here:
https://www.emerald.com/insight/content/doi/10.1108/IJHRH-01-2017-0004/full/html

Major Kudos to Bradley for leading this, and giving me permission and feedback to publish this.