Tech Matters recently released our sixth beta version of Aselo, our open source contact center platform that will modernize and enhance the capabilities of child helplines. Throughout our process, we’ve applied a number of practices for early-stage product development for a diverse user base: listening to users, using existing tools and making smart investments that will save time in the long run. Together, they help us toward our ultimate goal: to provide the helplines with better tools so they can help children in crisis.

Listening to Users

Aselo was born out of an expressed need from the 160-member child helpline movement that they needed a new technology platform. While Tech Matters possesses technical expertise, we do not run helplines and did not start out as experts in their product needs. Therefore, it was essential that we actively listen to helplines at each stage of our development process. We began the project by interviewing over thirty helplines to understand how they were using technology today, what was working for them, and what was not. With our partners at Child Helpline International (CHI), we selected a set of ten helplines for our beta program. These ten helplines were spread around the world and mirrored the great diversity of the overall child helpline movement. With each release of our software, we include instructions on testing new features and include a questionnaire for feedback. We send out additional questionnaires when following up on feedback or when planning a new feature. Especially during this time when travel for in-person conversations is not possible, electronic communication has continued to be vital.

While we have our own core product roadmap, feedback from our beta helplines also guides us. For example, there was broad consensus that helpline counselors need to see the number of callers waiting while they are currently handling another call. While Twilio Flex, our base contact center platform, provides a supervisor dashboard to display this information, counselors normally do not have access to this dashboard and they definitely can’t see it while handling an active call. We responded quickly, adding this new capability in our fifth beta release. Feedback from helplines after the release was very positive.

Using Existing Tools

For this new “Contacts Waiting” feature, we needed to update the number of people waiting in queues and the longest wait time on a real-time basis. Knowing that there was already a supervisor dashboard that did this, we sought to reuse existing functionality that provided this. The Twilio.org team recommended the Live Query feature of Twilio Sync, and we were delighted to see that we could use it to get real-time updates on the information we wanted. With some investigation and experimentation, we were able to use it in our Flex plugin (our custom code built on top of Flex) to provide a small widget that showed the queue sizes for each communication channel (with short-hand standing for the five main queues: voice calls, SMS messages, WhatsApp messages, Facebook Messenger and webchat messages) along with the longest wait time across all channels.

Using this existing framework was hugely helpful in building this feature, and we have already reused our learnings in that framework by building additional features on top of it. Taking a little time to understand existing tools, especially those within the Twilio ecosystem, has paid off well so far.

Closeup of Contacts Waiting feature

Contacts Waiting feature in context of handling an active call

Small Investments Early

Many startups focus on a single geographic market, such as the United States, and do not invest in making their product useful and accessible internationally. They defer work such as language localization or global deployment infrastructure until they’ve reached a scale where it makes business sense to do so. This is entirely understandable at the early stages when there is an opportunity cost to every day of effort. We have a different situation in that we are starting with an international network, and hence, we have a different strategy. When choosing our first ten beta helplines, almost all in different countries, we deliberately chose to work with a mix of countries with many languages. While four of our ten beta helplines have English as their primary language (including two in Africa and one in Asia), the other six operate in six different languages. And amongst our beta helplines, there are dozens of languages that people may use to contact the helpline. As this platform is designed for the benefit of the entire child helpline movement, where often the countries most in need of the service do not speak English, it’s not an option to focus on a large single market early and leave diversification until later.

We want to be keenly aware of the need for intense focus, as the acronym YAGNI (“You Aren’t Gonna Need It”) reminds us not to go too far in building for the future when getting an early product out the door. This remains a tension, and a constant tradeoff, yet we believe there are a few areas where it will be far cheaper to get an early start rather than face a last-minute scramble later. Two areas where this is important are localization and accessibility.

An underlying part of our recent releases is a localization framework, especially the ability to translate text in the user interface without code changes. If we continue to add more features and put raw English text into our code, we know that we will have to go back and factor all that out later. Rather than wait to do that last minute, we invested two person-weeks developing a basic localization model now. This is based heavily off of Flex’s UI localization and templating abilities, which helpfully already gets us close to where we want to go. We created a four-tier approach:

1. We start with the UI text provided by Twilio.
2. We then include a file that has supplementary text in a default language (currently US English) needed for our added features. This is bundled directly with the code to ensure that it can be accessed.
3. We then provide the ability to set different configured languages by looking up a remote file in the same format. This gives us the ability to update languages for a whole helpline, or for particular helpline counselors if the helpline is multilingual. We again reuse existing Twilio tools to do this, especially Twilio Functions and Twilio Assets.
4. In some cases, the UI language can be different than the language that the counselor may speak with a particular caller. For example, a South African helpline counselor may be using the interface in English, but may be texting in Zulu with a caller (we still call them callers, even if they are texting). We may want to provide a standard goodbye message or a survey question in the caller’s language. To support this, we have a separate set of language files to support external messaging, which can be set for each helpline contact.

This localization model is only a first cut, and there’s a lot more we can cover. Yet one thing it has unlocked for us is the ability to build in localization as we go. The additional effort to add text to a remote file rather than add it into the code when developing new features is almost zero, and conforming to this practice is enforced as part of our standard code reviews. This means that when we come to localizing for our first non-English helpline, there will be minimal engineering work required to do it. We will not have to force the helpline to wait for several additional weeks while we scramble to do a hacky version of localization. Even though every day matters in the early stages, we believe this small initial investment will yield larger returns in saved time later.

Another example of investing early is accessibility. As an organization, we value inclusivity and a big part of that is building accessible products for people with visual and other impairments. In fact, often helplines are good employment options for individuals with these disabilities. Yet accessibility — in particular, the ability to use a screen reader to operate the application, or providing enough contrast in the UI for people with low vision — is easy to set aside in the early stages of getting a product off the ground. Then later, retrofitting for accessibility can seem like a massive mountain to climb. As part of our recent efforts, we invested a week of one engineer’s time to learn about accessibility and how we could work it into our process. We also consulted accessibility experts (we have close ties to Benetech, which is a leader in accessibility) to get a stronger idea of what was needed. While we didn’t go back and fix what we’ve already built, we did document it quickly in our issue tracking system. We did, however, identify how we can work accessibility into our process, so that going forward we will build for accessibility. This included adding unit tests that test accessibility, as well as adding accessibility as part of our standard code review. While we still may face many challenges on the way to having a 100% accessible product, the early effort in understanding the problem and the diligence in maintaining that at a code review level should save tedious and wasteful time to retrofit accessibility into the product, and enable individuals to be able to work as helpline counselors despite physical limitations.

Our latest releases include multiple aspects of what we consider good product and software development practice: listening to customers, making use of available tools, and avoiding future retrofits with small early investments and working those practices into our development cycle. Stay tuned here for future progress and news!