Client Organization Background
Child Witness Centre (CWC) is a Kitchener/Waterloo based Non-Profit Organization focused on building resiliency and creating strong futures with children, youth, and their families in our communities. CWC provides support, education, and advocacy for youth and their families as they journey through the criminal justice process. This includes planning, coping strategies, legal documentation support, etc. In late 2022, CWC was forced to start a waitlist for the first time since their inception in 1981. It is devastating because gaps in their service have serious consequences for children and their families.
Problem Space
The Child Witness Centre currently relies on manual processes, including emails, phone calls, and Excel, for coordinating and tracking onboarding tasks for both volunteers and staff. One notable challenge is the difficulty in monitoring form expirations, particularly with volunteers on a rotating basis, due to the absence of an automatic reminder system. This manual checking process is time-consuming. Additionally, the verification and updating of information consumes several hours each week, diverting resources from the organization's core mission of bringing in funding for programs. Moreover, the organization depends on manual emails and phone calls to track progress and ensure the completion of required forms, contributing further to time inefficiencies.
Objective
The objective is to create a web application that streamlines all of the administrative work and hence frees up time for the staff to focus on bridging the lack of funding they have. This will be a 2-profile web application with the main users being Staff (Admin) and Volunteers (Users).
Define
Constructing User Flows
We started by defining the information architecture of our application, based on the use case scenarios and functional/non-functional requirements. Although we were unable to conduct user research directly, the PMs informed us that the users were not that familiar with technology, so we ensured that the flows were as intuitive and simple as possible.
Information Architecture (IA)
Using this architecture, we then built out the individual flows for admins and volunteers.
Admin Flows
Volunteer Flows
Ideation
Sketches & Moodboard
Keeping in mind the nature of our user group, we created brainstorming sketches based on our user flows.
We also each constructed moodboards to guide our ideation process:
Ideation
Low Fidelity Mockups
After brainstorming ideas, we created low fidelity mockups for the homepage (admin), document directory (admin), invite user flow (admin), and onboarding flow (volunteer). We targeted only certain flows and screens so that we could aim to hand off some high-fidelity screens for developers to start working on.
Design System
Defining the Design System
We created the design system prioritizing simplicity and readability (i.e. high-contrast colours). The design tokens include text styles, colours, and spacing; the components include input boxes, different buttons, documents, and toast messages. For efficiency, the developers also chose to use the ChakraUI library, so we based our designs on some UI elements from there as well.
Design Tokens
Components
Unfortunately, the client cancelled this project due to reasons outside of our control, so we were unable continue this project after the cutoff. Because of this, we were only able to complete the high-fidelity prototypes for the "create user account" flow (admins), onboarding flow (volunteers), and document directory (admins). The screens are as shown below:
Create User Account (Admin View)
Onboarding User (Volunteer View)
Document Dashboard (Admin View)
Next Steps
Here are some things we were on track to do if the project hadn't been discontinued:
Finalize Hi-Fi for Dev Handoff
Had the project continued, we were about to hand off the above flows for development. These prototypes would go through a few more rounds of design critiques and feasibility checks with developers before their full design completion.
Design Home Dashboard and Other Flows
We had defined all the user flows for the platform, but we were far from designing their actual screens. After handing off these flows to dev, I was to tackle the home dashboard for admins -- the screen they would most likely see the most.
Key Takeaways
Feasibility Check
Working on a project with developers and a real client, there were several constraints the designers had to follow to ensure feasibility. For instance, since we were unable to host personal forms on Blueprint's servers, designers had to reconstruct the user flows and information architectures accordingly.
UI Libraries
This was my first time working on a project where designers relied so heavily on a UI library for our design system, namely ChakraUI. I learned that making good use of existing libraries makes the design process much more efficient, and allows designers to focus more of their time on the more significant areas of design.
Although this project was short-lived, I learned a lot of valuable lessons from working with my fellow designers, devs, and product managers. I was able to experience working on a real project for a real client for a good cause, and I am excited to tackle the next project at UW Blueprint.
