Interactive prototype, usability evaluation & blog update

We are not using Figma as our primary focus because this is not an application but rather a physical prototype. From the beginning, we knew we wanted to do some modules for parking scooters, which is the idea we stuck with. At first, we thought about lockers but concluded that it would be more efficient with stands instead. It’s essential to think about the overall user experience when designing the ScootSeal module. This includes factors such as the product’s usability, functionality, and aesthetics. For example, the module should be easy to use and navigate, with clear instructions and a logical flow. It should also be functional, meaning that it should effectively serve its intended purpose of providing a secure and convenient place for users to park their scooters. Finally, aesthetically, the module should be pleasing to the eye and consistent with the brand’s visual identity. We had to break our project down to achieve these goals and start sketching and conceptualizing.

At first, we did some sketches, trying to visualize the design of the module and what the user experience would look like. Then, we made our personas from the form we made at the beginning of the project, user stories, and “crazy eight” sketches. We have since then programmed a small monitor with an NFC reader to demonstrate how a user would typically choose and pay for parking.

While designing ScootSeal, we considered theories taught during lectures. For example, Norman’s six design principles, as discussed in the other assignment. The visibility principle is evident when making our minimalist design for the ScootSeal display, where the user is presented with few options on what to do, which also connects to the constraints principle. It’s also important to consider other principles, such as the affordance principle, which states that the design should indicate how it can be used. We also implemented the green lamp light. This is especially relevant for a physical product like the ScootSeal module, as users need to easily understand how to interact with it, whereas the light gives feedback to the user when a parking spot is available. We also considered the mapping principle with the easy three-step instructions provided before parking the electric scooter. Finally, the principle of consistency is evident through the internationally recognized symbol for card payments.

Other than considering the design theories, we wanted to design the product with the users in mind. Therefore, we conducted a few studies and also observed electric scooter users. As a result, we realized that ScootSeal would be most attractive for private electric scooters rather than rental ones. With this fact in mind, we then discussed where such a module would be placed in a city and what it should look like to fit those specific locations.

We also made this video that will be presented future during the upcoming presentation on our project, but if you want to take a small peak at the video before, this is the one we will be using.

However, since there were multiple discussions regarding Figma, we made a small demo of a potential application that we could demo. 

Usability evaluation

Heuristic evaluation

In the Heuristic evaluation, we got to choose between five of Nielsen’s Heuristics or to use Sneiderman’s golden rules, and we decided to use the golden rules. Our thoughts will be summarised under each title with a short text explaining our thoughts and an average evaluation value. All the following rules are graded on a scale of 1-5, and 1 indicating “Terrible” and five indicating “Amazing”.

Consistency

“Our product has a limited interaction surface, which contributes to its consistency. The UI reuses layouts across different screens, and a significant portion of the terminal remains constant, displaying permanent instructions and the card reader. We are also using a simple interface with few colours to avoid confusing the user, as the only necessary action is scanning the card. The symbol for card payment and the three-step instructions also add to the consistency of the interface.”

Score: 4

Usability

“Instructions and use of the lock are generally simple, but some users may have difficulty understanding them. Paying by card and using the card as a ‘key’ may be a new concept for some, and the app requires careful reading to avoid disrupting the process. ScootSeal is primarily designed for a specific group of people, and older users may need help understanding it compared to younger users. However, the product is adapted to all ages that are allowed to use electric scooters, which is the target group for the product.”

Score: 3,33

Feedback

“We offer clear feedback through various means to ensure the user understands the product and knows what to do. The most important feedback is provided when the user first scans their card, and the lock opens, with both on-screen and physical (green light) indicators. The parking module also offers visual (green lamp) and auditory feedback (sounds) for locking or unlocking. In addition, lamps light up to guide the user to the correct stall, and on-screen feedback is provided once the card has been scanned.”

Score: 4,33

Prevent errors

“There are few possibilities for the user to make mistakes while using the parking module, as the interaction is designed to have a minimal number of steps. The only way to trigger an error when paying by card is by not inserting the scooter when the spot opens up. However, human error is still possible if the user accidentally locks someone else’s scooter or something else that should not be locked with our product.”

