Description

5/5 - (3 votes)

In lectures we have talked about the User Centred Design process. We have described that the process starts out being creative, unknown and ill defined, but by following the user centred design process, you come to understand the design problem from the users’ perspective before you write one line of code (and in this course, we don’t write code). This process is what Buxton (Buxton, 2008) calls the “design funnel”. At the beginning, there are lots of possible ideas and as the process advances, the design is refined into a single defined vision that follows an ordered and well-defined process. As the design matures, you as a designer, continue to be self-critical of the design, considering aspects like design principles and user experience goals (that you learned in the first assignment) to improve the overall design.

In this group assignment, you will be exposed to the initial phase of the user centred design process. The outcome will be a first set of paper prototypes that you will evaluate using formal usability tests.

You will form your groups with other students from the same tutorial during the Week 2 tutorial. Each person in your group will play a specif role during the project. It is important to work efficiently together as a team to achieve timely deliverables. There will be several exercises and checkpoints to be carried out during your tutorial/laboratory time slot, some of these components will be assessed in those time slots. Other activities during the tutorial will be necessary to be able to continue with the assignment. Details of each of the checkpoints are provided in the detailed specification section of this document.

The user interface critique in Assignment 1 introduced you to the possibilities and pitfalls of designing user interfaces, whether they are websites or mobile applications. It has also introduced you to terminology and approaches for formally evaluating user interfaces. In Assignment 2, you will evaluate your own design outcomes against the given frameworks.

The deliverables for the postgraduate and undergraduate will be slightly different. Undergraduates and Postgraduates will both be designing an interface with the theme of “Bushfire safety”, but will each have a slightly different focus.

Context

Name: COMP3511 Assignment2 Solved
SKU: 63261
Price: 30.00 USD
Availability: InStock

You will be designing an interface for the overall theme of ‘Bushfire Safety’.

Australia has experienced its worst bushfires in decades with millions of hectares of bushland burnt to the ground, the loss of property with whole towns being wiped and sadly loss of life. Bushfire season in Australia usually commences in October and goes until March, it is important to be prepared before bushfires strike. We need to be able to have access to resources and understanding of how to prepare, act and survive.

As a team you are to design a system with the broad theme of ‘Bushfire Safety’. It is up to your group to choose ONE specific area of focus within the theme. For example, you may focus on bushfire preparation, a warning system, or an alert system in the case of bushfires already burning (or other areas of course, these are just three possible areas). Other functionality should be considered also, these just provide some examples of where you could go with the theme.

Your system may allow users to:

Monitor bushfires around your locality
Monitor road closures
Wildlife monitoring/rescuing
Provide education on preparing for bushfires
Provide statistics
You may consider other functionality as well

Both Undergraduate and Postgraduate students will consider an interface for either traditional desktop/laptop computers or tablet computers.

You can all consider any group of users, however you will need to focus on the following group of users as well:

Undergraduates will consider the needs of families. A family unit must consist of at least two people living together, and should include either young children, teenagers or elderly parents, or a combination of these. Consider who the users are that you have the most access to for developing requirements.

Postgraduates will either consider the needs of farmers who must also care for cattle OR consider older adults (45+). Choose your group based on the users that you have the most access to for your interviews.

High-Level Overview

Following you will find a high level list of the steps involved in completing this assignment. The checkpoints for each step or set of steps are listed below.

Form groups of 3-4 during the tutorial time.

This step to be finished by the start of the second week 2 tutorial.

Your tutor will then take down your group name and the names of the students in your group. Your tutor will then create a Teams space for you. You will use this space for all assignment related discussion and sharing of documents, any collaborative work you undertake.

You will each have a role to play within your project. The possible roles are:

Product designer: oversee the product, understand objectives and requirements, management of things. Is responsible for desigining and coordinating the interviews/data collection
Media/marketing – branding: co-ordinating and creating paper prototypes based on group findings
Researcher (common for group): this process is done by everyone in the group but led by the researcher. The process involves writing scenarios, creating personas, brainstorming and researching needs of your users
Architect designer: how to design the system based on requirements? You are responsible for organising the testing and analysis of your paper prototypes.

