Sketch, Prototype, Test, Wireframe
The Problem
For this project, I was asked to look at the UW suite of student tools, and redesign one of them to better meet the needs of students. The tool I chose to overhaul was the registration system. The problem with the current UW registration system is that it requires students to have multiple tabs or windows open, and requires users to constantly switch between tabs to find/copy/paste different pieces of information into their registration form. It is an extremely complex process, much more complex and time consuming than it needs to be. In order to put forth a design that addresses some of these problems, I decided to seek out a scenario where the current system would be at its absolute worst. The scenario I landed on was a student attempting to use the current registration system from their mobile phone. On mobile, it is even more impractical to have multiple tabs open, and copy and paste from different pages, especially when the system doesn’t even display responsively. With this in mind, I started designing my version of the registration tool with mobile specifically in mind. I figured that if I could get a satisfactory experience on mobile first, then I could scale the designs up to desktop without losing any value.
Sketching
After deciding on the problem I was going to address, and setting some constraints for myself, I started sketching. I started with the most basic and necessary mechanic of the system, the actual act of adding a course to your schedule. After that, I just started sketching whatever came to mind. I sketched how existing features could be effectively be translated to mobile, new features, as well as the basic user flow between some of these features. Due to the compressed timeline of this assignment, I only sketched ~6 different potential ideas before I needed to start evaluating. With that being said, I believe that these 6 sketches were enough brainstorming to get me moving in a good direction, and through the critique process in class, I was able to pick a task flow to focus on, and elaborate on my ideas as they pertained to that feature.
The task flow I chose to move forward with was using the Time Schedule to find and register for classes. I chose this task flow because it is the primary way in which students currently register. Some of my other features, like suggested schedules tailored for students majors and interests, don’t currently exist. I wanted to focus on fixing the current system first, then adding new functionality if time allowed (it did not). My other feature ideas, such as scheduling conflict notifications/indications could be integrated in with the time schedule flow.
Below, you can see all of the initial sketching I did for this project. Not all of these feature ideas made it into later iterations of my designs, and as I said before, I focused on the time schedule task flow moving forward. However, sketching the other features helped give me a sense of what the entire system might look like. With a mental picture of that holistic system, I was able to design a better time schedule flow, and one that would integrate with other features and services much more effectively.
Prototyping
After sketching, and a lot of critique, it was time to get my designs in front of some potential users. In order to do that, I needed to create an interactive prototype. Since it was still so early in the design process, I made a paper prototype to show users. The reasons for using a paper prototype for gathering initial user feedback are too numerous to comprehensively cover in this writeup, but I will say that I wanted my prototypes to convey that the design is still very much a work in progress. This “sketchy” aspect of paper prototypes invites critical and constructive feedback from users. Paper prototypes are also easy to update and change on the fly, take relatively little time to create, and force users to focus on things like navigation and Information Architecture, rather than graphic design and aesthetics.
Creating my paper prototype also allowed me to refine my design ideas from my sketches, and incorporate some of the feedback my peers gave me during critique. For example, I did away with the “Shopping Cart” concept, a lot of my peers felt that this step would potentially be confusing to users, and that directly registering one class at a time would make more sense.
Testing
After creating my paper prototype, it was time to test it with users. Due to the time constraints of the project, I was only able to test with 3 potential users, but the feedback I received allowed me to make some key design changes.
Overall, the response to my prototype was very positive. Participants were really excited about the ability to register from their mobile phone, and thought that the user flow through the task was straightforward and intuitive. All participants were able to complete the task on their own, without any extra help from me. There were, however, a few sticking points. First, the users were confused by the calendar icon in the banner of each page. It wasn’t clear to them what the calendar button did, and when explained, they claimed that it was a feature they probably wouldn’t use. Also, the users were confused by the course listing on the department page. They didn’t like that the courses were listed by course number, rather than course title. Finally, users expected to be taken to a new page when they “click into” a course on the department page. The action of the course details simply expanding down the same page confused them, and broke consistency with how buttons behave in the rest of the system.
After completing testing, I wrote the following statement regarding design considerations.
In the next iteration of this design, I will change a few things in order to reconcile the sticking points pointed out by my participants. First, I will remove the persistent calendar icon from the banner, and instead put the option for viewing the visual schedule somewhere else, where it is less intrusive. I will also change how courses are listed on the department page, to show course titles rather than course numbers. Course numbers will still be shown, but perhaps not until the user has clicked into a specific course. Finally, I will split out the course page to be separate from the department page. When a user clicks on a course offering, they will be taken to a new page with details about that course, and where they can register for the course if desired.
These design considerations were implemented in the next stage of the project, a set of annotated wireframes.
Annotated Wireframes
The next step in the project was to create a set of annotated wireframes. As you can see in the samples I have included, I implemented the updates identified in user testing, and took the fidelity level up slightly. The purpose of these frames and annotations would be to possibly pass them off to a development team, discuss them with PM’s or other stakeholders, or to act as a set of Business Requirements Documents. I won’t go into all of the details on why wireframing is a good practice, but as you can see here, the fidelity level is high enough to look and feel like a professional document, without looking overly polished or getting into the details of graphic design and content management. A full set of my frames can be seen below.
Moving Forward
Future steps with this project would be to expand its functionality. I would go back and start implementing some of the features that were sketched but didn’t make it into the prototype and wireframes. Once I have what feels like a more complete system, I will create another prototype (perhaps on paper again, perhaps not) and test with more users. I would then take that feedback and iterate.
