Exercise 5 Reflections

Summary of Exercise 5

During this exercise we presented our high-fidelity prototype for the group and received some feedback that we will present below, we will also present our discussion within the group regarding how we are planning to use this feedback.

Feedback

We got some comments regarding the lack of a home button, something that correlated with complaints of our own testing where the test users voiced the same opinion regarding the fact that they had to press the back button so many times to switch back to the main menu window.

The SOS button was something that the group thought was a bit to protruding and maybe its location on the screen should be discussed some more.

Some people in the group thought that an “about” button is something that is standard and hence something that should be added to the UI of the application.

Last but not least there was some worry from the exercise group that the service we provide is not unique enough or rather that we should actively do something that will differentiate or at least show why our service is truly unique.

Our discussion and course of action based on the feedback

Regarding the lack of a home screen button we as a group completely agree with this feedback and will work on implementing this feature as quickly as possible. The reason we feel that this feedback is completely valid is not only because the exercise group and our user testers told us but also because when one takes a look at the 10 usability Heuristics, of the principles is efficiency of use. So it is in our best interest to really implement this feature since it will objectively improve the service from all perspectives.

When we designed the SOS button we thought it should be clear so that in the heat of the moment there should be no question where to look or where to press, and we thought this idea of ours had grounding in the Heuristics “visibility of system status” and “match between system and the real world” principles. Although we where right, the part where we did not succeed is the part of consistency and aesthetic. What the feedback told us is not that the feature is useless or annoying but rather that it is not consistent with the rest of the UI and that the aesthetic we have chosen makes the button rather interfering. With this in mind we are going to tone down the red colour and shrink the font size a bit more to make it less protruding.

The comments about an about button is understandable and our group get where these opinions are coming from and we are going to implement this but not as an about button. Our reasoning is that we have put in quite a lot of work in making the design of the UI consistent and above all minimalistic. What we are trying to say is that we don’t feel like there is a need for an about button just because it usually is one a majority of services. But what we concluded during our discussion regarding this matter is that we have not implemented any way for our users to identify, diagnose and recover from errors which is one of the ten principles of usability herustics. So our current solution is that we will add an help button that will open up a window that explains what to do in case of different errors, and if for any reason the error encountered by the user is not listed there will be and option to report this to the developers so that they can fix this error and continue to improve the service post launch.

 This last piece of feedback was a tough one for our group. We feel that the critique regarding our uniqueness is understandable but unfair. It is understandable since on the surface and what we showed during the presentation the application looks rather generic. Here is where it gets unfair, we feel that the prototyping tool is greatly limiting our vision for this service and so it gives the impression of lacking uniqueness or personality if you will. So how are we going to improve upon this? We thought of a couple of different ways. We discussed the possibility changing the way the service looks since the simplistic design could be the reason to the feel of generic-ness since people feel like they have seen this type of UI before and there is nothing new and exciting about it. Since we know that the human psyche is always looking for new experiences something that was touched upon lightly during the lecture on cognition, but we decided against this idea since this is actually what we want. Our intent was and still is that the UI and the interaction with the application/service should not be something that is taxing on the user’s mind since our target group is tourists and leisure travellers. So in other worlds the feedback could actually be turned into something really positive that shows that our goal in regard to the UI design has been reached. As one can see the idea of changing the UI is not a good one, but our discussions lead us to what we believe is the root issue of this criticism, and that is that during the presentation we failed to emphasize that our service will be tailored to each user. The way we managed to do this is by having the users put in their preferences the first time they use the application so that any content they are met with is something that they will have use of, and this is to further reduce the load on the user’s mind. As far as we know, no other service has the possibility of giving tailor made suggestions and completely cater to the user’s likes and dislikes, so as one can see it is rather hard to show of this idea in a prototyping tool. So for the final presentation we will do our best to emphasise this feature to see if people still think the application/service still is too generic or if it passes as  at least somewhat unique!