5/13/2007
This week I participated in interpretation sessions with my group and in which I played the role of interviewer, recorder, and modeler. I thought this process helped me learn more about the process of interpretation session by exposing me to the different various roles. I also finished creating our own individual sequence and flow models for our user interviews and posted them to the wiki. I used the online program called gliffy (gliffy.com) to create these models. I used this program because it was a lot more user-friendly than Microsoft Visio, which was what I was using prior to this week. Creating the sequence models allowed me to understand how triggers and intents work and they also helped me better understand the steps that users take to complete their tasks. Creating flow models enabled me to understand the information flow of my users.
In addition, I helped work on the affinity diagram with my group. I helped create the primary level post-its where the notable things of our user interviews were written down. Then I created the secondary level of the hierarchy where I grouped the similar primary level post-its together. Next, I helped created the 3rd highest hierarchy level with another set of colored post-its to find different categories of functionalities that the users prefer. Doing this affinity diagram helped me better understand the design process because it really helped me formulate design recommendations and ideas as I began to see patterns and trends in the data. The affinity diagram was a great way to consolidate all our data and organize it. In the end I took photos of our affinity diagram.
I also helped create the PowerPoint presentation on the summary of our user data that our group is going to present next week.
Next week, I plan on helping the group with coming up with design ideas for our first paper prototype. I also plan on finding people to schedule interviews with for the following week so I can interview them with the paper prototype. I also plan on begin thinking about our group paper and how we should divide up the responsibilities for it.
5/20/2007
This week I helped finish the powerpoint presentation for our data summary by adding in a few slides regarding the affinity diagram. Our group also finished consolidating the flow model and included that in our presentation as well. On Thursday our group presented our data in class and it went quite well and got good suggestions. Later this week I helped prepared for our meeting on Sunday by asking everyone to bring materials to build our paper prototype with, including things like paper, scissors, post-its, tape, stapler, colored markers, etc.
On Sunday I met with the group from 10AM to 4PM. During this time our group finished creating the consolidated sequence model, where I helped create the table for the consolidated sequence model. Later I suggested that we needed to create personas for our users to help guide our design principle for the paper prototype, so we came up with 4 different personas, including "intensive schedulers", "in-between-ers", "cue-people", and "non-tech savvy people". Descriptions of these personas can be found on our wiki. Afterwards we had our brainstorming session where we discussed the goals we were going to focus on and some of our guiding design principles. In the end we decided that there were 3 main these that we would like our prototype to achieve: portability, facilitate integration of information from different sources, and facilitating a one-time access, such as being able to print out schedules. More details on this can be found on our wiki as well.
Later came our visioning session, where we, including myself, drew ideas on the board to try to come up with solutions to facilitate solving the problems that our users were facing and trying to reach our design goals from the brainstorming session. I came up with sketches and ideas for the "calendar" panel that we were going to have, specifically how categories such as class, work, clubs, etc. were going to expand out into more subcategories (ie: under "class" would be COGS102C, COGS101, ECON3, etc.) and there would be check boxes next to each of them for users to check which ones they would like to display in the calendar. I also helped draw some other sketches as to how the other panel/tabbed functions would work.
Later we began building our paper prototype where I designed the content for the "calendar" and "to-do" tabs, and cut out pieces of paper and post-its to use for our prototype as well as taped things together. Our group managed to complete most of the paper prototype on Sunday. On Monday we plan to continue working on the paper prototype, solving any of the issues or concerns that we have, and duplicating the prototype so we can split up into teams to conduct the interviews with the paper prototype.
5/27/2007
This week on Monday I met with my group to finish the design for the first paper prototype. We made some changes to the design and I helped create a duplicate paper prototype. Our group decided to split up into two groups of 3 so we needed 2 sets of paper prototypes. I helped make the panels for the tabs and wrote the content for the "calendar" and "to-do" tabs. I then helped create post-its that we planned on using during our prototype interviews. I helped placed the post-its on the a "palette" that we created so we can better organize each post-its we would potentially be using during our prototype interviews. Our TA Sumedh also came and gave us valuable suggestions and insight regarding about our paper prototype about what to do and what not to do and showed us some good examples of websites and other calendar programs, such as iCal.
Later this week I conducted two prototype interviews with Chris and James, my team members. During these interviews I was mainly the recorder who took down notes of anything notable and sequences that our informants did. When necessary, I also helped create iterations on-the-fly and asked our informants some questions in order to test the usability of our prototype. During the interviews I focused on asking questions of how our informant would design a specific feature or what our informant would expect to see after clicking certain buttons or labels. After the prototype interviews I typed up my notes and posted them to our wiki. From these interviews, we discovered that it was not obvious for our users that the calendars could be come from different sources and that users could subscribe to them. It was also not obvious at first to the users where exactly to go browse other calendars -- it took them awhile to find the "manage/edit calendar" button since they had to look around for a few seconds. Both of our users suggested that there should be a "search" box on the front of the default "calendars" tab so it is more obvious that users are able to search for other calendars. We also discovered ways that our users wanted the "reminder" function to be designed --they wanted to have the option of choosing when and how often they want to be reminded of events. I learned from these interviews that paper prototype are very valuable tools to find re-design recommendations despite the fact that a paper prototype may seem primitive or unsophisticated. I also learned that iterations on-the-fly really help build the partnership between us and the users.
Next week, I plan on meeting with my group on Monday to conduct interpretation sessions about the prototype interviews and come up with design iterations. Next week I will also conduct 2nd round prototype interviews, purchase a binder for our group, and possibly begin talking about the final paper.
6/3/2007
This week on Monday I conducted interpretation sessions with my group for our first round of prototype interviews. I acted as the interviewer and the modeler during these sessions and drew sequence models on the board. From our interpretation sessions we discovered that the "class planner" tab was not be used enough to warrant a tab to itself on the calendar. We decided to take this tab out and just have the "to-do" and "view" panels one on each side of the calendar. We also discovered that multiple users had the problem of having a hard time figuring out how to search for other calendars or event, and multiple users suggested to just place a search box on the calendars tab so that it is easily findable. Users also mentioned that they would like include a deadline to their to-do items. It was also clear that we needed to have more organized and structured "browse" and "search" pages in our next prototype. We also discovered that we needed to find a better way to implement the "add a reminder" function because there were a lot of discrepancies as to how and how often users wanted reminders sent to them. After the interpretation session for the 1st prototype I helped design the second prototype by creating the "browse" and "search" pages that show the search results when users type in a search for something.
Later on in the week, I interviewed two other users with our second prototype. During the first interview I was the moderator, and in the second interview I was the recorder. From these interviews we discovered that our users really liked and preferred the view where the "calendar view" and the "to-do" panels were on each side, and not tabbed together. During these interviews we tested to see if the search function was improved, and we felt that it was because our users had an easier time searching for events this time around. We also tested the "add a reminder" function, and we also felt this was improved. One of our users gave us even more insight to the "add a reminder" function by telling us that he prefers to have the option to add multiple reminders for events if needed. Our other user also gave us the suggestion to be able to see a history of all the to-do's that he's ever had, and he also mentioned he would like to check off to-do items when he is done with them, which we thought was a good idea.
On Sunday our group met up and had our interpretation session with the interviews we did with the second prototype. For our final prototype design, we decided to have a new window pop up when a user is adding an event from their e-mail inboxes, include the ability to check-off to-do items once they are completed which adds them to a history list, have the ability to hide the " to-do" and "view" panels, include an "all campus events" tab along with the "search" and "browse" pages, and move the import/export feature into the "manage calendars" section because we discovered that it was a function that was used too less to warrant it having a real estate on the front page of our calendar. We also decided to improve the print function by giving users the option of printing either a Calendar view (which shows the calendar with events blocked out like on the actual calendar front page) or an Agenda view (much like a list of things to do) becuase one of our users suggested it.
On Sunday I helped build the final paper prototype by creating the front page, to-do tab, view tab, and put together the rest of the final paper prototype. I also organized the first and second prototypes so that we can put it into our binder. In addition, I created digital mockups of our interactive calendar with PhotoShop for the following pages: Homepage, Browse pages, Search pages, and the All campus events page. Our group also started on the final presentation.
Next week, our group will finish the final presentation and present on Tuesday. We will also begin writing our paper and finish putting together our binder.
Comments (0)
You don't have permission to comment on this page.