If there are three group members, than one of these roles will spread across all the group members. Decide on each group member’s role. Your role puts you in charge of particular stage/process in the design lifecycle but you can still share the actual workload as you deem appropriate. The actual process should be documented as you go along.

In the second tutorial of Week 2, brainstorm ideas of a product or system
In a group meeting (and using Teams for any online discussion and as a repository for all your work), establish a shared vision of a product or system. Consider the design objective, the audience and develop a preliminary product description statement.

These steps to be finished by the end of the second tutorial in week 2. Checkpoint in tutorial.

Each group member is to develop initial context scenarios describing potential users of the product or describe how a person’s goals relate to the product.
Refine and discuss the individual context scenarios and personas in a group meeting: the purpose of the meeting is to come up with one set of context scenarios (there might be several different prototypical users). Storyboarding might also be useful as part of this process. Remember to upload any minutes or documents of the meeting to your Teams Space.
Discuss in a group meeting the functional and non-functional requirements of the product. Remember to upload any minutes or documents of the meeting to your Teams Space.
Develop a group questionnaire to ask people who match the intended audience and prepare the consent documentation. Use your Teams space for any online discussion and as a repository for all your work and collaboration.

These steps to be finished by the end of the first tutorial in week 3. Checkpoint in tutorial.

Run a pilot interview using the questionnaire to identify flaws in the set of questions and process. Refine as necessary, documenting the rationale.

To be done in week 3 first tutorial if there is time, AND in your own time.

Each group member will interview 2-3 people and record the outcomes of the interview. This needs to follow ethics and privacy principles discussed in lectures. Each member must have passed the ethics quiz BEFORE conducting any interview.
Analyse all the interview data and develop one summary report of the interviews. Remember to use your Teams space for any online discussion and as a repository for all your work and collaboration.
Based on the interview analysis, consider the refinement of the following items:
1. Product Description Statement;
2. Context Scenarios to be used in the subsequent design processes; and
3. Requirements (functional and non-functional).

These steps to be finished by the second tutorial in week 3. Checkpoint in tutorial.

Develop your paper prototype to cover some of your key paths. Remember to use your Teams space for any online discussion and as a repository for all your work and collaboration.
Prepare a usability test plan, considering which aspects of the current design are to be evaluated. Remember to use your Teams space for any online discussion and as a repository for all your work and collaboration.
Conduct a usability test.

To be presented in the first tutorial in week 4. Checkpoint in tutorial.

Conduct several other usability tests (two per group member) outside of class. Each individual observer must prepare an issues table, documenting all the issues discovered in that test.
Consolidate the group issues table, using the previous results. Remember to use your Teams space for any online discussion and as a repository for all your work and collaboration.
Review the overall issues table and assign priorities to the issues. Remember to use your Teams space for any online discussion and as a repository for all your work and collaboration.
Review the current design. Remember to use your Teams space for any online discussion and as a repository for all your work and collaboration.

By the middle of week 5, you should be at this point.

Reflect, individually, on the role that you played within your team during the project. Reflect on the value of the role that you filled and the user centred design process overall. In the context of your role, provide a critical reflection of why this position is important within the lifecyle – describe the most important lessons you have learnt from this assignment process overall including both positive and negative ones, and also what you would have done differently if you had more time or as a result of what you have now learnt? Consider this in terms of both your own team and the assignment team structure that you were constrained by. (This deliverable should be worked on individually and submitted electronically).

Week 5. Individual Reflection to be submitted via Moodle by Thursday 6^th Febuary midnight.

Final presentation

To be presented in the second tutorial week 5 (slides due beforehand).

Online peer review.

Administration

nment help

General questions regarding Assignment 2 should be posted in the Assignment 2 forum in the Moodle class website.

Assssment

This assignment is worth 30% of your final mark. This will include written and oral assessment exercises due at regular intervals. Your mark will also take into account your contribution to the group and will be scaled according to your contribution evaluated in the peer assessment. The basic breakdown of marks for this assignment is as follows:

