(Click to download full version in PDF format)
In our Rapid Ideation and Prototyping class, our assignment this week, and for the next eight weeks, is to design an online application for planning and tracking school classes. In the initial pass, we develop personas (“fictional characters created to represent the different user types within a targeted demographic“), scenarios (written statements of a userflow), storyboards (a comic strip like approach to show a person using the product or service), and wireframes (pictured in the header image above) that describe the functionality of the product’s digital interfaces.
In developing the wireframes, we start with very low fidelity sketches, then re-sketch them several times, each time increasing the level of detail, eventually finishing up in a digital tool like Illustrator, Flash, Keynote, or Omnigraffle. During these iterations, we will start testing with potential users to get feedback and identify problems with the interfaces. The type of testing we do is called Think-Aloud Testing. The user is given a task or goal to complete, and they work through the paper or digital prototypes talking through what is going through their minds as they attempt the task. With just a few short sessions, most of the glaring problems with a product can be found.
After this initial first pass of wireframing and testing, we’ll iterate five more times over the course of the quarter. You can download my first pass as a PDF.
The good news is that my test users were able to search for and add classes. However, they discouraged by the messaging of “no results” when over-constraining a search, so the system needs to help users unconstrain the search either explicitly (by removing options) or implicitly (by showing related or similar matches, or correcting misspellings). Users did not understand the bookmarking icon and how it related to the functionality for comparing classes, so a more standard icon needs to be used and animation can add affordance to how the functionality works.
Users were also unclear if they were just planning classes or actually registering for them: in addition to clarifying this, the system will need to work differently depending if a registration period is open or closed. Finally, additional screens need to be created to articulate error or conflict states (for example, the user attempts to add a class where prerequisites are not met, or it does not fit their schedule). This opens another can of worms: should users still be allowed to add conflicting classes? Or should there be hard constraints? Should I just make a design decision? Or should I prototype both options and see what happens next in user testing? I don’t know the answers just yet, but stay tuned for the next post by November 20th to see the next round of results.
No Comments »