Banweb Guest Access

Jessica Boelcke, Rachel Fernstrum,

Gail North, and Ciara Poe
April 26, 2017
 Table of Contents

Introduction

Methods/Testing
Methods/ Objectives
Personas
Testing
Materials

Results and Discussion

Student Adding Guest
Guest Gaining Access
Student Account Maneuverability
Guest Account Maneuverability
Guest With Valid MTU ID
Student Changing Access Information
Forgotten Passwords

Recommendations
Instructions
Layout
Feedback
Display
Delays in Registration

Appendices
Appendix A - Consent Form
Appendix B - Persona Descriptions
Appendix C - First Draft Instructions
Appendix D - Final Draft Instructions

2
Introduction
The primary goal of this project was to review and find issues with the current Banweb Guest
Access system, and provide recommendations for future improvements. This project was
requested by Michigan Tech’s Enterprise Application Services (EAS), who is responsible for the
maintenance of this system. Over the past several years, there have been many reports of
difficulties registering for and using the Guest Access system, and some minor upgrades have
been completed However, EAS plans to do a major re-write of the system soon, so it was an
appropriate time to perform a general usability test on the existing system and make
recommendations for improvements.

Methods/Testing
Methods/ Objectives
We had our users use the “think aloud” protocol while fulfilling various tasks related to the usage
of the Guest Access.

Our objectives were as follows:

● Test the Guest Access process from both the Student and Guest perspective.
● Identify any areas where the tasks can’t be successfully performed.
● Identify any areas where it is unclear what the users are expected to do or complete, and
where feedback is lacking.
The final testing results were used to recommend improvements for the overall guest access
experience.

Personas (Located in Appendix B)

● Student Persona
● Guest Persona

Testing
Testing was conducted primarily between each member of the group and one or two outside
participants. Most of our participants were family members or friends, with testing conducted in
person. Several were already guests or students who had previously been through the Guest
Access process before. We also performed testing between our group members in order to
document and develop our instruction sets. We developed two separate personas, which were
representative of the two different roles involved: a student and a guest. We provided the testing
participants with an explanation of the process and a scenario of what they were trying to
accomplish. We encouraged the “think aloud” protocol to determine where they encountered
difficulties in completing either the student or the guest form.

Materials

3
 ● Computers (2)
○ One for student to have access to
○ One for the guest to have access to
● Student with access to Banweb
○ Username and password for Banweb (must be an existing student)
● Second person to receive permission for guest access
○ Must have an email address
○ Identifiable relationship to the student

Results and Discussion

Because the testing was being done on an already existing product that had been around for
awhile, we already had a list of problems that needed to be dealt with before our testing. We
based our testing to see how either our instructions could help ease some of the problems or if
the problems were things that needed to be redesigned when considering changes to the product.
Our questions enveloped key parts of the process including how well a student could request
access for a guest, how well a guest could confirm access, and how both parties could maneuver
through Banweb once the accounts had been set up. We also tested on the problems of guests
with pre-existing Michigan Tech IDs, students changing access information, and forgotten
passwords.

Student Adding Guest

There did not appear to be any difficulties associated with the student filling out the form from
their Banweb account. Observations of the participants indicated that this part of the process was
usually successful. Students were able to navigate to the form and fill it out. After completing the
form, the students were notified that an email was generated to their guest to complete the guest
portion of the process. This provided feedback that the student request process had been
completed successfully.

Guest Gaining Access

Most of our test participants had difficulties finishing this task to completion, especially without
our final instruction set. The form itself doesn’t provide clear guidance on which fields are
required, or what is expected in each field. Participants frequently paused and questioned
whether fields were required or what was expected in certain fields, particularly the pass phrase.
Guidance for the password was below the password fields, and wasn’t immediately obvious to
several users.

In many cases, the guest was ultimately successful in filling out the form. The form then notified
them that they would be contacted by email when their registration was complete. However,
sometimes they never received the email, or they received it a day or more later. In a few cases,

