...
We found that our UI changed dramatically from the paper prototype to the computer prototype. This was because we were limited to styles that were provided by the Android SDK and we had not considered how limited the screen space was on a phone. However, the paper prototype step was very helpful because it forced us to decide on our scenarios and ensure that it was easy and intuitive for the user to complete the target tasks.
We were not able to prototype some key touchscreen interactions using the paper prototype, so during the computer prototype we made the decision to add tabs to toggle between pages instead of having the user swipe to get between screens. There was no indication on our UI that the user should swipe to change screens, so we changed the UI to feature two large tabs at the top of the screen.
In general, we tried to follow UI designs that were already very common on phones to ensure that users know how to interact with our app. For example, selecting friends to invite to a lunch on our app is very similar to the way you select friends on Facebook. We observed that some users were confused what it meant to “confirm” attendance to a lunch once they had already accepted the lunch, so we added a line of instruction that informed the user that confirmation of their attendance was being requested. This made it more clear to users that there was a difference between simply accepting a lunch and confirming it as the lunch is approaching and you get a reminder.
...
Users weren’t confused about confirming their attendance to an event once they got a notification, as they were in previous user testing iterations. However, we had to explain to them that this was an invite they had already accepted and now they were getting a reminder/confirmation request for it. Once we asked them to respond to the reminder, they understood they had to confirm their attendance. If a user was using the app, they would understand on their own what the lunch was because they would remember having accepted it.
Some users confused the “Cancel” button for a button that would take them back to the previous page rather than a button to cancel the lunch because they were the creator. We had a dialog box pop up and ask the user if they were sure they wanted to cancel the lunch, so the users didn’t accidentally delete a lunch when they just wanted to go back. However, to avoid this problem entirely, we should make it more clear that the lunch was created by you and therefore you have extra control. The button should also be renamed to “Delete” or “Cancel Lunch” so the users don’t think they are cancelling the page. Also, putting the “Cancel” button next to the “Edit” button might make it more clear that these are buttons that change the lunch.