York U

Product Design
Project Overview
At the Learning Technology Service (LTS) at York University, I worked together with another designer to create a new online tool to demonstrate the department’s capabilities to faculty and staff. The project involved our team exploring user-centred design methods to understand what the potential clients, shareholders, and support staff, would need/want from their online service.
My Contributions
Usability audit, User research, Requirements gathering, Personas, Wireframes, Design system documentation
Outcome
The website was meant to be made for clients, but we forgot at times that a key user was our support staff as well. When backed into a wall due to our lack of available resources, we pivoted to who on our team had the most contact with our clients. Picking the brains of our support staff helped us see what we could do to support not only our clients, but them as well.

Project Summary

When joining the LTS at York University, the managers of the department tasked myself and the other designer to take on a self-driven project of overhauling their online presence. They knew that they wanted change, they just didn't have the knowledge or means to do it. It was up to us to understand the problem, determine the scope, and then seek out a solution.

Problem

How do we build a tool that allows educators to understand their potential for their classrooms?

Understanding the issue

To get a tighter understanding on the project, I conducted a usability audit on their current website (see below) to asses any potential red flags and problem areas to focus on. The key takeaways from my audit concluded that:

1) The site lacked a consistency in how it expected its user to interact with it.

2) It lacked information on the services the department provided.

3) The elements that required the user to interact with lacked a call-to-action.

4) There were no standards for the user to determine why they should be contacting the department.

Interviewing the department managers

The team then interviewed our department’s managers for insight on their vision of the tool. Our goals going into the interviews were: to better understand their idea for how the department should be shown to their clients, as well as determine what their goals would be from the future website. These interviews allowed us to determine the following goals:

1) Create an information base of what the LTS does and how they serve faculty.

2) Establish a point of contact for troubleshooting.

3) Provide inspiration and resources for professors looking to improve how they run their classes.

Interviewing the support staff

Our next steps were to empathize with our support staff, and interview them to understand how they currently go through their day-to-day, as well as identify any present frustrations or difficulties in their process. Through this, we learned that to help their clients better, the support staff wanted a singular database of information regarding the tools and services LTS provides, a public online help guide for said tools and services, and a more detailed contact protocol. This would increase efficiency in their workflow, allowing them to service more clients daily with ease (provided the clients follow the detailed contact protocol).

Combing through surveys

In lieu of being able to interview actual users due to budgetary restraints, we decided to look at previously collected survey data about the workings of the department. This allowed us to understand the pain points of our clients, which overlapped with our support staffs frustrations, as well as our managers main goal:

Create a unified information base of the services and tools to inform clients of their possibilities and increase internal efficiency.

Mapping out the Information Architecture

The first thing we did when approaching our solution was iron out and establish an information architecture. To get an understanding of how we wanted to potentially organize the website, we crafted an activity where our stakeholders would create groups using existing items on their current website, as well as items off a previously constructed excel file of all the services they provided. This exercise was done through the tool Trello. Trello typically isn’t used for card sorting, but we found its interface intuitive enough for them to understand the purpose of the assignment, which yielded great results.

Personas

Our first step in understanding of the kinds of users we were designing for was to categorize them into groups and identify the pain points and  needs for each one. We decided on the following:

1) Faculty New to York University
2) Someone who knows of LTS and knows what they want
3) Someone who knows of LTS and doesn’t know what they want.

Unfortunately, we lacked the budget to go out and interview current users who interact with the department, so we went to our support staff and polled them on the kinds of tickets they receive, and the common client they help.

Creating a prototype

With the system map set, we moved on to creating prototypes of varying fidelity. Using the collaborative design tool Figma, the team came together to design a series of interfaces that went through countless iterations before landing a finalized design.

First prototype

Our goal for the first prototype was to use existing Material Design components to create a quick litmus test of the flows we planned. Thankfully, our feedback instantly provided us with the information that it would take too many clicks on the users end to get to where they want to go.

Second prototype

With our second prototype, we wanted to get further in terms of visual ideation to make it feel more connected to the York University eco-system, as well as further our efforts to build a flow that worked within our managers and our own demands. With this attempt, we removed the biggest strain on our project with the individual tool pages and simply made the website a database of the tools the department provided. However upon feedback, we recognized that the lack of interactivity didn't fully service our potential users, and we moved on to a more dynamic prototype.

Final prototype

After much deliberation, we finally designed a prototype that was able to meet all of our expectations. It provided the right amount of interaction and was knowledgable enough that first time users would easily be directed to what they were looking for. We conducted user testing with the support staff and although there were certain services that needed to be removed as they were no longer offered, they found the experience simpler to their previous one and would easily be able to direct future users/clients to the documentation they would need.

Reflections

This project was a great introduction to product management and the expectations each role carries. It was also my first foray into user research outside of a schoolwork environment which allowed me to see first hand the walls and limitations that could be in place and how to work around them.

If I could do this project again, I would definitely try to include the support staff at many more points in the project. We would meet with them for specific things such as information about the clients they assist and how they do it, but looking back I wish I brought them in more for each prototype presentation rather than waiting till the end to get them to test it.

The website was meant to be made for clients, our other key user was our support staff as well.