Design
Screenshots
Figure 1. Login Page.
Figure 2. Home page. Users can access any page on the site by clicking the large center buttons or the smaller sidebar buttons.
Figure 3. Packages page. Users can check in/out and edit packages on this page.
Figure 4. Items page. Users can check in/out and edit lendable items on this page.
Figure 5. History page. This page contains a list of all the actions ever performed by any desk worker in chronological order.
Figure 6. Notes page. Users can leave notes for other desk workers to let them know about anomalies during the job that don't fit into the packages or items categories.
Important Design Decisions
- consistency - we tried to make every page as similar as possible so once a desk worker learns how to use the packages page, they know how to use all the pages (based on findings from paper prototyping)
- simplicity/minimalist design - we eliminated unnecessary information and text (in tables and on buttons). Only pertinent information is displayed on each page. (based on findings from paper prototyping)
- lots of whitespace
- text labels on buttons - we initially removed most text from buttons, but we added it back to increase learnability. (based on findings from the heuristic evaluation and user testing).
- notes page - we chose to add the notes page because when we tested actual dorm desk workers, the most common complaint was the inability to handle abnormal situations that would require writing a special note and leaving it somewhere for other desk workers to find. (based on findings from paper prototyping)
- check in/out buttons for items - we initially used red x's and checks to indicate the status of an item as checked in or out, but we switched to using two separate buttons labeled "check in" and "check out" (based on findings from the heuristic evaluation)
- editable fields - initially we made package and item entries uneditable, but we added editing capabilities and full CRUD support (based on findings from paper prototyping)
- notes are only editable by author - we disallowed desk workers to edit notes they did not create (based on findings from user testing)
Design Alternatives
- more informative tables - we considered including a lot more information for each package or item like the desk worker that added it/checked it in, the time it was checked in, the last person who checked out an item, etc. But we chose simplicity and whitespace over overly informative tables. (based on findings from paper prototyping, heuristic evaluation, and user testing)
- sticky notes - we considered making the notes page contain more realistic sticky notes (like the sticky note feature on Windows), but decided against this idea in favor of the ability to sort and filter notes
- sticky notes - we considered allowing users to add sticky notes to any page on the site instead of having a separate notes page. However, we decided against this idea because it's simpler for users to only have to look in one place to see all the notes
Implementation
Describe the internals of your implementation, but keep the discussion on a high level. Discuss important design decisions you made in the implementation. Also discuss how implementation problems may have affected the usability of your interface.
Evaluation
Describe how you conducted your user test. Describe how you found your users and how representative they are of your target user population (but don't identify your users by name). Describe how the users were briefed and what tasks they performed; if you did a demo for them as part of your briefing, justify that decision. List the usability problems you found, and discuss how you might solve them.
Our test users consisted of three actual dormitory desk workers and one student who had never worked as a desk worker. Other than the student, our users were very representative of our target population as they are our target population.
Here is a link to the briefing and tasks we used in our user tests.
Usability problems found:
- it's difficult to enter names in the package and items forms because the have to be exact--many users added whitespace before or after names and the form would not accept them.
- package and item editability is not intuitive--users said they were looking for an edit button to switch into edit mode
- the icon for items is confusing because it is a picture of tools
- instead of "checking in/out" items, users preferred the term "lend"
- instead of "adding" or "releasing" packages, users preferred the terms "receive" and "deliver"
- users wished they could leave sticky notes on any page and view them all on the notes page
- users wanted to be able to add packages for non-residents (which our system does not allow) because dorm desk workers often hold packages for non-residents
- users wanted a "received by" field for packages, so they would know which desk worker performed the action
- users wanted a date field for items so they would know when an item was last checked out. This was they could contact residents who kept an item for too long.
- users said they wanted notifications for new notes so they would know to check the notes page.
Reflection
Discuss what you learned over the course of the iterative design process. If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.