Wireframes, take 2

A couple weeks ago, I created my first wireframes for our Rapid Ideation and Creative Problem Solving class. This week, I developed a revised set of frames for an iPad application that facilitates class scheduling and registration.

I integrated feedback from testing and presenting the previous wires–especially problems with navigation and usability around registration and pop-up descriptions to compensate for interface decisions that weren’t self-evident. Since this is an iPad app, I also wanted to change the navigation so the app would work regardless of orientation.

Here is the second iteration of the wireframes. (Click image to download a full PDF.)

I tested these wires with three users using a Think-Aloud Test, where testers explained what they’re doing as they tapped through paper prototypes. Their descriptions helped me understand where the process didn’t flow as expected–as did the “Uhhs…” and pauses when they needed to reorient themselves to the screen presented before them.

So what did I learn in this round?

  1. Experiment with the schedule view. No one tried tapping the schedule to add classes based on time. Similarly, in my first iteration, users didn’t immediately know how to set time preferences on their schedule. I need to determine if this is a valuable part of the app, and if so, offer affordances so users understand what they can do.
  2. Streamline the “hero flow.” In testing, all my users defaulted to searching for classes through the course catalog rather than entering the process through the schedule view. Several screens were entirely unused in the tests, so I want to reevaluate the process to make sure it isn’t too complex.
  3. Refine details. I added some visual cues in this round–like showing the most recently added course as darker on the schedule, making the registration button an obvious option, and adding a status bar to indicate number of credits on the schedule. However, others features were not obvious enough; no one used the filter options for course searches, and one user wanted to slide the credit status bar like he does when he unlocks him phone. In my next iteration, I want to continue refining these details so they’re useful.
  4. Test with more users. I only tested with 3 users, and while I saw trends in the usability issues with my frames in this round, I know I would have had a better sense of the problems and opportunities if I tested with more people. I’m planning to retest this current set of wireframes with 3-4 more people before I dig into work on iteration 3.

I’m enjoying this process more and more–though I do think it gets harder with each iteration because the “easy” usability decisions have already been made.