Scholarship system design part II - Usability testing
Example of the kind of documentation available for the design process.
Problem description:
The Costa Rica Institute of Technology (TEC) needed to create a system that allows to request and manage the student scholarships. The system has four different user profiles which are: students, social workers, employees and system administrator. They hadn’t worked in a system as huge as this one before, they hadn’t hired an information designer for their systems before, and they didn’t have a department responsible for finding requirements in an appropriate way. So, some of the people in charge of the project had wrong expectations about the information designer role, as I am sure it happens to other colleagues, when the client thinks we are going to decorate their interfaces and make them “pretty”. However, they identified a set of modules for the system that were going to be implemented individually, but needed to be organized in order to close processes.
The design solution:
As I already said, this system is huge, it has 30 different modules that needed to be designed, each one with at least 50 pages of documentation, so it was a very extensive process that has to be done as many times as modules it had. Here I speak generically about the process I followed for most of the modules because otherwise it could become a frustrating large story.
Reciprocity analysis between some modules of the system to complete a data flow.
The first step is to read and understand very well the existing documentation, basically become a social worker, a student, an employee or a system administrator in order to understand their needs, their frustrations and their expectations. I had to question everything written and connect modules to each other, because most of them works in a flow, where they are receiving and sending data to each other. When you make this connections, you start to find a lot of gaps that need to be filled with some information that maybe wasn’t considered at the beginning and also discover some data you won’t really need.
After this exercise, I got a second kind of specifications to follow, a robust one that contains not only the user expectations but the designer requirements as well, now I’m ready to sketch my prototypes.
Every prototype made is tested by paper prototyping, which allows you to get a lot of feedback from the users. I usually identify the main tasks I want to test and write an open task (it means not to lead the user through the process) that let me test several elements and functions at the same time, for example:
“You are the social worker in charge of management the Mauricio Campos scholarships. You must modify the academic load requirement to the first six candidates for scholarship. You will allow them a minimum of 7 credits enrolled. If any of the selected students presents other modification with a more favorable value you will have to decide which modification you want to apply. This modification will be valid for three semesters.”
On the right you can see the sequence of screens I used for testing the task described before.
At the end of the testing phase I got some modifications to apply, usually related to some concepts that might not be the most appropriate ones. The next part of the process will be explained in the next post: Scholarship system design part III - Wireframes.