4
the guest completed the form and were immediately told that the registration was successful and
they could then log in via the link provided. In other words, even though the participants
perceived that they had completed the task successfully, the outcomes did not appear to be
consistent.

Student Account Maneuverability

Once the guest account has been successfully created, the student can go to the Guest Access tab
and click on "View Authorization History" to see the current status of their guest(s)’ access.
They can also see the history of any changes.
If the student has more than one guest, they can select a guest from a drop-down list of all guests.
Information is displayed for only one guest at a time on both the "Authorization History" and
"Change/View" screens. Selecting a different guest from the drop-down list changes the
information to that of the selected guest.

Guest Account Maneuverability

It varies, depending on whether or not the guest already had another Banner access, and whether
they are a guest on more than one account. For example, if they are also a student or employee,
they will also see those Banner tabs. If they are a guest to more than one student, they will see all
the student names available in a drop-down list. When they click on the Guest Access tab and
select Student Information, they will be able to select a student, one at a time. The screen will
then display links to any pages that the student has authorized the guest to see.
One significant error was noted if a guest already had a Banner account (eg former/current
student or employee): after viewing their student’s information and returning to the main page,
the status bar at the top of the screen displayed the student’s name instead of the guests. All of
the remaining information was correct, and the guest had no access to anything of the students
that they shouldn’t have. However, the display name did not automatically refresh with the
guest’s name.

Guest With Valid MTU ID

The big difference in immediate success versus delayed (or non-existent) success appeared to be
whether or not the guest was already in Banner. We discovered that if the guest already had a
login and entered that on their form, the login was immediately linked to the student’s account
and the guest could log in. If the guest already had a login and didn’t enter that on their form, a
delay could result. We discovered that if the guest has information matching someone already in
Banner, the guest account is bounced to the Registrar’s Office for review. Therefore, there may
be a delay in the response time for getting the account set up. This likely explains the high
number of failures/delays in our test set, because many of our participants were already guests,
students or alumni, and would therefore get bounced if they didn’t enter their existing login.

Student Changing Access Information

5
Yes. If the student goes to Change/View Current Guest Access, they can select or deselect items
from the access list. These changes are reflected the next time that the guest logs in.

Forgotten Passwords
Several test participants reported problems with recalling a login and password, especially if it
had been assigned some time ago. One participant immediately forgot the password he had just
created, after struggling with different things to meet the strong password rules.
The Banweb login dialog box does display a link to reset an account password. However, it
blends in with other information and doesn’t stand out. Also, it requires that you have either a
birthdate on file or a mobile phone number. The guest access form doesn’t require either a
birthdate or a mobile number, so it’s easily possible that a user would have no way of
automatically resetting a password.

Recommendations
The purpose of our instructions and testing on the guest access in Banweb was to help the
owners of the site to better prepare the process for future students to give access out to guests.
They plan on considering our recommendations for when they plan to make the next revision to
the site. Our recommendations were split down into sections such as quality of instructions
needed, layout of the pages in the form, amount of feedback that the users need for accurate
results, display problems, and registration delays.
Instructions

Every time we revised the instruction set, we got better results. There’s a trade-off in having
lengthy instructions, however the user may get lost trying to follow through all the detail.
Therefore, it may be a good compromise to have detailed instructions available in a Help section
for those who may need it. At the same time, include more concise, online instructions on the
form itself, or possibly a mouse-hover format.

There also needs to be explanation for what is needed for the password phrase, and indication on
the exact requirements (the 15-character restriction indicated on the form isn’t true).

Finally for guests with pre existing logins, there needs to be an obvious indication that they need
to enter the login in order to set up the account quickly and accurately. The existing guidance is
vague: “enter either your login or email address”. We discovered that this was a crucial part of
the form for users with existing accounts.
Layout

Required fields need to be made obvious. To be consistent with many other web forms, signify a
required field with an asterisk (*) prior to the field. If a field is required for a password reset (e.g.
mobile phone, birth date) it needs to be indicated.