Component	Worth
In-Class Tutorial Checkpoints:
Product Description Statement (PDS)	1%
Consent Documentation and Questionnaire	1%
Revised PDS Final Context Scenarios Requirements Questionnaire and Interview Summary	5%
Paper Prototype Usability Test Plan (UTP) In-class usability testing	5%
Presentation Week 5	8%
Individual Component – Reflection	10%

Some group work will be assessed in tutorials. Any group member who is not present during the tutorial checkpoints will be penalised unless they can present documented evidence relating to their absence.

Any member of a group who does not present in tutorials in Week 5 will receive zero for their group presentation, unless they can present documented evidence relating to their absence, for special consideration.

See https://www.engineering.unsw.edu.au/computer-science-engineering/aboutus/organisational-structure/student-services/policies/essential-advice-for-cse-students

Peer Review

Students must declare their contribution to the group work in the assignment that is confirmed by all members of the group. In addition there will be an online peer review process to gather peer assessment of each other’s contribution. The peer review process relies on confidentiality to be effective, so please do NOT discuss details with your fellow group members. This will be used to scale marks based on contribution.

Anyone who does not complete the online Peer Review by the Friday of Week 5

(midnight, Friday 7^th February) will be deemed to have not contributed to the assignment and may thus fail the assignment. Peer review MUST be completed and in a timely manner.

Intellectual Property (Ref: COMP1972, Richard Buckland)

Copyright of any material you submit will belong to The University of New South Wales. Submitting means you accept this condition. If you have special circumstances and wish to negotiate variations to this condition you must do so before submitting.

One of the reasons we require this is so we can share your work with students in this and future sessions. We may also use it to demonstrate poor style and/or common mistakes.

We usually try to keep student material anonymous. However, if you would like to be identified as the author of a work regardless of whether we are praising the work or not, then include this on the assignment cover sheet. If you only want to be identified as the author if we are praising the work, please make this clear on the assignment cover sheet.

We may distribute and share any material you submit, including but not limited to assignments, reports, papers, presentation handouts, seminar material, videos, wiki, lab solutions, emails and forum content. All copyright and intellectual property arising from this belongs to the University.

Submitting material includes but is not limited to physical submission, submission via Moodle or give, posting material on the forum or wiki, sending email to the teaching staff or course account, etc.

Hardware Platform Assumptions

You may assume that you have a standard desktop with a 24-inch screen and/or a standard 10-inch touchscreen tablet. All other devices need to be approved by your tutor.

Steps and checkpoints

Most of the feedback and marking you will receive will come from your tutor during tutorial time. This is what is called a checkpoint. For each checkpoint, there will be a list of items you must have completed and brought to class in case your tutor needs them to complete the marking. If you have completed this list, you will be able to answer any questions asked by your tutor. Some assessments will be written and others presented orally in a few minutes with visual or written support. You must be very clear as your tutor has little time to assess your work. Be precise and concise. Be prepared and ready for questions and do not expect to fix up your report 5 minutes before the tutorial.

Step 1 – Forming Groups

Form a team of 3 or ideally 4 people. All members must attend the same tutorial and be in the same cohort. No groups are to be a mix of 3511(undergraduate) and 9511(postgraduate) students.

To be finished by the start of the second tutorial in week 2.

Step 2 – Teams/Roles within your team

Your tutor will create a Teams space for you. You will use this space for all assignment related discussion and sharing of documents, any collaborative work you undertake.

Now, you need to assign roles to the students in your group. Make a decision, who will fulfil which roles. Please note that a lot of tasks are also shared across the roles. The possible roles are:

Product designer: oversee the product, understand objectives and requirements, management of things. Is responsible for designing and co-ordinating the interviews/data collection
Media/marketing – branding: Co-ordinating and creating paper prototypes based on group findings
Researcher (common for group): this process is done by everyone in the group but led by the researcher. The process involves writing scenarios, creating personas, brainstorming and researching needs of your users
Architect designer: how to design the system based on requirements? You are responsible for organising the testing and analysis of your paper prototypes. If there are three group members, than one of these roles will spread across all the group members. Decide on each group member’s role. The group process should be documented as you go along.

Step 3 – Getting Started

