Students using devices

For over a year now, I've been responsible for managing MyEd, the University of Edinburgh's web portal. I've come into this role from a fairly mixed background: front-end development, education, and usability. I think a lot about users and I'm pretty opinionated about what goes into a good user experience. I want them to have the best experience that we can provide.

Last autumn, I initiated a project to improve the student experience on MyEd. MyEd serves the entire University population, but students form the majority of our user base. To understand how to make a good student portal, I've been doing research with my colleagues, students, and fellow portal people at other institutions. I owe a debt of gratitude to these collective brains for helping me articulate these ideas.

So, what does a student portal designed for students look like? I have quite a lot to say on this subject, so I've split this out over two posts. In this post, I'll be exploring some common portal issues and looking at how we can resolve them.

Disclaimers: MyEd is built on uPortal, an open source framework based on the Java Portlet Specification. I'm using this specification (and MyEd) for the basis of this discussion, since it's the one I'm the most familiar with and it's commonly used. However, I intend to remain focused on the user experience aspect only. None of the problems or solutions covered are specific to any technology or framework. As always, any opinions given here are my own.


#1: Separated services

In MyEd, as in many portals, each portlet is equivalent to a service or system that the University offers. (For those non-portal folk, a "portlet" is a box of content displayed within the portal.) For example, we have a student and course records system at the University, and that system has a portlet. Staff and students go to the relevant portlet to access that system.

Separated services

Using this "one system per portlet" model, our services are completely separate from each other. This prevents students from understanding how they fit together. For example, let's say that we have a Learning Management System (LMS) where students have to submit their assignments. We also have a Student Records System which records final marks. The student wants to go check their marks for a mid-semester exam. Should they look in the LMS, or the Student Records System?

To us, the service owners, it might be obvious where the student should look because we understand the process. To a student, it isn't obvious. They will probably end up checking both locations, and even then they may not be certain which one is correct.

There are also many cases where no single system will have all of the information the student needs to perform a task. For example, at the start of the semester, a student might want to find out where and when their classes are. To do this, they need to check their timetable and the location for their classes. They might also want to see what transportation options are available to get around campus.

To get this information, they may have to check three (or more!) individual systems: Timetabling, Campus Maps, and Transportation. Even if all this information is displayed on the page, it's still separated off into its own little box - the student must combine this information together manually. We've put the burden onto the student to do this work for us.

Solution: Integrated services

Integrated services

A better way would be to take on that burden by bringing the data together for the student. In our above example, we might have a single section on the page which uses data from three different services and displays them seamlessly together. This also resolves the problem for students of knowing where to look. The student might not even know the names of these services, or that they are separate services at all.

#2: Content overload

With any portal, there is a temptation to just toss all of our services in willy-nilly and let students figure out which ones they need themselves. We don't want to leave anything out for fear it will be missed.

However, our analytics show that only a fraction of MyEd content is being accessed regularly. The graph below shows portlet access by users over the course of one year (names removed to protect the innocent). As we've said above, in MyEd a portlet is essentially equivalent to a service. This is then a good measure of how often services are being accessed from the portal - although it doesn't tell us anything about services offered elsewhere.

Graph of portlet usage

As you can see, a very small percentage of our services account for almost all user interaction. Unsurprisingly, the most-used service is the LMS which students use for their day-to-day coursework.

This same "long tail" of services is also reflected in self-reported priorities. This graph shows the results of a survey from 2013 where students were asked to select their top 5 tasks (choosing from a selection of both tasks already available in MyEd and proposed tasks not yet available):

Graph of task priorities

Although there is a bit more give, the curve here is almost identical to the one above. Based on this, we can clearly see that students don't actually use and/or care about most of our content. Even for content that they do care about, they may only be required to interact with it very occasionally.

Because we have so much content, services are forced to compete with each other for student attention. The end result is something like merchants shouting in a bazaar - each service trying to shout the loudest to get noticed by users.

Solution: Don't try to please everyone

There are a couple of things that we can do to resolve this situation. First, we can reduce competition by reviewing our content. Not everything needs to be in the portal. In fact, some items are better served elsewhere. For example:

  • Long, wordy content should be on our University website or in another online format optimised for reading.
  • Complicated tasks require a page of their own. We should redirect students to the source system to do the task, using a shared pattern library to keep the experience consistent.
  • Content which is only occasionally required should be pointed to as needed using notifications, alerts, or task lists.

Second, we need to enforce a common "voice" to prevent the portal from becoming disjointed. This requires us to have standards for our content, which are then enforced by governance. Having central oversight ensures that students always receive a consistent message from the University.

From time to time there will be tension between the individual service needs and the portal service. In trying to create a common voice, someone will inevitably feel that their voice isn't being heard. When this happens, our portal governance needs to make the final call. This doesn't imply that the portal always come first. Rather, decisions should be made based on the University's strategic objectives and evidence from user research.

#3: Institution rather than student

The final (and perhaps most damning) problem with this type of portal is that it enforces an institutional view, rather than supporting the perspective of the student. Our portal is built around our internal hierarchy and the systems we have. This is not the way that students actually think about our services.

  • Students think: "I need to submit my coursework."
  • They don't think: "I need to go to the LMS." (Especially since they probably don't know what an LMS is, until we train them to.)

The message that this "institution first" attitude conveys to students is that we care more about our needs than we do about theirs. Most of what we (as a business) care about most deeply are the things that students could care less about.

For example, say that we invest in building a fancy new way for students to update their address. This could be an important project for us, but students don't come to university to spend time updating their address. We make them do it, and they just want to get it done as quickly as possible.

Solution: Make it about students

The part that students care about is the learning and teaching experience - this is why they picked us. As portal owners, our job is to streamline all the "un-fun" tasks and make it easier to focus on the fun ones (or, at least, the intellectually challenging ones). We can make things easier by changing our the portal structure to be based around these tasks. This is the approach of user needs advocated and used by GOV.UK.

To do this successfully, we need to understand and use the language that students use to describe these tasks. This means:

  • Not using internal or specialist vocabulary only understood by staff working in that area
  • Not using names for services which aren't descriptive (e.g. "LMS")
  • Grouping together related items under the same heading, even if they are organisationally separate

We also need to work with students closely to understand what tasks they are doing, and how they think about them. It's important for this information to come from students themselves, rather than service owners. Service owners still play an important role as subject matter experts, but only students can truly say what their perspective is. If we don't do this, we are only continuing to enforce the institutional perspective.

Do we need a portal?

Given all the problems that we have identified with portals, it's worth questioning whether we need them at all. Are portals more trouble than they are worth?

Universities are big organisations, and they have a lot of IT systems and services. (I have yet to find the University that operates on a single, centralised system. If you have one at your institution, I envy you.) Users still need a way to discover all of these services, and access them. At the very least, we need some kind of directory or listing service.

As we argued above, we also need a place for our different services to come together. There is no single service that can provide a complete, holistic picture for everything that is going on for a student. This is the added value that a portal can give.

In the next post, I'll go on to discuss alternate models for creating a portal, and ideas for how we can improve on them to build a portal that best serves students.

© 2019 by Marissa Warner-Wu. All rights reserved.

Proudly published with Ghost