Copy this file to a new one called evaluation-and-vision.md. Populate the sections as indicated. Illustrate your ideas as needed, with diagrams, screen mockups, etc. Don’t forget to cite references—this is still a piece of formal writing.
Provide a summary and recap of the application that you have built. Describe the web service(s) that you use, the functionality that was implemented, and any other notable facts or tidbits of the final product.
In this section, provide an objective assessment of your front end’s usability.
Explore how usable you think your application might be. Base your discussion on one or more of the following:
- Mental model of the system from both your (developer) perspective and how you think the system’s image communicates this to end-users
- Guidelines documents that correspond or apply to your technology stack (i.e., how well [or badly] your front end ended up complying with those guidelines)
- A well-chosen subset of interaction design principles or theories (i.e., how well [or badly] your front end follows these principles; how a theory explains what a user might experience when using your front end)
- The effectiveness or appropriateness of the predominant interaction style(s) used by your front end
Select two (2) usability metrics and informally record these for your front end with a small number of users. You may take measurements from as many people as you like, classmates or otherwise. Due to our limited time and resources, we don’t require a particular number of users, but aim for at least three (3)—that seems to be a fairly reachable number although of course is nowhere near being statistically valid. Still, it’s better than nothing. Remember the following conditions/definitions for the various metrics:
- Learnability—Remember that this only applies to subjects who are not familiar with the particular system they are about to use (interface knowledge), but understand the tasks in your list (domain knowledge). This metric is the time to accomplish tasks without prior training.
- Efficiency—For this metric, give your subjects some time to become familiar with your front end (perhaps after you have recorded learnability!). To accelerate the process, you can opt to give them some training and/or practice time in order to gain some level of expertise.
- Memorability—This metric requires the most planning to explore, but with sufficient lead time it isn’t impossible. Allow your subjects to learn your front end, then get back to them at least one (1) or more weeks later. Measure the time it takes for them to accomplish things after this time away. The metric pairs very well with learnability and efficiency: measure one of the two initially, then measure memorability after some time has passed.
- Errors—Remember that in IxD, an error is not a bug, exception, nor crash, but an incident where the user does something whose result is not what he or she expected.
- Satisfaction—We will stay very simple here. Just ask your subjects to rate, on a scale of 1 to 10, how much they enjoyed performing each task on their respective devices or systems. In this document, report the (very small number of) measurements taken and make a judgment call on how well your front end performed for your chosen metrics. Note that this is by no means a valid quantiative assessment of your front-end, but the exercise at least gives you a firsthand taste of what such studies would be like. How do these measurements align with your original usability metric forecast from Assignment 0920? What insights might you draw, now that you have experienced the full cycle of designing then implementing then evaluating a front end?
Provide an overall statement on your front end’s usability, based on the evaluation that you performed. Note that this can serve as a very effective lead-in to the next section.
In this section, you may release yourself from all implementation knowledge constraints and describe what you feel would be the ideal design for your front end. You may also release yourself from the technology stack that you chose, if you feel that the ideal interface for your application is better delivered on a different platform or device. You will notice that the outline for this section is very similar to Assignment 0920—in a way, it serves the same purpose, but for a next-generation version of your front end.
Provide an overview of your user interface. Annotated mockups work very well here, with accompanying text describing, at a high level, the various components of your design. You may also provide a comparative illustration of how your “vision” differs from the existing reality.
As with your original front-end design document, provide at least two usage scenarios here. They may be the same or different from the scenarios in the original. The best choices for this document are the scenarios that effectively show off the strengths of your “vision” design.
Replace the title with an actual description of the scenario, e.g., “Adding a Song to a Playlist.”
Ditto with the title.
State why your design is the way it is: relevant priorities, mental models, interaction design concepts, guidelines, principles, theories, etc. Because this is a second iteration, you may also bring in lessons learned from the original design rationale from earlier in the semester. Cite relevant references as needed.
In conclusion, remember that the final objective measure of an application’s usability is how it fares in the five established usability metrics. Thus, your design “vision” must also be motivated by those metrics. Based on the informal measurements that you captured for the existing design and what you feel are the priority metrics for your application, state how your new design vision intentionally aims to improve on the important metrics, possibly trading off those improvements for the less important ones.
Cite formally, as you would with any other research paper.