6
The guest relationship default being Brother is odd and should be changed because it isn’t a
likely relationship for most guests.

The address fields are also clunky, with no identifiers. Identify items like “street address” or “apt
number” if that’s what is expected, instead of simply providing a series of blank lines.

Feedback

In some cases, the guest and student have no idea what has happened to a request once it has
been sent. It falls into what we referred to as a “black hole” during testing. Upon completing the
form, the guest receives a message that they will later on be sent an email once the process is
complete, but the email never arrives or can arrive a day or more later. This should be fixed so
that both parties are aware of what is going on with the request. Because of this there should
ideally be a progress bar on the student page to indicate the current stage of the process (e.g.
request acknowledged, email sent to guest, form completed by guest, flagged for review, etc.).

Display

The guest page doesn’t always show the guest’s name on the top banner because sometimes it is
showing the student’s name. This should be changed so it always shows the guest’s name.

Delays in Registration

It would be easier if requests that needed to be reviewed were flagged for the users so that they
would know when and why their request hasn’t been processed. Currently it goes into the “black
hole” and neither group hears about it again. There should also be easier ways for users to find
out if they have an existing login or if they have forgotten their passwords.

7
Appendix A - Consent Form

CONSENT TO PARTICIPATE IN RESEARCH

HU 4628 Software Usability Studies

Circle one

Banweb Alumni Tab Banweb Guest Access Husky Bucket List SnowDay

INTRODUCTION
Thank you for your interest in participating in the indicated Usability Study conducted by students from
HU 4628, Usability and Instructions Writing.

PURPOSE OF THE STUDY

The purpose of this study is to investigate the usability of elements of a larger software package, a
specific app, or a computer program.

PROCEDURES
1. Read and sign an informed consent form (included in the study package)
2. Read or listen to introductory information and instructions delivered by the study team
3. Follow instructions to accomplish tasks appropriate to the evaluation of the product.
4. “Think aloud”; that is, verbalize your thought processes to alert observers to problem areas in the
task, the software, or the interface. If you stop verbalizing, the observer will prompt you with
questions such as “What are you thinking now?” or “Why did you click that button?” or “Are you
looking for something specific”?
5. When all tasks have been completed, the observer will ask you to discuss the overall experience,
offer suggestions, and add details as appropriate. Final questions may vary from group to group,
but the goal is to understand the user’s experience.

RISKS OR DISCOMFORTS
We expect that any risks, discomforts, or inconveniences will be minor and we believe that they are not
likely to happen. If discomforts become a problem, you may discontinue your participation.

In the unlikely event of physical and/or mental injury resulting from participation in this research project,
Michigan Technological University does not provide any medical, hospitalization or other insurance for
participants in this research study, nor will Michigan Technological University provide any medical
treatment or compensation for any injury sustained as a result of participation in this research study,
except as required by law.

8
POTENTIAL BENEFITS TO PARTICIPANTS AND/OR TO SOCIETY
No individual participant will benefit from the research, although benefits to future users of the software
can be expected due to potential improvements to the software. .

COMPENSATION FOR PARTICIPATION

You will not receive any payment or other compensation for participation in this study. There is also no
cost to you for participation.

CONFIDENTIALITY
Any information that is obtained in connection with this study and that can be identified with you will
remain confidential and will be disclosed only with your permission or as required by law.
Confidentiality will be maintained by means of the use of participant codes or pseudonyms. The document
that shows the link between study codes and identifying information will be destroyed when the study is
finished.

Your identifying information will not be released to anyone outside the study. The information used for
publication, however, will not lead to your identification.

Electronic data files, including digital recordings and photographs, will be stored on a password-
protected computer owned by the University. The files will be destroyed three years after the study
completed.

PARTICIPATION AND WITHDRAWAL

You can choose whether or not to participate in this study. If you do participate, you may stop
participating at any time. There is no penalty or other consequence if you withdraw from the study and
you will not lose any benefits to which you are otherwise entitled.

IDENTIFICATION OF INVESTIGATORS
If you have any questions or concerns about this research, please contact:

