Project Overview
Requirements
Conduct a heuristic evaluation of a local agency's website, then plan, coordinate, and report on a usability test session.Timeline
Skills Used
Completed For
HOURCAR (Community Engaged Learning)Project Type
Freeform Skill ApplicationAbout This Project
Group Collaborative Project
Our team had three members. For their privacy, their names are redacted here.This page pares down our 97 report pages and a presentation to HOURCAR.
Community Engaged Learning
This project is a part of the University of Minnesota's Community Engaged Learning initiative, so our class collaborated with local organizations as student volunteers.
What is HOURCAR?
Our team was assigned to work with HOURCAR, the Twin Cities' local nonprofit carshare service. They offer two services, the namesake HOURCAR and Evie. At the time, theses were separate websites.
HOURCAR is round-trip, so trips start and end at the same location.
Evie is one-way, so trips can start and end anywhere in the inner metro, similar to Lime scooters.
At the time, these services had separate homepages and a single support "wiki".
HOURCAR’s Goals
HOURCAR laid out three main areas they encouraged us to explore:
First Impressions
Can new users define, differentiate, and choose a service based on their needs?
Support Wiki
Is the new Wiki helpful and accessible? How might we improve the search function?
Existing Members
How might we make the website more appealing and useful for existing members?
Heuristic Evaluation
Heuristic evaluations don’t catch everything, but they can help predict issues real users may encounter. To guide our usability test, we evaluated HOURCAR’s websites based on Nielsen’s UI Heuristics:
👀 Visibility of System Status
What a system is doing should be conveyed to its users. If you press a button, you should know it worked.
🎛️ Match Between System and Real World
Systems should speak their user's language, not technical jargon. This could include using visual metaphors and control mapping.
💨 User Control and Freedom
Users need to be able to easily leave a page or undesirable state.
🐣 Consistency and Standards
A product should be consistent with its users's expectations. It should consider expectations set by both other products and itself.
🚧 Error Prevention
Use constraints, hints, and suggestions to prevent users from making an error in the first place.
🚏 Recognition Over Recall
When users need to remember something, use cues and suggestions to help them recognize it instead.
⏩ Flexibility and Efficiency of Use
Systems should be adaptable to both new and familiar users; as people learn the system, it should offer ways to make repetitive tasks faster.
🎨 Aesthetics and Minimalist Design
Interfaces should contain elements that help users perform a task, but not ones that don't.
⚠️ Help Users Recognize, Diagnose, and Recover from Errors
If an error occurs, it should be clear that it occured, how it happened, and how to fix it.
📖 Help & Documentation
While an ideal interface can be used without help, this is often unrealistic. Systems should provide help that's relevant, scannable, and ignorable.
Comments On Evie Homepage
We were primarily asked to evaluate the Evie homepage, but our comments here often extended to the HOURCAR homepage as well.
Comments On Support Wiki
Usability Test Structure
We used the results of our heuristic evaluation and HOURCAR’s research goals to structure our usability test. We recruited five participants, who joined virtually.
Scenarios and Tasks
To test how our participants used the website, we came up with four realistic scenarios with tasks to perform.
Scenario 1
This scenario asked participants to research HOURCAR services, find the best membership plan for a given demographic, and figure out how to register.
Scenario 2
This scenario acted as a knowledge check; it asked participants to choose the best service to use for a given scenario.
Scenario 3
This scenario asked participants how to pay for third-party EV charging. This tested how they searched the wiki for specific, less prominent information.
Scenario 4
This scenario pushed participants to quickly search for insurance information, as if they were in a crash. This information is easier to find, so we pressured them to act quickly.
More Test Information
Participant Demographics
Before the evalutation, we asked participants to describe their transportation habits. None of them had used a carshare service before, and all but one commuted under 3 times a week.
Post-Task Ratings
Each task was followed up with a 5-star rating on the experience and a quick interview.
Product Reaction Cards
Each participant selected five product reaction cards during our debriefing interview to describe their experience.
Usability Test Results
Recommendations given to HOURCAR
- Organize site content more intentionally and implement clearer and more deliberate phrasing. Our participants had never used HOURCAR services before, and their understanding was based on a short description on the support Wiki’s homepage. Basic understanding of HOURCAR’s core services shouldn’t be based on a help article. We specifically recommended using a pair of identifying phrases like “round-trip” and “one-way” to identify the services and using that across every website.
- Make a graphic comparison table to clearly differentiate services on the homepage. The lack of comparison between Evie, HOURCAR, and other competing services like Lime threw off our participants. We recommended prominently featuring this comparison on each homepage (not just the Wiki).
- Be upfront and consistent about where links lead. Several times, our participants were thrown off track because a link unexpectedly scrolled the page or brought them to an external site. We recommended visually differentiating links based on where they led and making sure they describe their destination well.
- Create a categorical index of the Wiki. Our participants relied heavily on the Wiki’s sidebar and navigation bar, not search. This isn’t super surprising, as unfamiliar users tend to prefer visually scanning for the information they need instead of guessing which keywords to search. Like an index of a book, we recommended having similar articles listed together for easier recognition.
- Make the search function more useful, prominent, and accessible. None of our participants used the wiki’s search box, meaning they didn’t identify it as a resource. Search acts as an “escape hatch when users are stuck in navigation” (Nielsen) and is therefore an important for support sites like the Wiki. Our heuristic evaluation showed that the search bar isn’t very useful, while our usability test showed it may not be identifiable to users. We recommended featuring a prominent search function on every page, allowing natural language searches, and tagging content better. We also recommended focusing on other areas first because search is difficult to implement well and often used as a crutch.
Example Mockup
To demonstrate what our recommendations could look like in practice, I made a simple mockup in Figma to share with HOURCAR.