In your second Week 2 tutorial, use group brainstorming and creative thinking to discover possible ideas of a product. As a group discuss all the ideas of the brainstorming session, and decide on your final product.

Step 4 – Product Statement

In the same tutorial, you will now start to hone in more of what the final product is by writing a product description statement. Remember to use your Teams space for any online discussion and as a repository for all your work and collaboration.

The discussions should be creative and consider all possible ideas and the possible audience, but the result of this step is one shared vision, described as a product description statement, a maximum 30 word statement stating what the product can do for the intended audience. Note that this is the preliminary vision; it will change and improve when you follow the later stages in the design.

Show the statement for comment and approval to your tutor along with some ideas for your audience. You cannot continue with your assignment until the step is completed.

Checkpoint at the end of the second tutorial in week 2: Product description statement, written, 30 words.

Step 5 – Imagining your Users

Individually and using the product statement, develop two (2 per group member) context scenarios that describe users engaging with your system to satisfy their needs and goals. Recall that at this stage, there is no concrete system that has been discussed so your context scenarios should not focus on user interaction specifics like the names of buttons and the way that the interaction takes place, rather on the overall functionality.

This step does not require you to talk to anybody, in fact we are asking you to do this in isolation. (Later you will consider and reflect on the impact of involving real users in the process.) Instead, you must imagine the users.

A context scenario focuses on describing a person (with a name and age) who has goals and objectives with respect to the product. Describe the sequence of actions and events that this person will experience when interacting with the “black box” system that is your product. Think high-level goals and intentions; don’t focus on any specific technology.

Find a photo image from the free stock libraries online that best portrays the person described in your scenario. Remember to use your Teams space for any online discussion and as a repository for all your work and collaboration.

Step 6 – Combining the Context Scenarios

As we have discovered in the brainstorming and mind mapping lecture, each person is capable of coming up with ideas and the number of ideas shared in common is fairly low. Hence the more people working in a group, the more ideas that could potentially be generated. This holds true for developing the context scenarios; whilst everybody started out with a shared vision and the same product definition statement, the thinking and the outcomes for developing the context scenarios could be quite different.

Using the individual context scenarios from the previous step, consolidate them into one set per group, by for example, combining the individual contributions and generating 2-3 group context scenarios. These scenarios will be used throughout the design process.

One possible method is to use a storyboard process to help everybody understand how to combine the context scenarios.

After the process is complete, review the product definition statement. Do your scenarios support the product definition statement? Modify the statement as needed. Remember to use your Teams space for any online discussion and as a repository for all your work and collaboration.

Step 7 – Functional and Non-Functional Requirements

In software engineering we define a system in terms of requirements (Interaction Design, page 390, 392 and your lecture notes). Requirements describe explicitly the mandatory ways in which the system must operate. Functional requirements relate to the technical aspects of the system, whilst non-functional requirements refer to other aspects of the system that are generally non-quantitative. For example, usability goals fall under the nonfunctional requirements. (See Interaction Design page 390, Table 11.1 and Chapter 11).

Based on the current definition and understanding of your product-to-be, consider the requirements of the design problem. Later, as you refine your design, the requirements will most likely change. So don’t feel pressured to come up with the perfect set of requirements right now. Consider both the functional and non-functional requirements. Remember to use your Teams space for any online discussion and as a repository for all your work and collaboration.

Step 8 – Developing a Questionnaire

So far, the context scenarios you created are based mostly on your own ideas and thoughts. They have not been guided by information from representative users that make up your application’s target audience. With the use of targeted interviews, you will refine the scenarios.

First individually, develop a series of questions to ask potential users of the system. Then as a group, review each individual’s questions and combine these, to formulate a single written questionnaire. Remember to use your Teams space for any online discussion and as a repository for all your work and collaboration.

Keep in mind that this survey is not of a personal nature. Its purpose is to understand the needs and goals of your user audience using your product. So the questions must focus on issues relevant to the chosen topic. You should consider different forms of questions to ask: single or multiple choice questions, rating scales and open questions where the participant writes a response.

As part of preparing the questionnaire and interview session, you must prepare the consent documentation. A sample form will be available on the class web site.

