Test without Users - Heuristics
Evaluation No. 1: Nadège Keep the interface simple There should not be too many menus in the interface otherwise the user may be lost. Few buttons no need to offer plenty of functions when some won’t be used by a high number of persons: no need to save your list in many formats or send a sms. Easy to read and to distinguish the pages, the functions… Follow the Gestalt Laws. We have to black rectangles giving the opportunity to open new page to realize certain options. There are working in the same way. Speak the user’s language Avoid technical language Be clear in labeling. By reading the name of a button, the user should be able to determine what the purpose of this button is. Be consistent and predictable Related functions should work in the same way Provide Feedback When doing an action, a result should be visible. The change of state also. We can refresh the page or put an information message but this solution could be annoying. Minimize memory load There are not so many information that the system has to search while using our application. Avoid errors, help to recover, offer Undo It is possible to create a confirmation window before realizing something Give the ability to go back in the previous step There should be no point without return, no fatal action. We just have the delete case to improve. Design clear exits and closed dialogs It is not possible to do many actions in the same time. You have to finish one to begin a new one. Include help and documentation We should include a small documentation with screenshots showing how to do the major functions Maybe include also in the help a search by category Offer shortcuts for experts It may be possible to add shortcuts to open a new list or go back in a personal list, to print, to see as list… Provide several representation of a feature Name clearly the functions or buttons Evaluation No. 2: Bodo Keep the interface simple On every page we have not more than 16 functions. That sounds very much, but approximately 4 functions are in pie-Menus around some buttons. So the structure is very simple. The system does not provide too many features, so we deleted the integrated Message-Function to simplify the system. The buttons are clearly labeled. Speak the user’s language We didn’t use many word to describe the button. The most button-functions are very clear. I think we should rename the button “New List” in “New Wishlist”, because the user wants to create a new Wishlist. Be consistent and predictable For button with the same functions we used the same button and label. We only use two types of menus, on the left and right side a “normal” menu, and for persons and gifts a pie-Menu. Provide Feedback The feedback is almost given by showing a new side. Sometimes the prototype need too much time to load the new side. As a solution we can add a Progress bar for each downloading ofa new part, but I think, that’s not necessary. We can recolor pressed buttons. In the pie-Menus, we recolor the crossed buttons. Minimize memory load The user doesn’t need to provide where he/she is, because a name of the person is shown We can recolor the pressed button, to show the user in which mode he/she is. Avoid errors, help to recover, offer Undo We can offer an undo option for all deleted gifts. If a user press the wrong button, he/she is able to go back We have no error messages implemented Design clear exits and closed dialogs Different information are offered on different pages. We can add an log-out-button, but we haven’t implement a secure-System around the system All other dialogs are in closed dialogs Include help and documentation We add a “?”-Button to help the user. We don’t implement any documentation, because we doesn’t need one. Offer shortcuts for experts We add a setting “Show as list” or “Show as Whishlist”, because it is unusable for experts to work with pie-Menus. We add no more Shortcuts in the prototype. But I think we can offer some shortcuts for printing or something else. Evaluation No. 3: Marcus Keep the interface simple We try to keep our interface as simple as possible. We want to focus on a few core-features and not overload the interface. Speak the user’s language We use words like “wishes” instead of “item”/”object”. We use the vocabulary, which people would use in the real word by talking about wishes and “making gifts”. Be consistent and predictable Similar functions should be represented in a similar way in the interface. For example “adding a new wish” and “adding a new contact”. Also Provide Feedback After an action, the result is directly visible on the same screen (but there are some restrictions in the prototype (no new wish etc.) Minimize memory load We highlight the buttons, to show in which the application is (my connections, my wish list), so the user hasn´t to remember that. We also show the name of the person on the top of the page, to show on whose profile page the user is. Avoid errors, help to recover, offer Undo An undo function is not yet implemented, but it should be added to undo actions like creating a new gift/adding a new contact. Design clear exits and closed dialogs If you add a wish, the add-dialog should close and the new wish should be directly visible on the screen (not in the prototype). Include help and documentation We have included a help section. But there is at the moment only a dummy-FAQ Offer shortcuts for experts We added a function to let show the wish lists also as list and not only as pie menus. For expert user this mode is probably more efficient. Concentrate on a few core-features On the beginning, we have thought about implementing a messaging function. But we think that it is better to include current messaging platforms like e-mail. So the user hasn´t to check multiple mailboxes. |
     |