Executive Summary
This report evaluates the usability of Miami University’s myMiami portal and the accompanying instructions for registering for classes. The original test involved three participants from different age groups who attempted ten tasks within a total of twenty-five minutes. Two participants completed every task, although some tasks exceeded the assigned time, and the oldest participant completed six within time and two afterward. Participants praised the instructions but reported small text, insufficient contrast, poor responsiveness, and a session that appeared to remain active after the browser was closed.
The study provides useful formative observations, but its sample is too small to support percentages as estimates of the wider student population. The original report also combines the portal, BannerWeb, the instruction manual, internet performance, and participant experience into one score. This revised report treats the findings as exploratory, explains methodological limitations, and recommends a repeatable usability and accessibility program. Miami University replaced the older myMiami interface with a OneCampus-based portal in 2022 partly to address accessibility and security concerns, so the historical observations should be used as design lessons rather than a current audit of every page.
Purpose and Scope
The primary purpose was to determine whether a first-time user could follow instructions and complete class-registration tasks through myMiami and linked systems. The evaluation considered effectiveness, efficiency, learnability, accessibility, error recovery, and satisfaction.
The scope should be defined carefully. myMiami is a portal that directs users to campus information and systems. Registration may involve another application. A failure could arise from portal navigation, instructions, authentication, Banner functionality, network delay, or lack of domain knowledge. Each source should be recorded separately.
Research Questions
The evaluation can be organized around five questions:
- Can first-time users locate and begin the registration workflow?
- Can they complete critical tasks accurately without assistance?
- How much time, hesitation, backtracking, and error occur?
- Can users with different abilities and devices perceive and operate the interface?
- What changes to the portal or instructions would reduce failure and risk?
These questions are more useful than asking whether the site is simply “good” or “bad.”
Participants
The original study used three people with different ages and levels of technical experience. Purposeful variation is useful for discovering diverse problems, but age should not be treated as a substitute for digital skill, disability, or student status. One participant’s vision concern produced an important accessibility observation, but the test did not include systematic assistive-technology use.
Future rounds should recruit current and prospective students, transfer students, graduate students, international students, people using mobile devices, and participants who use screen magnification, keyboard navigation, or screen readers. A formative test can begin with a small group, but repeated rounds are preferable to one large test because designers can fix problems and test again.
Task Design
Tasks should reflect realistic goals without revealing the exact navigation path. Instead of saying “click BannerWeb and choose Registration,” a scenario might ask: “You need to add an available course to your fall schedule. Show how you would begin.” This tests whether labels and information architecture make sense.
Critical tasks may include locating registration, checking a hold, searching for a course, viewing prerequisites, adding or dropping a section, identifying a registration error, finding help, and signing out. Destructive actions should be performed in a test environment or stopped before final submission.
Time Limits
Time-on-task can reveal friction, but a rigid time limit can distort behavior. A user may rush, skip verification, or appear to fail because of network delay. The original test allowed exceptions for connection problems, which was sensible, but the criteria were not standardized.
Future testing should record task start and end times, system waiting time, and active interaction time separately. A benchmark can be established after observing successful users rather than assumed in advance. Critical accuracy matters more than speed for enrollment decisions.
Data Collection
Screenshots confirm destination pages but do not explain the user’s reasoning. Moderated testing should include observation, think-aloud comments, clicks, errors, requests for help, and post-task ratings. Screen recording may be useful with consent, secure storage, and removal of credentials or student information.
Participants should not use real passwords provided by researchers. Test accounts or a safe prototype are preferable. Authentication and session testing require security controls so that usability research does not expose institutional systems.
Original Findings
One participant completed every task within the assigned time. Another completed all tasks but exceeded time on three. The oldest participant completed six within time and two afterward. These results suggest that the workflow was possible but not equally efficient.
The reported “60%, 100%, and 70%” figures should not be averaged or presented as population success rates. With ten tasks, each task changes an individual percentage by ten points, and the tasks may differ greatly in difficulty. A clearer table would report success, partial success, failure, time, error, and assistance for each task and participant.
Instruction Manual
All participants considered the instructions helpful. This suggests that step-by-step support compensated for limitations in the interface. However, instructions can become outdated when labels or screens change. They should be versioned, dated, tested, and linked from the relevant point in the workflow.
Instructions should use concise steps, meaningful screenshots, alternative text, keyboard-accessible formats, and troubleshooting for common errors. They should explain concepts such as registration holds and prerequisites rather than only listing clicks.
Responsive Design
One participant reported losing part of the page when the browser window was narrowed and needing horizontal scrolling. This is a serious usability and accessibility issue. Content should reflow without loss of information or functionality at supported viewport sizes and zoom levels.
Testing should include desktop, tablet, and mobile layouts, browser zoom, text enlargement, landscape orientation, and long labels. Responsive design should preserve task priority; moving a critical action into an unexpected menu can solve layout while harming discoverability.
Text, Contrast, and Low Vision
The complaint about small fonts and inadequate contrast should not be dismissed as an individual limitation. WCAG 2.2 provides testable accessibility criteria for contrast, resizing, reflow, focus, target size, and other needs. Conformance improves access for people with disabilities and often improves usability for everyone.
Designers should test text and interface-component contrast, support 200% text resizing and higher page zoom where required, avoid images of text, and ensure focus indicators remain visible. User testing with people who have low vision complements automated checks.
Keyboard and Screen-Reader Access
The original study did not evaluate non-mouse operation. Every interactive element should be reachable in a logical order by keyboard, have a visible focus state, and expose an accessible name, role, and state. Error messages and dynamic updates should be announced appropriately.
Headings, landmarks, form labels, table headers, and skip links help navigation. Testing should include common screen readers and browsers, but accessibility should be designed into components rather than postponed to the end.
Authentication
WCAG 2.2 includes accessible-authentication requirements intended to reduce unnecessary cognitive tests and barriers. University authentication may include multifactor steps, recovery, and identity verification. These controls should be secure and usable.
Users need clear error messages, alternatives where appropriate, sufficient time, and accessible support. Security cannot be weakened, but avoidable memory and transcription burdens should be reduced.
Session Termination
A participant reported remaining logged in after closing the browser. This observation requires technical verification. Modern single sign-on may maintain a session by design, and closing a window is not always equivalent to signing out. The interface should make that distinction clear.
High-risk systems need an obvious sign-out action, appropriate inactivity timeout, warnings before timeout, and revocation behavior matched to risk. Testing should determine whether reopening the browser restores access, whether other linked systems remain active, and whether shared computers are protected. Claims of a “session destruction failure” should not be made without reproducing the behavior.
Navigation and Information Architecture
Users should be able to find registration through labels they naturally understand. Search, favorites, task categories, and recently used items can help. Miami’s newer portal includes search and favorites, reflecting the need for multiple pathways.
Analytics can identify failed searches, but search logs should be handled responsibly. Common unsuccessful terms can guide synonyms and content improvements. Navigation tests such as card sorting and tree testing can evaluate structure before interface development.
Error Prevention and Recovery
Registration is consequential. The system should prevent accidental drops, explain prerequisites and holds, confirm selected term and section, and preserve entered work after recoverable errors. Messages should state what happened, why, and what the user can do.
Error codes written for administrators are not sufficient. Links to support should carry useful context without exposing private data. Users should be able to verify their final schedule and receive a clear confirmation.
Accessibility Governance
Miami University’s AccessMU program links accessibility with procurement, testing, training, and institutional policy. Portal quality depends on both the university and third-party products. Contracts should require accessibility documentation, remediation, and continuing conformance after updates.
An accessibility statement should identify standards, known limitations, and a responsive channel for reporting barriers. Alternative access must be provided promptly while a defect is corrected.
Severity Ratings
Problems should be prioritized by frequency, impact, persistence, and risk. In the original test, poor reflow and low contrast deserve high priority because they can block access. Session behavior may be high risk but needs confirmation. Minor wording preferences may be lower priority unless they affect a critical decision.
A severity scale should include evidence and recommended ownership. Accessibility violations should not be postponed merely because only one participant encountered them.
Revised Test Plan
A stronger study would use at least two iterative rounds. Round one would include five to eight participants representing key user groups. The team would test six to eight critical tasks, record outcome and behavior, and correct major problems. Round two would verify the changes with new participants, including assistive-technology users.
The study should document device, browser, prior experience, task wording, moderator assistance, interruptions, and system performance. Quantitative results should be reported with raw counts because small samples do not justify precise population percentages.
Recommended Metrics
Useful metrics include task success, critical error rate, time on task, help requests, number of backtracks, post-task ease, and accessibility defects. Satisfaction can be measured with a validated instrument such as the System Usability Scale, but one score should not replace task-level findings.
Operational monitoring can include search success, support contacts, abandonment, and registration errors. Metrics should exclude unnecessary personal data and be interpreted with qualitative feedback.
Recommendations
- Verify responsive reflow and remove horizontal scrolling for ordinary content.
- Test WCAG 2.2 Level AA criteria and remediate contrast, focus, labels, target size, and authentication barriers.
- Clarify sign-out and single-sign-on session behavior.
- Rewrite and version the registration instructions using accessible formats.
- Test critical workflows with prospective students, current students, and assistive-technology users.
- Separate portal, linked-system, network, and instruction problems in reporting.
- Repeat usability testing after changes and publish a corrective-action summary.
Conclusion
The original three-person test identified meaningful problems and showed that the instruction manual helped users complete registration tasks. Its findings should be treated as formative evidence, not as proof that 60%, 70%, or 100% of a population will succeed. The strongest observations concern poor reflow, small text or contrast, and unclear session behavior.
A modern evaluation should combine realistic task testing, WCAG 2.2 accessibility review, security-aware session testing, and iterative design. The goal is not merely to make a portal efficient for an experienced user. It is to ensure that students with different devices, abilities, backgrounds, and levels of institutional knowledge can complete high-stakes tasks accurately and confidently.
References
World Wide Web Consortium. (2024). Web Content Accessibility Guidelines 2.2.
Miami University. (2022). FAQ: myMiami Replacement.
Miami University AccessMU Center. Policy and Procurement.
ISO. (2018). ISO 9241-11: Ergonomics of Human-System Interaction—Usability.
Brooke, J. (1996). SUS: A quick and dirty usability scale.
Cite This Work
To export a reference to this article please select a referencing stye below:
Academic Master Education Team is a group of academic editors and subject specialists responsible for producing structured, research-backed essays across multiple disciplines. Each article is developed following Academic Master’s Editorial Policy and supported by credible academic references. The team ensures clarity, citation accuracy, and adherence to ethical academic writing standards
Content reviewed under Academic Master Editorial Policy.