You must present your questionnaire and consent documentation to your tutor for approval before you run an interview session.

You must also complete the ethics quiz (in Moodle) and pass it before you are permitted to approach users.

Checkpoint end of the first tutorial in week 3:

Questionnaire and consent documentation. Written with oral explanations.

Week 3: ethics quiz, should now be fully completed online (this was done in week 2 tutorials, but you need to achieve 100%, so you may need many attempts).

Step 9 – Run a Pilot Interview

To check that your survey is clear and understandable, run a test interview session with somebody outside your group (a fellow UNSW student should be used, and they can be from your HCI class). Run the full test which includes describing to the participant the consent and privacy processes, running through the questionnaire and interview, and thanking him or her. This process should take about 15-20 minutes.

During the session, one member is to guide the interview, while the rest of the team members are observers, with one taking notes. After the interview, discuss what was observed and what changes should be made to the questionnaire. Make the required changes and repeat the process until satisfied with the questionnaire. Document all the changes and problems found.

To be done during or after the week 3 tutorials, depending on time constraints, AFTER receiving feedback from your tutor. Although this is to be done in your own time, do come prepared in case there is spare time in the lab.

Step 10 – Actual Interviews

With the final copy of the questionnaire and the consent documentation at the disposal of each group member; the understanding of the ethical and privacy requirements by each member, the group is ready to interview friends, family and other students (ideally not in the HCI class). Carry out the interviews in pairs, with one person facilitating the interview and the other taking detailed notes.

The number of interviews to conduct is a minimum of 2 interviews per group member. If you are in a 3-person group, we expect 6 interviews conducted, and in a 4-person group, at least 8 interviews.

After each interview, when the interviewee has departed, review and summarise the findings of the interview. Document what was discovered from the interview.

Step 11 – Analysing the Interviews

Once all the interviews have been conducted, meet to summarise outcomes by reviewing the results of the previous step and discuss the trends and unique observations. Make sure to use Teams throughout the process for your discussion and document repository/collaboration.

Quantitative questions (i.e. those with rating scales) should be graphed on a histogram and averages considered (but for small numbers of participants, averages may not make sense – the distribution might be bi-modal, for example).

Summarise the interview process including the following:

What did the group discover from the interview process?
What were the results? Both quantitative and qualitative results should be summarised.
What techniques were effective during interviewing?
How do the outcomes of the interviews affect the existing product definition statement and context scenarios?

Step 12 – Iterating the Current Documentation

Step 9 represents the first real contact with potential users. Step 10 shows discoveries that the group did not initially anticipate: new ideas as suggested by the interviewees or ideas that the group came up with after the interviews. You may also find that some ideas simply won’t work, possibly because the original ideas don’t meet user’s goals and needs. Review the documentation completed so far and make the appropriate changes and updates to the product description statement, context scenarios, and requirements. Document and discuss in a group meeting, the reasons for the change, justifying with reference to the interviews why the change has become necessary. Remember to use your Teams space for any online discussion and as a repository for all your work and collaboration.

Be prepared for change.

Checkpoint end of the second tutorial in week 3:

Your tutor might not ask you for everything but you must have all the documents ready for him or her to check and be ready to answer any questions he or she may ask. You need to prepare:

Revised Product Description Statement (30 words)

Final set of Context Scenarios, 2-3 scenarios for each group (1 page per scenario, maximum)

Requirements list (1-2 pages)

Questionnaire and Interview Summary (1-2 pages)

Step 13 – Paper Prototype

In this step, you start to develop the interaction and visual design of the system.

The first question to ask is what sort of interaction to incorporate into the design. Are the users working through a wizard-like interaction or do they explore information presented to them?

Use the outcomes of the previous steps to help organise the layout/flow. This will help you follow the sequence of paper prototypes. As you develop your visual designs, go back and read the context scenarios and imagine the person in the context scenario interacting with your current prototype.

Prepare as a group for your next checkpoint, and remember to use Teams for your discussion and document repository/collaboration:

Paper prototype (at least 10 pages of sketches, one screen per page – you will need to have covered any screens that are needed for your task scenarios)

