Wedding Planning Website Application: Pass 2€¦ · designed as a wedding invitation system that...

EECE 418 – HUMAN COMPUTER INTERFACES IN ENGINEERING DESIGN

Wedding Planning Website Application: Pass 2

Group Ahahahah

Stanislav Zarud 67950089

Ryan Randhawa 62768080

Steven Singbeil 73939068

William Gallego 13370077

Wedding Planning Application Group Ahahahah

A1 Redesign Rationale

In Pass 1, the project scope was focused on providing a wedding planning system that

could be used by anyone that was invited to a wedding. Essentially, we created an

invitation system that people could use to RSVP to an event. The mental model for this

system was more similar to a conference RSVP system than a wedding invitation.

After the design review, it became clear that the focus of the system had to be changed

to fit the wedding card mental model. Traditionally, the mental model for a wedding card

from the perspective of a guest is a "receive and send" model, where the guest receives

a wedding card and sends an RSVP card. With our system, the mental model was a

"receive and confirm" model, where the guest receives the invitation and has to confirm

their attendance by inputting their information into the system. Since the guest does not

send anything back to the wedding couple or wedding planner, we may not have a

complete system based on the traditional model, and users may have trouble adapting

to the new system. Alternatively, one could argue that since weddings are not common,

we may want to utilize a more common mental model and use transferred user

knowledge to provide a system that the user already knows how to use. Since most

users will have used something similar to a Doodle poll or a conference RSVP system,

they may actually be more familiar with the "receive and confirm" mental model than the

"receive and send model". Keeping this in mind, we have tried to come up with a more

balanced system that has more of a wedding mental model, but also has similarities with

the confirmation model.

For the most part, the Pass 2 scope is the same as the Pass 1 scope. The system is still

designed as a wedding invitation system that will be used by potential wedding guests.

The functionality of the system remains the same, but the user interface design and the

mental model has been altered to better fit the wedding mental model. We have added a

video at the beginning of the wedding invitation process in order for the process to feel

more special, like when a guest receives a real wedding card. The video allows the

RSVP process to become more customized and special and focuses the attention on

the wedding rather than the RSVP process. The user interface has also been tweaked

to have more of a fancy design, with special text and icons that have more of a wedding

card feel. The goal for this change was to ensure that when users see the system, they

know that it is for weddings. The previous system was relatively ambiguous.

During Pass 2, it is important to find out what potential users of our system think of the

wedding invitation mental model. We should determine if the wedding invitation process

feels special for the user or if it is considered a hassle. This will allow us to focus our

prototype design to be quicker or slower but more customized and special. We should


also have a better way of evaluating our solution, and comparing it to alternative

designs. In Pass 1, our alternative designs were all based on the same design and

mental model, delivered through a different medium. One possible alternative design

could be to use an existing conference RSVP system that was tailored to the specific

questions that need to be answered in a wedding RSVP.

Ultimately, the bride and groom are usually very excited about their wedding. Guests will

share some of this excitement, but it will usually not be as evident. We need our

wedding invitation system to convey the special nature of the wedding and to express

the excitement of the wedding couple without annoying the guests. During our user

evaluations, we should determine how enjoyable our system is, but we should also

confirm that it is what users want.

A2 Additional Analysis and Evaluation

A cognitive walkthrough will be used in this section to analyze the UI we have created

for pass 2. We will use a character, John, who is a busy office manager. He is energetic

and hates being in one place for too long. He has received the wedding invitation and he

is excited to go with his wife, Patricia.

The application begins with a welcoming video from the bride and groom. John will

watch the video and click it when the video prompts him to at the end.


Next John is presented with a wedding invitation with the details of the wedding and the

link to the RSVP page. He has to check his busy schedule to see if he can attend the

wedding and is excited to see he will be free. He does not realize at first that the RSVP

text is actually a button but after scanning the rest of the page, he clicks it.

The RSVP page offers the choices to go back to the previous page, choose not to

attend or to attend. John quickly leaves the radio button for “I will attend” selected and

he catches on that the red text is meant to represent buttons.


John will never get to see this page since he is very excited to go to the wedding.

. John is pleasantly surprised by the variety of options present in the invitation and

decides to see the seating arrangement to check if anyone else he knows has already

gotten their invitation.


John doesn‟t mind sitting anywhere as long as his wife is sitting with him.

John realizes that his wife did not get an invitation and that this is his chance to get her

