Many educational institutions use a student information system (SIS) to manage student enrollments. This project intended to provide a new user experience to build on an MVP version made by another team. After looking at the MVP, it became immediately clear that the workflow was going to be overly complex to expect a user to complete. Still, it wasn’t obvious where in the workflow we could make changes to simplify this, or even if it could be simplified.

We had a completed MVP for this project to build off. However, we were unsure if the MVP had been built in a way that met the customer’s needs. We wanted to focus our research on how student information systems are used if we can use any of the work already done in the MVP, and exploring ways to present the complex workflow in a way that wouldn’t be too overwhelming for the user.

I decided that we’d split this workflow up into steps. Users would be able to leave the workflow at different points and come back to it to complete the process. We’d give as much information as we can when there are periods the users have to wait to prompt them to return later.

1. The explanatory text should be used to provide immediate context and give structure when users return to process at a later point.
2. We’d break things into steps wherever possible. Steps would be described upfront and reinforced wherever possible.
3. We’d clearly state where users have to leave the app to configure elsewhere. Then, when they have to go through the app, we will provide extra contextual information for them to refer back to.

Step 1

As the process requires the user to follow a complicated journey between our app and elsewhere, we introduce it upfront to set their expectations.

Step 2

Where the user must take information from our app and transfer it, we provide a single click button to avoid any copying errors.

Step
3

Once configured, it could be many hours before the user can complete the workflow, depending on how they set up their connection.

To help, we provide a simple contextual copy with a definite path they can follow to continue. We also offer access to troubleshooting if they are not expecting the page.

Step 4

Steps - Steps provide structure when people have to come back later and lessen the cognitive load on the user.

Descriptive text - As people have to leave the workflow, the text gives the user context when they return and enough context to understand the complex workflow.

Other elements - Simple descriptive elements to provide a recognisable and easy-to-grasp workflow.

Step 5

A success message gives the administrator, who otherwise may not use the app that regularly, a path to support the instructors who will be using the app regularly.

We had no centralised area where users could go to learn about potential problems with our products. Because we have many different access paths that plugin to many different environments, it is often difficult to know if something is a new problem or something that a single institution was experiencing. We needed an area where users could go to self-serve this information before going to the support team for extra help.

Going into this project, we were aware of two limiting factors that would restrict what we could accomplish.

1. The page would be built within MadCap flare. We knew already that MadCap didn't have a way of displaying this type of information gracefully.
2. We wouldn't have any development resources for this project. I would be responsible for the UX and engineering work.

I knew that there were problems but I didn't know why users had trouble finding out information about them. I decided to tackle this stretch of research in two ways. I'd first work with our Support team to understand the issues they commonly saw repeatedly. What were the things that multiple users would contact them about? Parallel to this investigation, I would engage our Integrations team to get involved with their daily talks with users.

It was my hope by seeing this problem from two different perspectives would give me insight into how a page could act as a source of truth for users and be a resource they could rely on.

All of the content for this project would be designed to provide timely context to the user. Most felt they could self-serve, as long as they weren't left to become lost looking for the content that was relevant to them.

1. Each access path follows a simple hierarchy that followed the patterns of behaviour we saw in our research. The top-level filter would be the Learning Management System (Which we knew they were most likely to know), and then increase in specificity for those who knew what to look for.
2. Each access path would have its own RSS feed users could subscribe to.
3. I would create several 'pill' elements that would provide further context for each item and its current status.
4. The page would dynamically fill based on the page within MadCap. JavaScript would be used to change elements to fit the context the user wants. For example, a dropdown allows the user to choose the most relevant integration for them. This would filter the items show to only the most relevant, but also update the 'last updated' and 'RSS feed' sections.

Welcome Text - It was important to introduce this page in a supporting voice. Users are already frustrated by not being able to access that app. Giving them false platitudes wouldn't help anyway. We would acknowledge that there are potential problems, and try to help them.

Access paths - Access paths would start high level and then zoom in to filter as much as we can to what is most relevant to the user. When they really don't know, they can fall back on the 'all' option.

Dynamic elements - The date and RSS elements may seem simple, but on the backend, they rely on multiple functions to ensure that whatever filter the user picks truly changes the page to what is relevant to them.

Pill elements - My core philosophy with these elements was to provide extra context. The user should be able to glance at the page and know if there has been progress with their issue. I created four different pills that would allow the user to self-serve their update. 'In development', 'Investigating', 'Workaround', and 'Fixed'.