...
The final design of the website was extremely focussed on a the bulletin board, allowing users to efficiently add Buckets and tasks, post notes to their board and / arrange them however they want. Figure 1 shows a screenshot of the main page of BucketList (where the user spends all their time when on the site)., and easily see what tasks they need to do, all from one main page.
Main Page - Bulletin Board
BucketList does not have multiple pages to navigate through, the user remains on the main bulletin board screen at all times, where they can accomplish all key tasks. One important reason we chose this design instead of having multiple pages to navigate and forms to fill out, is because it makes the application very efficient and users can easily and quickly accomplish all key functions from one place. This decision was made based on initial user surveys (see GR1 for more details), since most users
Figure 1: Main Screenshot of BucketList
Login
When
Figure 2: Login
In our initial paper prototypes, there was a much smaller focus on the bulletin board. In addition, each Bucket had a different board (instead of having one main board with all the user's info). We got lots of feedback regarding the bulletin board (see GR3 for details), and the consensus seemed to be that users liked the bulletin board but didn't like how we were implementing it. We tried two different designs of the bulletin board (splitting the screen with an "all notes" and the bulletin board, and having tabs to go between "all notes" and the board) for the paper prototype, and took all the comments into account when designing the website for GR4. Based on feedback we decided to switch to the 'one main board' approach and we split the screen into 3 sections (side list of buckets, bulletin board on top, and list of notes / tasks on the bottom). After coding this, we did another round of user testing before GR4 was due. Many users commented that they wanted more room for the bulletin board and thought that always displaying the notes / tasks in the bottom and list of buckets on the side was a waste of space. Based on this feedback, we redesigned to look more like the website in the screenshot above.
Figure 2: Drop-down Menu to Sort Tasks
...
Another comment in heuristic evaluation was that users wanted to be able to open multiple pieces of paper at once, as depicted in Figure 3. Thus, if a user clicks a task or bucket from a drop-down menu in the final implementation, it opens a new paper. This makes the action more obvious, and lets users view multiple tasks at once, if desired. Its also easy to close these papers, with the little 'x' in the corner.
Figure 3: Multiple PapersFigure 4: Zoom-in List of Tasks on a 'Bucket Paper'
Based on the Heuristic evaluation and another round of user testing, we also changed the layout and information presented on the paper. Specifically, we added the edit and calendar icons. The edit icon (instead of having the task name always be editable)
We In our final implementation, we also added a "help" button, based on the heuristic evaluation. This question-mark seen in Figure 5 is always present in the bottom-left corner of the screen. Clicking it opens a new paper, with information about the option to read about main
main aspects of BucketList (including 'alerts', 'buckets', 'due-dates', etc). These topics were chosen by evaluating the website with users and observing what concepts confused them 
Figure 5: Help '?'
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.
Our implementation involved separate objects for all of the various entities in our UI: papers, stickies, the board itself, notes, tasks, and buckets. These objects contained all necessary identifying information for those entities and allowed us to find the item on the board and manipulate it according to the user's specifications. Originally our implementation limited the number of papers open at a time to one, but after doing user testing on our computer prototype, we learned that users wanted to be able to open multiple papers at once, so we changed our implementation to allow for many papers, each of which is individually closable.
We dealt with concurrency issues between different papers on the same board by having a "refreshBoard" function that refreshed every paper and note on the board, and the dropdown menus, whenever anything was changed. We also called the "refreshBoard" function after periodically pulling information from the database backend, ensuring that users would have up-to-date information that collaborators add from other computers. This worked well for our testing purposes, since it made sure that there was never inconsistent information about a task or bucket on the screen, but it also had the potential to slow the system down a lot if a user had too many papers open at once. If this became a common problem for users, we could add some logic to make only papers with information that might change got refreshed.
In addition, we had to make some tradeoffs in the interest of time. Unfortunately, we never quite got to work on the "Alert" functionality. Having all of the affordances of an alert system without an actual alert system is obviously a usability drawback of our interface, but it highlights some important not-yet implemented functionality that will improve user experience.
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.
User tests were conducted on 6 MIT students who keep to-do lists and must manage group projects (exactly our target audience), who we found by asking our friends. We began by asking some questions about how they currently do to manage to-do lists, and got answers ranging from "I write everything on my mirror or on scraps of paper" to "I use MGSD for group task-management, and then I import everything to Google tasks for due-dates and reminders". This ensured that some test subjects were familiar with shared task-management applications, while others just keep their own to-do lists, so that we got a wide range of responses.
We decided not to do a demo as part of the briefing, as we really wanted to see if users would be able to figure out how to accomplish key tasks, so we didn't want to show them first.
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.
...