an invitation but he is wondering whether he will be seated with his wife or not. He may

go back to the seating arrangement after this to check if anything has changed there.


John sticks to fish since his wife has been nagging him to eat healthier but he finds

himself wondering whether his choices will be saved once he leaves this page. Also he

cannot find anywhere to pick his wife‟s meal but realizes it‟s irrelevant since she loves

fish.

John is fairly well-off so he thinks he can afford any of these gifts but decides to make

his choice later after consulting with his wife. After he has finished, he cannot find a “submit” or “finish” button. He quits the

application, slightly confused but excited about the upcoming wedding.


A3 Prototype Illustrations

There are two prototypes we chose to base our experiment on: a single form based

prototype and one that behaves more like a “wizard” and guides the user through the

process step-by-step. The wizard-style prototype is demonstrated above in the walkthrough

and an image of the single form prototype is shown below. This was chosen as a simple

alternative to the more complicated wizard prototype. The user will simply scroll down as

they fill out the form and submit once they are done. The prototypes are visually similar, as

the same background and icons were used. The single form UI includes all of the pages

from the wizard UI in a single scrolling panel.

B1 Evaluation Protocol

We conducted a controlled experiment to gather data about our prototypes, where we did

our best to ensure that it would be as impartial as possible. We did this by designing a

protocol and using it in an experimental setting to gather data. The protocol served as a

script of sorts to guide the direction of the experiment. This allowed us to eliminate some of

the uncertainty with regard to our experiment.

We gathered 10 subjects, from a wide variety of backgrounds. This allows us to be f

confident that our results are statistically significant. Our hypothesis is that the single form


UI will be completed faster than the wizard-style UI within 95% confidence.

The purpose of the experiment is to compare the two UI designs we created for pass two, and compare both designs with the current model, paper invitations. We compare our two designs by the time it takes the subjects to complete a given set of tasks on each UI. Our secondary goal was to compare the perceived enjoyability of using each UI. We also ask the subjects a few prepared questions to find out a little about them since they might be predisposed to liking one UI over another. For example, busier people might prefer to just fill in a single form and submit it. Our variables are numerous. Among the uncontrolled variables are: the subjects‟ mood, computer proficiency and cultural influences. Among the controlled variables are: the UI prototype, the tasks that the subjects will be doing, the computers they will be using and the environment the experiment will be conducted in. After the subjects have completed the task we ask them to rate the UI on simplicity and ease of use. These metrics are used to compare the two different UIs and the types of people who may have a preference for one type of UI.

The goal of the experiment is to see whether subjects will prefer our UI over the standard paper invitation after trying it. A secondary experiment will time the progress of the subjects and see whether the UI they liked was the faster one. This places importance on how intuitive the UI is over how functional it is. For example: if a new user is able to navigate it without significant pauses and without asking any questions, while finishing below the calculated average, then the UI could be considered easy to use. But if the user finds it hard to navigate to where they need to be due to an over-saturation of options, the UI could be considered too cluttered. The goal is to have a UI that the user feels was enjoyable.

C1 Subjects The representative users were chosen to represent a broad cross section of the population who might be receiving a wedding invitation or attending a wedding or similar event. Ages ranged from early 20s to 50+ years old. In order to assess whether or not a user would be likely to use the design, some control questions were asked which identified whether the user was comfortable using online forms rather than mailed letters for day-to-day tasks such as paying bills or accepting invitations. Each user was asked whether they had previously received an invitation to a wedding, as having received a previous invitation could have an impact on that user‟s mental model for receiving and responding to a wedding invitation. Involving the same users for both the Pass 1 and Pass 2 evaluations can have some effects on the results of the Pass 2 evaluation. In the course of the Pass 1 interview, the user could have formed a mental model for how the online RSVP system would work based on the proposed design at that point. This could speed up their completion of the RSVP, as they have a better idea of what to expect than the user who is viewing the concept for the first time. Since online RSVPs for weddings are currently uncommon and should feel


different to regular, everyday event invitations, having a user who does not have a good idea of what is to be expected would be preferable, since that is going to be the case for an average user once the RSVP platform is released. In addition, since the Pass 1 users had a chance to make direct suggestions for interface options and features, if the Pass 2 design incorporates any of those features then the user will know what is expected in a way that a new user would not.

C2 Evaluation Results Provided below are the results of our survey (split up into two images).

User ID (non

identifying)

Q1: Pay Bills (1

electronic, 0

paper)