Dr. Karla Kitalong, Professor See next page for co-investigators’ names and emails.
Department of Humanities
Michigan Technological University
Houghton, MI 49931
906-487-3254
kitalong@mtu.edu

Coinvestigators are listed on the attached page.

RIGHTS OF RESEARCH SUBJECTS

The Michigan Tech Institutional Review Board has reviewed my request to conduct this project. If you
have any concerns about your rights in this study, please contact the Institutional Review Board,
Michigan Tech-IRB at 906-487-2902 or email IRB@mtu.edu.

9
____YES, I agree to participate in this study.

I authorize you to audio record or photograph my participation in this study. YES NO

I understand the procedures described above. My questions have been answered to my satisfaction, and I
confirm that I am age 18 years or older and I agree to participate in this study. I have been given a copy
of this form.

________________________________________
Printed Name of Participant

________________________________________ _________________________
Signature of Participant Date

Please provide demographic information

Age Gender CIRCLE: MTU undergrad MTU grad MTU faculty MTU
staff other adult

List of project co-investigators (students enrolled in HU 4628, Spring 2017

● Jessica Boelcke jaboelck@mtu.edu
● Gail North gjnorth@mtu.edu
● Ciara Poe cepoe@mtu.edu
● Rachel Fernstrum rkfernst@mtu.edu

10
Appendix B - Persona Descriptions
Student Persona

Tina is going to be a first-year student at Michigan Tech in the fall. As part of her orientation
packet, she was told to go to her Banweb account and create a guest account for her parents
before starting the school year. She also needs to set up a guest account for her grandmother. Her
grandmother has told her that she’ll pay part of Tina’s tuition each semester, as long as she keeps
her grade point average above 3.0.

Tina is an excellent student. She grew up with technology and is familiar with registering on
various websites, so she doesn’t anticipate any problems. However, she’s not the most confident
person in the world. If something doesn’t work right, technology-wise, she blames herself,
thinking she must have “hit the wrong key or something.” She’s the type who will try something
over several times before asking for help. So, when her grandmother tells her that the guest
account doesn’t seem to work, Tina decides to try setting it up another time.
Guest Persona

Helen is Tina’s grandmother. She loves Tina and is proud of the way that she’s excelled in high
school. She has enough money that she wants to help Tina with her college costs, because she
puts a high value on higher education and learning. Helen is well educated herself, and even
though she just turned 80, she’s embraced the home computer that her son bought for her several
years ago. It allows her to exchange emails and photos with her three grandchildren and her two
daughters that live far away. She does some online shopping as well.

Unlike Tina, Helen will blame the computer for anything that goes wrong. If she can’t print
something, it’s because “the printer doesn’t work!” She apparently shares some of Don
Norman’s philosophies. She always believes that she does exactly what the computer tells her to
do, and that if something goes wrong, it’s because the computer was being stupid. She has very
little patience for experimenting and poking around on a web page—she wants (and needs)
things to work in a very obvious manner.

11
Appendix C - First Draft Instructions
Student Instructions
1. Go to Banweb at https://www.banweb.mtu.edu
2. Use your Michigan Tech username ID (should be your first letter of your first name, first
letter of middle name, and first six letters of your last name) and Password (which should
have been given to you by the school and allowed you to change it to a password you
want)
3. There is a home bar with several buttons (Personal Information, Students, Financial Aid,
etc). Choose the button that says Guest Access.
4. Select Request Guest Access.
5. Answer whether the new guest has ever had access to your account (Yes or No).
6. Enter the Guest Information
a. First Name, Middle Initial, Last Name
b. Use the choice bar to select the relationship they have with you.
7. Check the box for the correct type of access you want to give the new guest.
8. Choose a security phrase for your guest to know in order to acquire access to your
account.
9. Indicate whether your guest has internet access (Yes or No).
10. Enter the email for your guest (make sure it the valid email that they will be checking in
order to make sure that your request won’t go unanswered).
11. Let your guest know that it is their turn to fill out the online form.

Guest Instructions

This is a copy of the email that the guest receives after the student makes the request:

1. After receiving the email, the guest should click on the link in the email and follow the
online instructions to complete the process.
2. Fill in name, phone and address
3. Click Continue

12
4. From the drop-down list, select an id that you will use to log in. (Note: if you have
already gone through this process before and/or already have an MTU ID, it will not
show in this list. The list only shows those id’s that are not in use).
5. Create a password, following the password rules listed. Re-enter the password and hit
Submit to finish the process.
6. You may now use the id and password to log in at www.banweb.mtu.edu.

13
14
Appendix D - Final Draft Instructions
Student Instructions
1. Go to Banweb
2. Sign into your Michigan Technological University Banweb account.
a. Enter your Michigan Technological University Username ID (should be your first
letter of your first name, first letter of your middle name, and first six letters of
your last name)
i. Example: jaboelck
b. Enter your Banweb password
i. Note: this should have been given to you by the school and allowed you to
change it to a password of your choice).
3. There is a home bar with several buttons (Personal Information, Students, Financial Aid,
etc.). Select Guest Access.
4. Select Request Guest Access.
5. Answer whether the new guest has ever had access to your account (Yes or No).
6. Enter your Guest Information
a. First Name, Middle Initial, Last Name
b. Use the choice bar to select the relationship they have with you (example:
Mother)
7. Check the box for the correct type of access you want to give the new guest
a. Accounting - Electronic Bill Notification
b. Accounting - Enrollment Deposit
c. Accounting - Tax Notification (1098-T)
d. Accounting - Tuition Bill and Associated Holds/Pay Bill via the web
e. Financial Aid - Cost of Attendance, Award by Aid Year, and Requirements
f. General - Student’s emergency contacts as recorded in the student’s record
g. Schedule by Day/Time and Course Detail
h. Unofficial Academic Transcript, Midterm Grades (for first year students only),
Term End Grades
8. Choose a security phrase for your guest to know in order to acquire access to your
account.
a. Note: There is no minimum/maximum amount of characters needed
9. Indicate whether your guest has internet access (Yes or No).
10. Enter the email for your guest
a. Make sure it is the valid email address they will be checking in order to make sure
that your request won’t go unanswered
11. Let your guest know that it is their turn to fill out the online form
a. Warning: if the name or address of your guest has already been used for previous
guest access it may be held up in the offices before being processed so they can
determine that it’s not a duplicate

