Integrating a unified help centre across four user personas and many product modules
Let us paint a picture. Toddle is a platform that helps educators (IB AND other independent curriculums) streamline teaching and learning. Everything that happens in a school that adheres to rigorous IB standards can happen on Toddle. This applies across student groups — early years (Primary Year Program), middle year students (Middle Year Program) and DIploma students (Diploma Program).
One can only imagine the diversity of use cases that we were dabbling with- catering to the needs of students across these programs, teachers and for curriculum specific modules. Through a unified help centre, we wanted to fill any gaps related to discoverability of features, any issues that users faced with completing actions and make user flows more accessible to all the user personas that we were dealing with.
Once the entire help centre was set up, we were faced with discoverability and contextual help. We wanted to integrate these resources into the daily user flows, whenever they felt stuck contextually. Read on to know how implementing a simple feature made all the difference.
Taking a close look at user personas:
Educators: were concerned with modules designed for PYP educators. Plan units and add learning standards to them, define the weekly and yearly plans and customise how they will look. Educators create tasks and assignments of various kinds (Learning experiences, quick tasks, FA and SA), assign them to students within and across classes, evaluate submissions and grade them using single point rubrics, checklists, remarks, grades and scores, send feedback. They also collaborate with other teachers on unit plans/task creation/interdisciplinary units, with students on their PP, CP or CAS, EE, TOK which are exploratory and iterative projects.
Administrators/School coordinators: Concerned with overall actions such as academic setup (setting up academic years, terms and periods), school roster across curriculums (classes, students, teachers, family members visitors), managing announcements, configuring classroom functionalities, class stream, attendance marking scheme, monitoring progress and curriculum coverage, adherence to IB, IBIS forms, and other administrative tasks. Administrators are also responsible for auth and evaluation by external IB visitors and registration on IBIS and other centralised portals. They manage theses and curriculum specific projects and track completion of the same: including MYP projects (PP, CP and SAA) and DP projects (CAS, EE, TOK).
tracking progress/insights
adherence to IB standards by looking at horiontal and vertical insights of the curriculum
Central actions- announcements, approving attendance excusal requests, managing progress report templates and sending them out to family members, managing transcripts, etc.
Students: submitting assignments in multiple formats, viewing class content, class discussions, viewing their calendar and attendance, timetable, progress reports,
Family members: an active part of the student learning journey, viewing student attendance records and timetables, progress reports, student work, sending in excusal requests. Family members used the platform through educators in some sense in that we could not directly coalesce with them, but educators were their points of contact. So we had to help educators understand the family flows really well.
The process
Defining the roadmap
Before jumping right in, we defined a roadmap so that our efforts found structure and guidance at each point in the process
- Defining the internal architecture
2. Assessing needs by understanding user pain points so that more resources could be directed towards filling gaps in information
3. Defining user journeys based on personas
4. Defining the skeleton of each article as well as the unit-level experience to ensure that users found precise answers they were looking for and could also get all background information (through related articles and embedded videos)
5. Templatising the voice and tone of articles, their coverage, and design prinicples around embedded screenshots and text.
6. Enhancing discoverability with a simple feature that made all the difference
I. Internal architecture
The first step was to create an internal architecture for all the existing modules on the platform, in an attempt to capture the spectrum of needs we were dabbling with. I mapped all the existing modules on the platform. This was done as a precursor to figuring out the best way of assimilating information and in what way might organise information. We hoped to achieve a few goals with this exercise:
Define the granularity of each article on the help centre — what level of depth could we go into
Decide on the number of articles under each module — identify common articles across modules so that there is minimal duplication of effort.
Determine how information would be classified and define the information hierarchy using existing tech stacks and limitations of the supporting medium (Zendesk).
II. Assessing user pain points to bridge information gap better
Owing to a platform which had many intersecting user flows and that many features and functionalities, we wanted to ensure that we definitely address the most glaring user pain points first and bring depth to those, while simultaneouly covering all the possible journeys there are to cover. Our approach followed a T-based structure — coverage across all use cases, while ensuring more information around the common pain points through more articles and videos.
How did we figure out the gaps:
- Speaking with the School success buddies, who are the POCs between the platform and schools/users. We drew insights on the most commonly received questions and distilled insights on which modules, functionalities and user group do we require more support with specifically. The buddies could help us understand the pain points of educators and family members really well.
- Conducting user research: We identified schools across the three curriculums and reached out to educators and students. We asked them open-ended questions and took their lead into them speaking about modules they were facing difficulties with. We realised that unit planning, and classroom functionalities were a point of concern. And therefore we had to ensure that the articles pertaining to those were really thorough. We ultimately decided to have product walkthrough videos for those, in addition to step-wise articles for each role.
- Chat support: We analysed chat support data on Intercom to understand the most frequently asked questions, and which modules did the FAQs accrue to. This helped us with specifically drawing from questions and incorporating pointed answers to those questions in the resources we created — placing them at the forefront.
III. Defining user journeys based on personas
Information had to classified at three levels — the module, the user and the curriculum. Zendesk allowed only a two level hierarchy so we could lead with the module, or with the user. Torn between a module-centric and user-centric approach, we decided to lead with a user centric one. This basically meant that on the help centre landing page, a user would have to select one of the roles — Educator, Administrator, Student and Family member, and view information module-wise within that.
Further, a user could only access the help centre once they had logged into their account. So, the curriculum would be taken care of when the user would sign in as they would be tagged to one or more curriculums in the school setup roster. Hence, once they were in, the articles that they saw would be the ones that were tagged to the curriculum a user was also tagged to.
At the micro level, once a user was on the help centre, s/he can select the role they want to see articles for, then the module or features they particularly want help with. This was a conscious decision as a particular user could want to know how the flow looks like for another user group — for instance when an educator wants to see what students will see on their end when they make submissions or how family members can submit attendance excusal requests.
IV. Defining the skeleton of each article and unit-level experience
After some research around best practices on help centre articles and exploring possibilities on Zendesk, we came up with a skeleton for each article. The following were the considerations:
- Product walkthrough embedded at the top within articles for those which received a high volume of queries or were complex modules with a bunch of functionalities (CAS, EE, TOK modules and progress report modules).
- Breadcrumbs at the top of each article for users to navigate back to the previous page easily in case they had opened the wrong article. This would ensure a painless experience as they won’t have to start from scratch.
- Guidelines around embedded screenshots so that the volume of text was split up and accompanied by visual aids to actually contextually place what the article spoke about.
- A navigation scroll on the right panel for users to quickly jump to a previous or subsequent section and not have to manually scroll till the top or bottom.
- Related articles at the bottom of each article so that users could look at related flows. For instance, if a user was reading about how to fill progress reports for MYP, related articles could show how to set up a progress report template. This would be an indirect nudge for those who were learning this process for the first time and might be generally unaware that the administrator has to configure the progress report template for particular sections to appear.
- Community comment options at the bottom for users to add in their comments and feedback so that they are constantly in touch with users and articles can be informed by real-time feedback, if any.
V. Templatising the voice and tone of articles and design principles
Product help articles were to be the voice of the product. They would be direct communication between the product and the users. To ensure consistency of voice and tone, I created specifcic guidelines and included them in the design system. This included:
- Templatising the article structures: It was essential to ensure that users could expect consistency across articles. So we implemented a step-wise structure, with notes pointing out salient features wherever necessary. This made articles readable so that whenever a user opened a new article, the expected structure was the same- so that they didn’t spend time figuring that out. This was also essential from an internal standpoint so that irrespective of the author, articles could maintain a unified voice of the product.
- Screenshot design: After experimenting with a bunch of colors , we went with yellow borders to ensure that the screenshots were as readable and amenable as possible against light and dark modes, and there was minimal blurring. We maintained the curvature of edges that was used across our design system in icons, so that these articles spoke to our design language and identity, and weren’t separate from them.
VI. The ‘Question mark’ icon enhanced discoverability
Once all the heavy-lifting was done and we had successfully released over 150 articles on the help centre, the analytics did not reflect the amount of usage that we were expecting. Not even 1/20th of our users were accessing and using these resources.
This was because this feature had poor discoverability as it was not visible upfront.
I did some research on best practices around product help.
