The overall design of this website focuses on simplicity to facilitate usability, learnability, and efficiency for elderly users. Each page was designed to highlight the functionality available to the user and eliminate clutter and noise that may distract and detract from the user experience.

We implemented our front-end in HTML, CSS, javascript, and JQuery with Foundation libraries; our back-end was built on top of django. The key design decisions are mentioned in the previous section.

The biggest challenge we encountered was because of different levels of familiarity with django, we divided our work not by feature, or the different pages, but by expertise. For example, most of the back-end implementation was done by Viksit, while the rest of the team focused on the front-end design. This created a problem because features that required integration of front-end and back-end components required two or more members to physically be in the same room.

Formative Evaluation Sheet

Aged to Perfection

Briefing

Our website is aimed at the elderly population as a way to connect with each other, foster community, and find information about hobbies and interests. You have the following scenarios you'd like to perform on our site.

Scenario Tasks

The following scenario tasks were given to our user testers.

1. Look through a list of health related questions and choose to answer one.
2. Find a person you don't know and try to connect with him or her with video.
3. After talking with an user through video, you decided to add him or her as a friend.

Specific Questions/Feedback

We included a guided questions list in addition to collecting feedback on the fly as well as if we noticed any critical moments during the evaluation.

How hard was it complete the given tasks? Did you find any of the tasks unintuitive?
Is there anything annoying on the site and do you find it fast enough to perform the things you wanted?

User Testing

For user testing, we interviewed three users:

• User1: A 65-year-old male professor at MIT; he is a regular internet user.
• User2: A 67-year-old male retired stock trader in Cambridge, who is also proficient at use of internet.
• User3: A third user is a 79-year-old female retired elementary school teacher without much computer experience. The testing was guided by a 30-year-old grandson who took notes and relayed info.

Usability Problems

• "How do I go back to home page?"
  • Description: Even though we have a grid to the top-left corner, it is not clear to the users that it brings them back to the home page.
  • Severity: Medium
  • Heuristic: Learnability; efficiency
  • Solution: Animate the home page grid zooming into the top-left corner.
• Post question was hard to use
  • Description: Posting new question was not intuitive. They didn't know they had to first click in the textbox to start typing and click on the button "Post" to post the question
  • Severity: Minor
  • Heuristic: Visibility; Help and Documentation
  • Solution: Fill the textbox with a grey "click here to type your question" background text.

• "Did I post something?"/"Where is my post?"
  • Description: After the user clicks on the "Post" button, the page refreshes with the user's answer buried somewhere in the middle of the page. He/she can't tell immediately if the post was successful.
  • Severity: Medium
  • Heuristic: Feedback
  • Solution: Instead of refreshing the page with new content, the button should dynamically insert content into the page and highlight the post that fades out gradually.
•  "How do I delete my post?"
  • Description: After seeing that he/she can edit his/her own posts, the user asks if it's possible to delete or take away the post.
  • Severity: Major
  • Heuristic: Safety; CRUD; User Control & Freedom
  • Solution: Add an "X" button, which will confirm the user's intent of deleting his/her post upon click.

• "Who are these people?"
  • Description: It is not clear to the users how the "Meet new people" section is formed. By age? By geography?
  • Severity:Medium
  • Heuristic: Visibility

• "I don't want to show them my camera; turn it off."
  • Description: Users are concerned with revealing themselves to strangers over the internet without knowing more about their identities.
  • Severity: Major
  • Heuristic: Safety; User Control & Freedom
  • Solution: Prompt the user for consent of turning on the web camera.
• Fonts are too small
  • Description: Depending on the apparatus, the font appeared to be too small for a particular user.
  • Severity: Medium
  • Heuristic: Readability
  • Solution: Use bigger font size in general and make sure the font family is easy to read.

Presentation and Demo

Presentation Slide:

Introduction

The guidance of GR1-GR6 was a very well structured way to guide a team into brainstorming, designing and implementing a service that's highly user centric. Although GR1-GR3 did an excellent job of refining multiple layers of design, the schedule division of the project series seemed front-light and end-heavy. In addition, the focus on core scenarios meant that we didn't get much feedback from secondary scenarios which are necessary for real users to exercise core scenarios, for example, login, registration, logout.

We've divided the feedback into a few sections:

Missing or Confusing Issues during GR1-GR6

Lack of prioritization of core, secondary, tertiary features:

The problem here is that a small detail, like font size is a secondary attribute of a core feature, but there was no clear division of priorities of which attributes or features were core to the scenario. This resulted in all attributes of a page being first priority, which resulted in less structured development cycles.