Q2:

Received

Invitation Q2: Details

Q3: Last

RSVP

Q4:

Details

Q5: Extra

Info? Q5: Details

Q6: Max

time on

invitation

Experiment first

(one page =0,

multiple pg = 1)

Time - all

on 1 page Notes - V0

U1 1 0 online Facebook 0 5 0 1:37:00

Couldn't find

the scroll

button

U2 1 1

personal

text

message online Facebook 0 1 1 0:35:00

U3 1 0 online Facebook 0 2 0 0:37:00

U4 0 1 paper paper Wedding 1

Number of

guests 5 1 0:57:00

U5 1 1 paper

phone

call Meeting 1

Informatio

n for

agenda 5 0 0:48:00

U6 1 0 Online Facebook 0 3 0 0:32:00

U7 1 0 Online Facebook 0 5 1 1:59:00

U8 1 1 Paper Online Facebook 0 5 0 0:46:00

U9 1 1 Paper Online Email 0 3 1 0:44:00

U10 1 1 Paper Online Meeting 0 5 1 20.3

Should try to

make it all fit

on one screen


Hypothesis: More people will prefer the electronic version to the paper version. This

hypothesis is confirmed by performing a CHI^2 test on the “Use this over paper?” row of the

above spreadsheet. See the appendix for the calculation. For our experiment, the total

CHI^2 was = 0.80.

T-Test: For our T-test, the hypothesis is that the single page version is faster to complete

than the multi-page form. The Null Hypothesis is that one is not faster than the other. After

completing the T-test (see Appendix for the test), we conclude that we can reject the null

hypothesis.

C3 Final design rationale During the user evaluations there were a few complaints and comments that were raised fairly consistently. The main strength of the design is in its efficiency and ease of use. None of the users felt that responding to a wedding invitation should take more than five minutes, and filling out either of the the experimental UIs took well under that with the longest time to completion being two and a half minutes. The inclusion of an introductory video and a detailed confirmation process helped to make the invitation seem more special, as befits a wedding, keeping it distinct from the day-to-day invites we receive on Facebook or by email.

Time -

separate

pages Notes - V1

Q1:

Rather

Receive Notes

Q2: Took

More

Time Notes

Q3: More

enjoyable Notes

Q4: More

Personal Notes

Use this

over

paper? Why

0:47:00 1 Video 0 1

Liked the

video 1 Video 1 No mail

1:16:00

Didn't get the back button on

each subform 0 Faster 1 0 Quicker 1 Video 1 Faster

1:37:00

Didn't know they had to press

exit, expected this version to

be like the first. Delayed

reaction with the subform

back buttons. 0

More clear and

sequential 1 0 1

Because of the

video. Would

prefer the video

in option 0 1

1:21:00

Confused over what to click at

first 1

Nice video, see

everything in

one place 1 1 1 Video 1

0:37:00

Found the lack of a "Submit"

confusing. No feedback for

which sections have already

been filled out 0

Confused by

exit/back/submi

t 1

Knew it was

close, felt

option 1

was slower 0 1 Video 1

0:56:00

Could use a summary of

information somewhere 1

More involved,

not as generic 1 1 1

More descriptive,

feels more like a

wedding than any

old event 1 More convenient

0:24:00 1

Seems more

'flashy' 1 1 1 Video 1 More convenient, faster

0:48:00 0 0 0 1 0 Paper's more personal

2:29:00

Got held up on inconsistent

back/submit/exit buttons 0 Faster 1 0 No preference 1

Only if they receive a paper

invite, which sends them to

website to RSVP

1:17:00 0

Can see details

in one place 1 0 0

Having to switch

between sections

takes you out of

the 'invitation

process' 0

Having a hard copy, more

personal. Should at least

include option to print out

something, or receive paper

invite which sends to site