Average: 4

Permit easy reversal of actions

“One major issue with reversing decisions when using ScootSeal is that the system expects the scooter to be inserted into the lock once the user unlocks a spot. Therefore, it is difficult to cancel the operation if the user decides they do not want to park. Overall, the user can make a few mistakes in the first place, but these actions are easy to reverse, as there are only two steps (using the same card) – blipping to lock and blipping to unlock.”

Score: 2,66

Keep users in control.

“There is little information offered by the parking module and limited opportunities for change, but experienced users may be able to park quicker than inexperienced ones. As the entire flow is simple, the user controls how the terminal works and how to use the parking lock. There are no surprises – the lock functions as expected, and a small fee is taken in exchange for its use.”

Score: 4

Reduce short-term memory load

“Since the flow of using the product is short, there is little to remember while using it. However, some users may have difficulty remembering which card they used to lock their scooter when they wish to unlock it again. To help with this, the user can tap their card, which will be remembered. The system also unlocks the locked scooter as long as the correct card is used.”

Score: 3,66

Think-aloud protocol

Utilizing the think-aloud protocol, we uncovered a few things despite only using it on one test person. First, the person in question is not a regular user of scooters but can relate to the problems in regards to parking them. The test person is of medium technical expertise, which matches well with our intended target audience and the purpose of this exercise. The exercise was divided up into two parts. Part number one tested the flow of having the user park their scooter with a payment card, later using that card as a key to get their scooter unlocked again. Part two tested the usage of the app prototype. The tests were performed with a prototype version of the ScootSeal terminal and a manual version of the locking mechanism.

During the first part of the test, where the flow of parking a scooter with a payment card was tested, the main issues were around the card reader. Due to the limitations in our prototype terminal, the card reader did not look like a typical payment terminal card reader. The non-typical card reader confused the test person and the prototype nature of the test and made it hard to find where to tap their card even though they knew they could do it somewhere based on the description provided by the terminal.

This problem could be tossed up to the terminal being of a prototype nature with loose cables running everywhere, taking away the user’s focus from the task at hand.

Another big problem was that the test person did not know they needed to tap the card again to get their scooter back. They did, however, figure it out quite quickly because the terminal did not provide anything else to unlock the scooter with, causing the test person to ask the test supervisor if they used the card again to get the scooter back.

After part one of the tests, when asked for general thoughts, the test person brought up that they were unsure whether they would know this was a scooter parking station or not, bringing up a problem where we would need to design the parking station in such a way that it’s evident to everyone that this is where you park scooters.

During part two of the test, the test person was provided with a phone running the prototype ScootSeal application made in Figma. Again, the task was to park the scooter at a specific station listed in the app but this time using the app instead of a payment card. The first issue the test person faced was knowing exactly how to find the station they wanted to park at to start the parking session. As we have a list listing the closest parking stations and a button to search for more parking stations, this caused some confusion. The test person ultimately pressed the button to find more parking stations instead of opening up the information for the parking station she wanted to park at.

The following issues were mainly related to prototype mistakes made in Figma, where the tap target of the list items didn’t fill the entire width of the screen, causing the test person to try tapping to the right of the list item multiple times without any results. The test person also needed clarification on the map because it didn’t clearly show the user’s location along with all the parking stations.

The test person was also confused by the “start parking” button, commenting that they did not know if it would open or reserve a parking spot for them. Had the user read the text above the button more thoroughly, they would have figured out that it was the former option, but this shows a clear miss in the flow of the app parking where it needs to be more evident to the user what is happening. This could be done by having the user scan a QR code or similar at the station to start the parking session to eliminate the issue where a user can unlock the station from afar and create a more obvious tie between the station and the user’s app.

Finally, the test person mentioned that they were scared the lock would lock too fast for them to be able to park. Because the locking is intended to happen using sensors, this should be fine, but it’s likely something that needs to be considered in further design iterations.