ZIU

Web app for students to check their exam results online. Designed for the Ministry of National Education of Poland.

date

2019

relevant links

Website

Responsibilities

research, user tests, wireframes, prototypes, documentation, reviews & tests, copy, ux, ui & interaction, workshops

Introduction

ZIU stands for Zintegrowany Interfejs Użytkownika, which translates to Integrated User Interface but is also an onomatopoeia for a flying object, like a paper plane going fast. Through this integrated user interface students can check their exam results as soon as they're made available. This is the quickest way for students to find out whether they've passed and how they've scored in some of the most important exams in their lives.

Thanks to being connected to a much larger system designed for the Ministry of Education, the app could provide students who kept their accounts throughout their education process with information about their past exams. Most importantly, though, the app needed to work briskly under high loads, right after exam results are posted and a lot of clients are trying to log in.

Logging in

After taking their first exam supported by ZIU, the students would receive login credentials from their teacher. The login credentials were dubbed "login" and "token". After logging in for the first time, the user would be able to create their account and set up their "password" that they could later access.

Now the initial idea presented by the stakeholder was to provide users with a login screen that would allow them to either "search" for recently posted exam results or "log in" to the system.

The funny part? If you wanted to check your historical results but didn't participate in the recent exam for which the results are being posted, you wouldn't be able to access the quick database. If you wanted to get your recent results, they would not be available through the heavy database right away (only after, say, 12 hours or so).

I couldn't change the way databases behaved, so I needed to come up with solutions using the rules and tools that were already in place.

So the easiest and the laziest solution is to write a bunch of text explaining all the above. Calling the "search" something else, while it'd make more sense, was no solution either, as it'd create two entry points to the system and we'd still need to explain which one does what.

My idea was to decide for the user which way to direct them. Always call "login" a "login" and always call "password" a "password." No "tokens". No "searching". Only one way to log in. If the results were just posted, have all user credentials directed to the quick database. If the results are not found, display a message explaining that the app is working in a limited mode where only some users can access it.

While the solution does seem a little dirty, as we'd be blocking access to a large part of the system for some users for some amount of time, it seemed like the only sensible thing to do given the rigidity of the system.

The stakeholders were not too happy about the idea, as they did not want to block access to the heavy database for any amount of time for any users. They wanted to go back to their initial idea of basically having two login paths and maybe creating some onboarding process where some explanation as to what's going on is provided.

I still thought that having two ways of logging in was way too confusing and wanted to make the single login a viable solution, so I asked if we could direct all users to the quick database upon logging in and if their credentials were not found there, they'd be automatically redirected and logged in to the heavy database. It took a lot of meetings, but I've finally managed to convince the stakeholders to implement the solution.

Digitization & WCAG hardships

The next thing the app needed was some usability fixes and a fresh coat of paint. I did have some wireframes and mockups to work with done before I was brought in to finish the project that covered all the functionality that the stakeholders wanted to include.

Problem was, a lot of the stuff that was in the wireframes and mockups didn't always make sense in the context of simply checking exam results. So to give you a taste of what kind of information I wanted to get rid of, you had the first name, last name, personal id number, the school the student went to along with its entire address, semester info. I had to all that out of the way, so that the vital information would not get lost.

One can safely assume that all this information could come in handy if a student wanted to verify their data, but it's not something that should be taking a huge portion of the home screen every time they log into their account. The stakeholders were used to seeing official documents with exam results printed out, and so they wanted to recreate the old format that included all this information in the new media verbatim.

It is often the case with digitizing processes such as this, and it took a lot of convincing that we should approach the interface with a somewhat fresh perspective that is resemblant of the already existing dashboards rather than printed documents.

After a decent amount of pruning, I had a couple of ideas regarding what the app could look like. The internal stakeholder made it clear from the very beginning that we should include some illustrations to make the app look a little more friendly, which I thought was a great idea.

Final touches

Friendliness and legibility were the forefront requirements regarding the characteristics of the app. I wanted lighthearted, round, yet coherent, and easily legible typefaces, so I chose Nunito and Nunito Sans. The initial idea was to use a different color for each exam type, but there was no clear idea as to how to use the colors. Besides, I had to make the app at least WCAG AA compliant in its basic form, so the colors had to be dark enough and when the colors are dark, they're kinda muddy and not very pretty to look at.

In the end, I opted for using a very limited amount of colors arguing that even if we were to use different colors for each exam type a single user would not see more than 3-4 of the colors in his app anyway, and then they'd be ugly anyway. As a final touch, I had our illustrator create a number of illustrations that fit the light color palette and style of the app to be used on pages with a lot of whitespace and as loading screens.

As is often the case, there wasn't enough time and resources to test each newly delivered feature with users to make sure that it makes just as much sense to them as it does to the team that designed and implemented it. The problem of explaining what the app does has been with us since the very beginning, and it's only been exacerbated by the slow feature creep that made it harder and harader to onboard users and give them an overview of what Path does that doesn't feel overwhelming.

Due to the obstacles mentioned above and many more, this was a challenging and extremely fun product to work on.