On being user-centric & community driven with our open source product — Glific

Brief intro: Glific in an open source, two-way communication platform(think WhatsApp chatbot) for NGOs/nonprofits to interact with their communities at large scale. NGOs believe that they are not very tech savvy. We want to make it easy for them to adopt and use relevant tech solutions.

We aim to look beyond merely building technology and actually helping our users to empower their efforts using technology. This requires us to listen in really closely and be connected to their needs and challenges. To make this happen there’s no other way than to be user-centric and community driven. Here are some of things that we do:

Focus on design

As a product designer who is passionate about designing impactful products, it’s quite amazing that our open source product has a commitment to good design. This has persisted from the early days when we spent time talking with many potential users to validate the product idea and learn about their pain points. We continued to observe the users while they used the platform. We’ve obsessively wanted to create an intuitive application that looks good and is easy-to use. By centring our designs to how we expect users to use Glific, it saves up on extra support effort required to train users on the product, making it as self-serve as possible, helps us understand any product challenges and fix them faster.

Building for the majority

We’re focused on building the platform for a larger community and avoid building something uniquely for 1 or 2 of them and being pulled from various different directions. Here’s also a nice tool by Kailash Nadh of Zerodha to influence your decision about building a new feature. Our product team streamlines the features which should commonly be built for a larger community members. And fortunately for us, this approach is also supported by philanthropic grants who resonate with our philosophy and mission of the product we’re building.
In my personal experience it’s been difficult to say no to a customer or a potential user, but in the interest of community and for the larger picture, it was worth saying no to certain requests and focus on the ones that more than 1 person needed, however small that might request might have been. And that is also where being open source helps us navigate through this minor glitch in user-centricity by letting people solve their individual needs on their own.

Community interactions

For a long time under the umbrella term of community interactions it was mainly our product team interacting and engaging with the customers without much interactions among the users of product itself. Until, something changed that. It was when we started our in-person event starting with Education cohort where various members of the community involved with the product — funders, customers, software development partners joined in. That changed the level of interactions among the community. It’s still not easy to build common cords among organisations and people because they may have different goals and priorities at different points in time but it’s worth investing in community development and enabling people to exchange knowledge and learn from each other. We’ve seen that it massively impacts product adoption and our significant focus on the community has been a driving attraction for many.

I feel that one hurdle that a communication platform may cause to community interaction is that people see it only as a support tool and visit it only when they need help. Since they don’t check it out more often than they should, they might not as much as we’d like, be able to help others when they need. Do we need to think of an incentive model to enable people to help others a lot more and let it thrive sustainably? or do we simply stick with the pay-it-forward model.

Support, documentation & knowledge sharing

Support: Due to the nature of the audience we cater to, we felt the need to have a team member hand-holding our users on their way to adopting Glific. We try to be as prompt as we can because we understand that being stuck while using a product on which the entire program depends can lead to a lot of waste and seep energy. And also because our users may not be too tech-savvy.
Documentation: We try to make Glific as self-serving as possible through extensive documentation of features using docs and videos in addition to answering support requests 24X7. Users can find their way around any stumbling blocks using the help docs.
Knowledge sharing: Whenever we work on something new, the team writes and shares about it with everyone interested in it. This also extends to our customers writing and sharing about their experiences and learnings so that others who come after do not falter in the same path.

Everyone is customer facing

While we have a support team that interfaces with the customers to solve their day to day challenges and understand how they use the platform, their pain points and goals, however, everyone else including the design and engineering team also interact with the customers almost on a daily basis. I’m glad to have had the opportunity to handle support in the initial days(when we didn’t have a dedicated support team) which opened a world of insights and acted as the much required usability testing interviews. There is no layer between the team and the customers. This allows everyone in the team to understand the problems that our users face in their context and offer relevant help when needed. It makes our support and the product more effective and user-centric and each of the team members can vouch for our users’ interests.

Anything else we should we doing? Or if you have questions on any of the practices, please leave a comment below

Credits:
Donald Lobo, Tech4Dev and ColoredCow for building a culture that enable these practices.