Multi-page UI: One of the major problems with the multi-page UI is the lack of consistency and unclear language for moving between forms and submitting data. Many users commented on the presence of a „submit‟ button on the page for confirming guest numbers, while the seating and meal choice pages had no confirmation step and only had a „back‟ button (which was also present on the guest page). More consistent labeling would help to clear up confusion and make the design easy to use; each page should have both „submit‟ and „back‟ options. The „exit‟ button on the main page was also brought up several times; it is not clear that your changes will be saved if you press it, and it should instead be labelled as „finish and submit‟ or something similar. Since the „exit‟ button is present on the main page, it is also possible for the user to exit without having entered any information, which is undesirable. It might be a good idea to have a more guided walkthrough initially, with the current summary page remaining as the home page for quickly reviewing or editing information. Single-page UI: The single-page UI was generally found to be faster and slightly less confusing than the multi-page. It was mentioned that the form should be sized such that it fits completely on a single page, or at the very least it should be more obvious that the user is meant to scroll down to fill in information. Both: Currently neither UI handles guests very well. Choosing independent meals or seating arrangements for the original invitee and all their guests/children should be possible, but does not fit well with either model. Although both UIs do a good job of being more visually impressive and personal than a standard web invite, a number of users still felt that having a hard paper copy would be preferable. A few solutions to this would be to send out standard wedding invitation cards which contain a web address or QR code to direct the user to the website to RSVP, or to include a printable invitation as part of the RSVP.

C4 Reflection

Over the past 12 weeks, we have learned a considerable amount about Human Computer

Interaction and about the user-centred design process. Initially, it seems easy to go through

the course and learn user-centred design without involving any users, simply by simulating

expected users or trying to take a different mindset and use yourself as an interface tester.

After completing the user evaluations for this project, it is clear that the users have a

considerable impact on how a design proceeds past the prototyping stage. One major lesson learned during the course is that users will surprise you. During the user

testing and design evaluation process, some users ended up liking certain things about the

design that the designers hadn‟t put that much thought in. They also had trouble with certain


elements that a designer might describe as foolproof. One such example occurred when a

user froze during a design evaluation because they were unable to figure out how to scroll

down the page. To the designer that was overseeing the evaluation, it was clear that there

was a scrollbar, but due to the colors of the interface, the tester spent a bit of time before

they eventually found it. Lesson: users surprise you. They like unexpected things and they give you unexpected

feedback sometimes.

The medium/high fidelity prototype created in this project is not exactly an accurate

representation of the planned user interface. While all the main elements are present, we

found that we were constrained by the programming language that we selected. The

language we chose allowed us to create a semi-working version (as opposed to a wizard of

oz version), but it did not allow for more complex interface elements such as animations. In

an ideal world, our prototype tool would have allowed for function and esthetics. In future

projects, it would be more useful for us to be able to create another lower level prototype

instead of going to a medium level. It is natural for the course to require a higher level

prototype but by doing so, we sacrifice useful user interface elements because we are

unable to implement them.

We were evaluating two interfaces at the same time we were evaluating the traditional

paper model vs. the electronic model. As a result, we received feedback on whether users

preferred one model or the other and whether they would be willing to use an electronic

version of the system at all. In a future project, it would be useful to spend more time

looking at the mental model and designing a prototype and spending more time deciding

what specifically we should evaluate. At times, this project was guilty of trying to solve a few

different problems (changing an old way of thinking, using an existing mental model) instead

of focusing on something specific.

After going through EECE 418, the consensus from the group is that we would approach a

new interface design project in a different way than we did before this course, but we

wouldn‟t follow the course steps exactly. While in theory, following the course steps and

doing iterative design should allow us to come up with the best possible design, sometimes

due to time constraints, it can be difficult to make time for several passes of a user interface

or official user testing. In general, it would be useful to informally ask a second opinion of a

colleague, friend, or family member in order to help improve the user interface. This course

has offered us some tools on which types of questions to ask in order to get a proper

hresponse that can be used to improve an interface.


Appendices Provided below are the list of questions asked, and the process we went through for the survey: Before they see the interface

How do you normally pay your bills. Electronically or using paper?

Have you personally received an invitation to a wedding?

The last time you RSVPd to an event, did you do it online or using paper.

Did the RSVP request additional information (other than if you are attending or not attending)

What is the maximum amount of time you would spend completing a wedding invitation RSVP?

We asked why in cases where they responded yes, just to get some more background information or details that could be pertinent to the study. Going Through the Interface The user is shown the interface and told the specific criteria they need to enter (for example, attending, eating chicken, bringing a microwave, and sitting wherever they wish). They use the same criteria for the second interface. After Going Through Both Interfaces

Which would you rather receive?

Which did you feel took more time?

Which was more enjoyable?

Which felt more personal?

Would you use this type of UI over a paper RSVP?

Wedding Planning Website Application: Pass 2€¦ · designed as a wedding invitation system that...

Documents

Transcript of Wedding Planning Website Application: Pass 2€¦ · designed as a wedding invitation system that...