Step 14 – Preparing the Usability Test Plan

In this step, participants interact with the paper prototype. The purpose of this activity is to assess whether the design (in paper form) is usable by real people.

You must decide what needs to be tested and how you should run the test. Then you must prepare a set of task scenarios (Rubin p.182) to help the test participant understand the overall goal.

The task scenario is different from the context scenario. It is used for evaluation purposes. It gives the participant an overall goal and context so they have enough information to carry out the task on their own. We do not describe every step that needs to be conducted. This is just an overview. The purpose of the test is to discover whether people can naturally use the design. You are not trying to give them step-by-step instructions to follow your design.

Task Scenario Example

You are interested in watching a particular movie tomorrow night. You would like to see what movies are available to you and when it would be convenient to watch (and maybe when other members of your household are available).

Note that when running evaluations, it might be more appropriate to break a large task scenario into smaller achievable goals rather than having one large complex scenario.

Setting up the usability test plan requires that you document the steps that will be required to run this test. It also requires that the full set of consent forms be prepared for the test. In addition you need all your paper prototypes to be ready.

The litmus test for assessing this is to consider whether you could give this set of documentation to another person and they are able to carry out the test, providing the necessary reporting that your team requires.

Step 15 – Running a Usability Test

In the first tutorial of Week 4 you will carry out a usability test that is based on the usability test plan in Step 14. Observers will need to take notes and prepare an issues table that documents the findings of the test. This will be used as an opportunity to practise running the test.

Based on the experience of running this test, which is similar to a pilot test, make changes to the test plan where appropriate in readiness for further usability tests.

Checkpoint in the first tutorial in week 4:

Paper Prototype (10 pages of sketches, one screen per page – you will need to have covered any screens that are needed for your task scenarios)

Usability test plan

Run usability test in tutorials.

This will be assessed by your tutors, so make sure you come well prepared with all your documentation. Watch the videos available on Moodle describing and showing a Usability Test being conducted.

Step 16 – Running your own Usability Test

Now that a pilot usability test has been run, each group member is to facilitate two usability tests using the usability test plan finalised in Step 14. You should consider how you will carry this out in groups. These tests will be with potential users that you will need to find and will be carried out outside of tutorial/lab times. The participants should be family, friends or other UNSW students. Standard procedures that involve ethics, consent and privacy are required.

Observers from the group will need to take notes and continue to fill out the issues table started in the previous step. At the end of all tests, you will have a complete set of issues tabled, which includes the usability test from week 4, plus the two tests for each person in your group.

After each test, the facilitator and the observer must discuss the findings and document them.

Step 17 – Compiling the Usability Testing Outcomes in an Issues Table

Combine all the issues tables from each test into a single issues table, showing the issues down the first column and the results for each participant in the other columns. Once all the information is combined, it is possible to see trends in the results. Remember to use your Teams space for any online discussion and as a repository for all your work and collaboration.

Step 18 – Interpreting the Outcomes

Add an additional column to the issues table to keep track of the priority that your group will assign to each of the issues.

Review all the issues uncovered and interpret the trends. Remember to use your Teams space for any online discussion and as a repository for all your work and collaboration. It may be more appropriate to find groupings of issues so that you can discover whether there are any patterns in the outcomes. A series of issues might relate to say the terminology that might be spread throughout all the tasks evaluated. When grouped together, this collection of issues may become more apparent. You may consider using techniques such as affinity diagramming to analyse the results.

By the end of this process you should be able to prepare both quantitative and qualitative assessment of your design that is based on real user testing.

Based on the assessment, assign a priority to each issue (or collection of issues). You will use the following priorities:

4 = showstopper (cannot release until fixed)

3 = major problem (must fix)

2 = minor problem (should fix)

1 = cosmetic problem (fix if there is time)

0 = not a usability problem (e.g., bug)

Step 19 – Review the Design

With a prioritised issues table and a discussion within your group about the outcomes of the usability tests, review the paper based design to determine what changes need to be made in the current design. Remember to use Teams to aid with your discussion and keep a repository of documents/collaboration.

