To improve their digital delivery, the Ontario Autism Program wanted to create a secure web portal for families. I worked in the discovery and alpha phases as one of two Product Designers, alongside two developers and a lab leader, to create a proof of concept and to prototype some potential features.
Prior to 2019 the Ontario Autism Program offered a needs-based service, where therapy was funded in full. Funding was given to service providers who in turn kept waitlists. In 2019, as an attempt to reduce wait times, the existing program was replaced with childhood budgets, a direct funding-based program where a child would get either $20,000 or $5,000 a year. Childhood budgets were eventually replaced with interim one-time funding while the government worked to develop a new needs-based program.
Throughout the numerous stakeholder interviews we conducted, we saw different user cohorts emerge based on when families and individuals registered for the OAP. We then created a series of service blueprints to better understand the different in journeys, interactions with the OAP, and the processes that happened backstage to support the user.
We interviewed nine individuals, covering a range of different regions in Ontario, languages, access to technology, etc. One noteworthy portion of the interview was having users stack rank a list of potential portal features. Beyond this we learned more about some commonly brought up pain points.
We workshopped with some project managers and program analysts from the OAP to create early personas and journey maps. Through user interviews we then validated (or removed) any of our initial assumptions to ensure these pieces always reflected our most accurate understanding of our users.
Throughout the process of creating determining what features to dive deeper into we worked closely with internal stakeholders to make sure we were consistently assessing the feasibility of our ideas and to keep everyone in the loop. This involved holding participatory workshops where we asked stakeholders to envision the flows themselves, as well as daily check-ins and biweekly presentations.
As this new portal was to be built and launched as soon as possible we had to decide on what features we would design for immediately, and what features we would want to recommend for a future state portal.
Ultimately, the three primary features we workshopped with stakeholders were:
Once the preliminary flows had been created we set out to design an interface that allowed for content to de displayed in the most easily understandable way possible. We continued to tweak our UI and content throughout testing sessions with users, and ultimately had over five different iterations for the interface.
Much of our users' confusion surrounding the expense form came from the ambiguity of the expense category/subcategory names. We ran through a few iterations of how we could most clearly display categories before deciding on very explicitly describing each category.
Through our interviews, we learned that questions related status of application and other milestones/important dates were abundant. Having different notices depending on where the user is in the process of acquiring funding to keep them in the loop proved to be a hit during our testing sessions.
User's did not enjoy forms that took up multiple page heights and required too much scrolling. We found that breaking down pages into well defined and brief sections resulted in an overall more plesant experience during user testing.
As we went through three rounds of iterative user testing we constantly made changes to our high-fidelity mockups. We found that a bulk of the changes made revolved around the wording and the content itself. Our high fidelity mockups were further developped into coded prototypes by the developpers on our team.
You can view and interact with three of the flows through the Figma files embedded below.