Lack of incentives for user testing:

Most users, which are dictated to not be students in the class, have no real, or monetary, incentive to user test seriously. The lack of incentives when recruiting user testers result in higher variance and noise when accumulating relevant feedback from users.

Lack of rudimentary guidelines for UI engineering:

Although alot of software design and implementation, in general, are learned from other classes or common sense, it would be nice to cover some high level guidelines on how to architect a website or service with a team. Some of the information covered can include, division of labor among group members for website design, how to structure javascript, django, node, etc. code elegantly to partition in a team, and what are expected engineering schedules/deadlines.

Lack of time for GR5:

The backend building and integration had been the most time-intensive GR of the semester, and slightly unexpected. While most of the semester is focused on UI design, some more time allocated to backend and frontend integration would really help iron out details, particularly for websites that are backend heavy.

Prototype Techniques

Throughout the class, we experimented with various design techniques, paper prototyping, iterative design, screen shot mock ups and modular design.

Some prototyping techniques are more useful than others, especially applied to different services and projects.

Paper Prototyping

For us, the paper prototyping was actually not very helpful because we didn't get a chance to test these on elderlies, who likely would have been quite confused regarding what the paper prototypes is supposed to do. In addition, we noticed that real users focused on mouse input, then keyboard input, and the design of the website was almost secondary.

Screen Casts

However, the screen casts were more helpful because it visually displayed pictures that associated the design in a more familiar environment.

Modular Design

Modular design was very helpful throughout the project, since we adapted modular pieces from the paper prototyping stage into implementation all the way through GR5. We divided the labor by the widget, textbox, or piece that was mobile in paper prototyping, which really help clarify ownership as well as making way for more modular code.

Iterative Design

Iterative design was likely one of the most useful concepts that was re-inforced in this class. In addition to highlighting one of the core fallacies of a over-zealous developer, it allowed our design and implementation to be malleable, adaptable, and in general a better product for our user population.

"Having worked in industry, it's a shame to not see iterative design being an active part of development cycles of major projects even in highly reputable software companies."

Another perk of iterative design is that it sets the bar low, in the sense that users are encouraged to change their design, subconsciously setting aside their developer ego.

Other

On another note, It would be nice to encourage the use of various prototyping techniques directly on the user population to find out which ones are more effective.

Subjective Evaluation of Results and Learnings

We've divided evaluation into a few themes we've encountered, with a brief background, analysis, and proposed possible solutions for the future.

Variance in User Population

There had been a high degree of variance among user trials, from GR1 to GR6. While some users wanted more features, other users were confused about what the current features were meant to do, and other users didn't know how to use the interface at all.

Part of this is due to elderlies having a wide range of computer experience, website exposure, and their receptiveness to design feedback that we take for granted. While our user population is 65+, some 65 year olds are quite tech savvy, while others have barely had any experience with technology at all.

The high degree of user feedback variance caused us to non-trivially shift design for our website a few times during design, all the way to the end of GR4.

The class did a good job of isolating user populations that are not inclusive of students in the class. However, for even assumed user populations, it would be nice to have a guideline on how to segment the proposed user population even further. For example, instead of 65+ seniors, perhaps segmenting further by age, or internet experience would drive our target user population to be more specific, and directly result in a product providing better user experience for users.

Risks

Mentioned a bit earlier, risk of project completion is fairly low throughout the class, from GR1 to GR4. GR5 came along and introduced several new risks, including schedule risk, implementation risk and team dynamics risk.

Since we've practiced the entire class designing front-ends, the quick deep dive into backend implementation introduced a struggle to integrate after we figured out how the schema for backend storage and implementation ideally should be.

The short time span for GR5, relative to the workload, also introduced schedule risks, in which we didn't get as much time to refine our final product as we'd liked.

Finally, due to the combination of stress, end-of-semester workload, and lack of comfort with backend implementation, it indirectly introduces a team dynamics risk which our team had not been alone to deal with. While every member of our team really gel'ed with each other and enjoyed each other's company throughout the semester, there was more understated stress during GR5, comparatively.

A possible solution maybe to briefly speak about these risks, either in section, or in lecture, and giving us more time for GR5, highlighting that we need to start early. A brief exercise in backend development, mandatory for the class, even if it's just participation, would help too.

Conclusion

This class is a highly rewarding class, and comparatively to other engineering, product-oriented design classes, has an excellent pace, highly useful content, and superb TA's. This doesn't mean that minor changes can't be made to make the class even better, iterative design, right?