Prepare a numbered list of items to be corrected with their priority. You will then annotate a copy of the current design with the numbers as well as a short description of what needs to be changed. Provide a recommended solution to each of the suggested changes.

Note that we have asked you to prepare a prioritised list. Use the priorities to focus on what areas are important and provide a subset of proposed areas for change. We want you to be able to discriminate between important changes versus non-important changes.

As part of the review, consider the techniques discussed in Assignment 1 and review your design against user experience goals, usability goals, design principles and heuristics.

By the time of your first tutorial in week 5, you should at least be at this point. There is no formal checkpoint, but this is a good opportunity to ask questions, especially if you feel you are behind. Your final presentation is one tutorial away. You will get this tutorial and two hours of the lecture time on Tuesday 4^th February (Week 5) to work together on your presentations.

Step 20 – Reflection on the User Centred Design Process – Individual Submission

Now that each group member has experienced first-hand the user centred design process within their designated role within the group, it is time to reflect on what you have done so far. What did you learn from this process and what can you see are the benefits of the process?

In 500-600 words, reflect, individually, on the role that you played within your team during the project. Reflect on the value of the role that you filled and the user centred design process overall. In the context of your role, provide a critical reflection of why this position is important within the lifecyle – describe the most important lessons you have learnt from this assignment process overall including both positive and negative ones, and also what you would have done differently if you had more time or as a result of what you have now learnt? Consider this in terms of both your own team and the assignment team structure that you were constrained by. If space permits you can also make reference to the other team members roles and their value. (This deliverable should be worked on individually and submitted electronically).

Week 5 (due by midnight Thursday, February 6th): Each person in the group must electronically submit (through Moodle) an individual reflection of the user centred design process, from the perspective of their role within the team.

Step 21 – Presentation

With your group, you will present the process and result of the user centred design process that your group experienced in this assignment. You have 12 minutes to present your work in front of your tutorial classmates during the second tutorial in week 5.

You should summarise your findings, pinpointing the important aspects of the process according to your group, and how you reached your final design. To do this, you must present the final issues table, the list of recommended changes, and highlighted sketches of where these changes need to be made.

Further, Undergraduates only must include a brief discussion (1 or 2 minutes) of how their design met the needs of families. They should discuss design concepts, and perhaps detail some interface elements that were the focus of these types of users.

Postgraduates only must include at least 2 minutes detailing how their design met the needs of farmers OR older adults. They should discuss design concepts, and perhaps detail some interface elements that were the focus of these types of users.

Each member of the group is required to contribute orally to this presentation. You may use Powerpoint slides to support the presentation and these must be submitted to your tutor before the tutorial.

Week 5: Final presentation during tutorial times. Presentation file is to be submitted before the tutorial.

Step 23 – Peer Review

You must fill in an online peer review of each of your classmates’ contributions. If you do not fill in this peer review, the markers will assume that you did not contribute to the group’s work and your mark will be reduced or may be zero.

End of week 5 (Friday midnight Febryary 7^th).

Deliverables and Timelines

Week	What is due
Week 2 (second tutorial)	Form groups of 4 people from the SAME tutorial group. Product Description Statement Complete Ethics Quiz in Moodle, if not already completed.
Week 3 (first tutorial)	Consent documentation Questionnaire Pilot interview (own time)
Week 3 (second tutorial)	Revised Product Description Statement Final Context Scenarios Requirements list Questionnaire and Interview Summary
Week 4 (first tutorial)	Paper Prototype Usability Test Plan (Sample will be made available on Moodle) Usability test: Usability evaluation and assessment of design
Week 5	Individual reflection due by Thursday 6^th February midnight
Week 5 (second tutorial)	Final group presentation (submitted prior to tutorial), covering the following: 1. Copy of the original design following step 14 2. Final issues table 3. List of recommended changes (each change numbered) 4. Final design prototype (with numbers indicating the change, annotated alongside the relevant design) 5. Undergraduates only: Discussion of design for families. 6. Postgraduates only: Discussion of the needs of farmers OR older adults. Fill out online peer review

COMP3511 Assignment2 Solved

If Helpful Share: