Group Members
- Stephen Suen ssuen
- Kathy Fang kfang
- Yi Wu wuyi
- Connie Huang connieh
- TA: Katrina Panovich
GR1 - User and Task Analysis
GR2 - Designs
GR3 - Paper Prototyping
GR4 - Computer Prototyping
GR5 - Implementation
GR6 - User Testing
GR6 - User Testing
Design
The final design of our interface included the following components:
- Choosing initial wedding tasks: This is one component that was changed drastically since the first prototype of our design. We received complaints during both the paper prototyping and heuristic evaluation that the users were overwhelmed by the number of wedding tasks (and unsure of what each meant and if they could change them later) and thought that it cluttered the initial registration process. There were too many “big decisions” to be made without enough information about how to make the best choices. Heuristic evaluators thought this was very overwhelming and were unhappy with the lack of batch operation tools. we chose to take out this task and separate it into a settings page. we prepopulate the wedding tasks now and let users adjust them well after they register.
- Registration process: We decided to allowing users to input their wedding date initially because most people will know this when they are planning a wedding. We also decided to include a list of popular holidays. During paper prototyping, some users expressed concerns about their wedding date overlapping with important religious and national holidays.
- Timeline view on the dashboard: During the paper prototyping stage, the timeline view was tricky to understand in a paper prototype because tested were unsure of how responsive the timeline would actually be. Other alternatives included a calendar, nested timelines. We ultimately selected timeline view because we believed that it would be the least complex, easy-to-understand representation once implemented on the computer. From the heuristic evaluation, we reduced the unused vertical space of the timeline, and introduced a “stacked view” for easier visual differentiation between categories. We also eliminated the ability to drag events on the timeline because the users did not think it was intuitive or helpful.
- Event list view: This feature was added as a result of the heuristic evaluations. We received comments about having a centralized list of all the tasks associated with the wedding. Users testing showed that it was a good decision because they were happy with the ability to view the event as well as the event descriptions without the hassle of having to go to each event page separately.
Implementation
We used HTML/CSS/jQuery and a number of javascript libraries including D3 and Ruby gems including simpleform. To structure our content we used Bootstrap. We used Rails to implement our back end. Our system utilized four basic models: User, Wedding, Event, Comment. Establishing the relationships between these models early on helped us structure the rest of our content and how we chose to display it (e.g. a User has one Wedding, and a Wedding has multiple Events).
We found that using the default routes rails provides when you construct multiple views made it easier to separate some tasks into different screens instead of using modals (e.g. the Edit Event interface). This may be less efficient for the user (due to the increased number of pages/clicks required) but provides more feedback because navigating through different pages and receiving flash confirmation messages signaled to the user that changes were made.
Although we thought of a number of different ways to view all the events a user would encounter, we ultimately decided to create a timeline view and a list view. To prevent information overload on the dashboard page, we pulled out the unread comment section and gave it a standalone page. As with the Edit Event interface, this reduces efficiency but has the benefit of keeping the dashboard experience focused on the timeline and increasing overall readability due to the reserved page space.The jbuilder gem renders the events of each wedding as a JSON object that feeds into the timeline interface. We originally relied solely on the timeline view to display information to the user, but during the implementation process we displayed an unstyled list of events to easily see what was in the database. We found this feature so helpful that we decided to implement it as part of the user interface as well. This allows for greater efficiency in finding a specific event and supports list-oriented users in addition to visual users.
Evaluation
We tested the completely Hitched website on three different users. User 1 is a group member’s friend from University of Michigan who got engaged about 6 months ago. User 2 is a MIT senior who got engaged last week and is a member in our sorority, Kappa Alpha Theta. User 3 is a 22-year-old friend from the University of Arkansas who just proposed to his girlfriend. All three users are representative of the target user population because they are both females and male who are in the process of planning a wedding. For the MIT student, we conducted the user test in person. For the other two users outside of MIT, we conducted our user tests over Skype so we could observe their reactions and take notes while they are testing.
Before they were directly to our website, the users were briefed with the following:
“Many brides-to-be plan their own weddings without the help of a professional wedding planner for financial reasons. The aim of our app is to provide comprehensive guidance on the scheduling of tasks and events related to the wedding. Additionally, the app allows involved parties, such as family members, to provide their opinions during the wedding planning process.”
They were then asked to perform the following tasks:
1. Register for Hitched, including inputting their wedding date
2. Change the date and description of Edit Guest List event.
3. Add a comment to Set Up A Registry.
After observing the three user tests, we discovered a small number of usability problems that are worth noting. Below we list the problems as well as possible solutions
- Users would like an indicator for when tasks are complete. Possible solution includes adding a completion checkbox in the list view or making an unfinished/finished option on the event page
- Need to edit important fields, such as date/time of the event on the hovering view of the timeline. This is an efficiency issue. Users were frustrated at the need to go onto the event page to edit every single event detail.
- Users wanted to be able to sort and filter the list view. Currently, all the events in the list view are shown on the homepage. Although they are grouped by categories, we cannot view only 1 category and the whole list is sometimes overwhelming to our users. One solution to this problem is to allow filtering and sorting of the list view so that the users can view a selected number of events at a time
- The ability of add your own event: This was a question brought to us by 2 out of the 3 users. However, we had previously decided to not implement this to limit the scope of this application. Additionally, since this application is designed for people with little wedding experience, we wanted to guide them throughout the process. We included al the major events of wedding planning taken from professional sites like theknote.com, so we didn’t foresee users adding additional tasks
- When selecting wedding date, we should see the dates of the holidays. Currently, we only show a list of the holidays but not the dates. It would be helpful to list them.
- Be able to see the day for each event. Currently, we only show the date but not the day of the week. This information would be useful to figure out business hours of certain vendors.
Reflection
The iterative design process taught us the importance of being flexible with our design, prototyping, and testing with users.
Flexible Design
Throughout the prototyping and user testing process, we all realized that we need to continually adapt our design based on feedback from other team members and users. Initially, we each had different design ideas and prototype sketches. After evaluating the pros and cons of each design alternative, we created a paper prototype that incorporated the most user-friendly aspects of our different designs. This process showed us the power of brainstorming as a group and coming up with a collaborative design. Similarly, each round of user testing showed us issues that we had previously not considered. For example, users struggled to use certain features (such as dragging events around on the timeline) and suggested that we build additional features (such as a list view of events). As a result, we changed our design to increase learnability, safety, and efficiency at each iterative step. This required many frequent changes to our design. Hence, we learned that we should adjust our design (making both small and large changes at each iteration), rather than be set on a specific design.
Paper Prototyping
In addition, we learned about the usefulness of paper prototyping. None of us had ever used rounds of prototyping to build an application, so we were initially skeptical of how effective prototyping could be. However, after our first paper prototyping round (with other 6.813 students in Walker Memorial), we were convinced that prototyping could generate many useful comments. Even though our paper prototypes were primitive, in that a group member served as the back-end and some features were roughly sketched out, we still received valuable user feedback on the layout and progression of our screens. We found the most difficult part of paper prototyping to be creating a realistic experience for the user. Many features easily implemented on the computer (such as drag/drop, drop down menus, etc), were difficult to replicate using paper. As a result, we found that paper prototyping was the most useful for helping us make broad design choices, such as choices on the overall setup and layout of key features (i.e, comments). In the paper prototyping stage, we chose to prototype all the layouts of our main pages, including the registration & select events page, timeline, event page with comments, and edit event page. However, we did not fully prototype certain features that required more extensive back-end. These un-prototyped features were (1) adjusting the timeline after the user edited an event, (2) showing dates as the user dragged an event around on the timeline, and (3) populating the timeline based on the user’s selection of which tasks to include.
Computer Prototyping
Computer prototyping, on the other hand, provided useful feedback on both broad features and detailed design issues. We prototyped all of the front-end for our design, but gave users canned responses because we did not prototype the back-end. Specifically, as mentioned in GR4, we allowed users to edit events and add comments, but these edits were not stored in the back-end and thus disappeared after the user refreshed the page. We also did not prototype the back-end of the registration system, so users who created logins could not login with those credentials. Our timeline was pre-populated with events, instead of populated with user selected events. We did not implement much of the back-end for our computer prototype because we wanted to focus on testing the feel of the user interface.
Many of the heuristic evaluations pointed out small design inconsistencies that detracted from the user experience (i.e, font and color). Computer prototype testers also pointed out large design issues (i.e, an overly complex registration system). Computer prototypes were much more costly to implement than paper prototypes, and thus made sense to implement only after paper prototyping refined our design. We found that computer prototyping generated more useful comments than paper prototyping because our computer prototypes had a higher fidelity in feel, leading to a more representative user experience.
User Feedback and Evaluation
As mentioned above, users provided valuable insight into the learnability, efficiency, and safety of our application. Our prototype users helped us modify the layout of certain screens, decide which features to eliminate and add, and found inconsistencies in our design. Users generally understood the main features of our application (timeline, events, comments). They became more familiar with the timeline, the most complex feature, as they interacted with it. Hence, we believe that our user interface is highly learnable. Our users were also able to recover from any mistakes, such as editing an event with the wrong time or selecting the wrong wedding date. We purposely incorporated the safety features into our design in anticipation of such user mistakes. Finally, users were able to complete tasks in a short time period (1-2 minutes), so we believe that our design is efficient, although the efficiency could be improved even further with additional design changes. Overall, we believe that our application has low risk in terms of learnability, safety, or efficiency.
One of the most challenging issues that we encountered was dealing with user feedback regarding the scope of our application. During our briefing, we told users that our application was designed to guide engaged couples through the wedding planning process by helping them visualize the timing of important tasks. Even though we focused on the timeline aspect of wedding planning, some users suggested that we increase the scope of our application. For example, users wanted to ability to link to their Pinterest sites, post pictures, or pick items for their registry. While we agree that having a comprehensive wedding planning site would be highly useful, we did not think we would have enough time to implement such a site. We compromised by keeping the comments feature (enabling users to share ideas with friends/family), but not implementing other features (such as photo boards).
What We Would Do Differently
One of the main things we would do differently is present users with several different initial paper prototypes. As mentioned above, we initially each drew different sketches for paper prototypes. As a group, we decided on a paper prototype, taking elements from our individual sketches. For example, in our individual designs, we represented events using a timeline, to-do list, and calendar. After debating the pros and cons of each design, we decided to use the timeline. However, we think it would have been useful to create several several different paper prototypes to test on users. This way, we could see if users agreed that the best design was the timeline, rather than the to-do list or calendar.
If we had more time, we would implement more features, such as the photo board, suggested by users. This would allow our application to be a more robust wedding planning tool.