15
Guest Instructions
1. Check your email account that the student has filled out in their portion of the form.
a. The email will look like this

2. Click on the link provided in the email to continue to the form.

3. Fill out the form
a. Note: your first and last name along with your email will be prefilled from the
student granting you access
b. Phone number (mobile) and Birthday
i. Include this in case you forget your password it is used to confirm your
identity
c. Check box to indicate any existing status with the school
i. Alumni
ii. University employee
iii. parent/guardian
iv. Enter MTU user ID if you you have one
d. Address (Required)
4. Select Continue
5. If you didn’t enter a MTU user ID choose a new ID from the list
6. Enter Password
a. Write the password down so that you have access to the account if forgotten
b. Password must be
i. At least 6 characters long
ii. Non-trivial
iii. Contain at least one alphanumeric character
iv. Contain at least one non-alphanumeric character
v. Without spaces, tabs, or “whitespace”
7. Select Submit
8. There will be two possible messages
a. Immediate Confirmation

16
 b. Registration Review

Guest Instructions Navigating Banweb

1. If you didn’t get immediate confirmation after filling out the form check your email
account that the student identified for you in their portion of the form.
a. The confirmation email will look like this

17
2. Sign into your Banweb guest account
a. Chosen User ID
b. Chosen Password
3. There is a home bar that might have several buttons (Personal Information, Students,
Financial Aid, etc.). Select Guest Access.
4. Select Student Information.
5. Select which student to access from the drop down menu.
6. Select which section to access (ex: Schedule)

18