Our team developed two low-fidelity (low-fi) prototypes. One of these prototypes was hand written and the other was created using Microsoft PowerPoint. Both contained similar frames, yet had very different interface designs. The high-fidelity (hi-fi) prototype was developed in Macromedia Flash MX. This section will analyze the context of the transition between the low-fi and the high-fi interfaces, concentrating on what features were well designed and which parts needed to be changed. Also, because there were multiple low-fi interfaces, decisions regarding consistency had to be taken into account and were handled accordingly. Each low-fi interface began with a main menu with which to select a general set of sections which branch out into the different areas of the program. Based on research and development, the interface we wanted to design should satisfy that of a shallow and broad tree structure. Therefore, the main topics presented in the low-fi main menus were entering information, what to do before eating meals, exercise, entering food information, viewing data, transferring data, and a help menu. Figure 1 and Figure 2 show the differences of the main menu layout between the two low-fi designs.
Figure 1 Figure 2
The hi-fi prototype was a combination of the two types of main menus and is shown below (Figure 3). It used terms that were more clear and representative of the desired actions. Also, it was made sure to include a Help menu that Figure 2 (above) did not have and an Exit feature that Figure 1 (above) did not contain.
Figure 3
The buttons are lined up in two columns so that they are easy to click on and readable. Also, they are listed in a particular order. The items at the top of the screen are the features that will be used most often while the buttons at the bottom will be used less frequently.
Next, an interesting idea was that in order to make the software more personalized as well as easier and faster was to have an area to enter contact information for both the user and their physician. The PowerPoint interface did not include such a design feature. The hand written one had the idea however it required lots of space, meaning it represented more of a narrow and deep tree structure rather than our ideal branching factor. The hi-fi version had capabilities that combined the multiple low-fi levels into a single useful layout as seen in Figure 4.
Figure 4 – the top three images (above) were combined to create the single bottom image.
It can be seen here, that in addition to having the ability to enter contact information, the user is also given control over editing (entering) her exercise plan. Although executing the “Exercise” button from the main menu can do this, it can be done at this point too. This allows the program to support a variety of options, which users prefer. Based on the usability tests, although the majority of individuals did indeed use the “Exercise” command from the main menu, one individual found this path to be more appealing.
Continuing through the program, there is a major implementation difference made between the low-fi prototype and the hi-fi prototype. The main part of the program involves the user’s intake of food. This interface had to be designed carefully in order that it be as clear and simple as possible but at the same time, substantial in that it records all necessary data. Both low-fi designs showed that by splitting food up into groups would hopefully make it easier for the user to detect which food to enter. As seen in this low-fi interface, a simple click on any of the food groups would add a serving of that type of food and, in turn, effect the food chart (Figure 5).
Figure 5
It was later determined that this simple design would not be sufficient enough for our purposes. It did little to reflect our goals of actually recording the food intake of a given meal. There was no way for it to record the amount (fl. oz., oz., g, lbs) and all of the nutrition facts (ie. fat, calories, vitamin C, protein, etc.). Therefore the necessary changes were applied to form the high-fi design as seen in Figure 6.
Figure 6
This design is far more advanced than the initial design. Not only does it record more information, but it gives the user complete control over which information is entered and freedom to enter not only what food group the food is in, but additionally, what particular food it actually is.
A feature that was in one of the low-fi designs that remained identical and simplistic was the idea of removing food from the foods eaten. This would be necessary if a food was accidentally added, or while adding a food, an incorrect value for one of the input fields was entered. Therefore, within a couple clicks any food could be deleted (Figure 7).
Figure 7 – After clicking on “Delete Item” the user can simply choose an item from the combo box and delete the item from the foods consumed list.
When designing our low-fi prototypes, we gave it a lot of thought and consideration for what the program needed to accomplish. With this in mind at the time, many of the frames created were adequate enough for the high-fi. For example, the frames to perform all the essential exercise tasks in the low-fi interface were directly recreated in Flash for the high-fi prototype. In terms of viewing the current workout, the frames were finalized as seen in Figure 8 and Figure 9.
Figure 8
Figure 9
There are a couple other instances when the exact frame from the low-fi prototype was used in the high-fi design. These cases included the viewing and transferring and information between the physician and the PC as well and entering and selecting a request about exercise agendas. In all, the low-fi prototypes provided a more then general view of what the final version of the program should have looked like and after acquiring certain Flash skills and making some of the important changes as stated above, the final developed software was a great achievement that would not have been possible without the trial/error and efforts that were put into the low-fi prototypes.
The members who performed in the usability tests were eclectic. They ranged from college students with no children to adults with multiple children. The questions were aimed at determining what parts of the software required a stronger clarification and how quickly certain tasks could be learned. There were a total of ten individual tasks given to the potential users. The test took approximately 10-15 minutes for each user and they gave significant feedback that helped us derive our final prototype. The users’ results, regardless of experience and age, produced similar outcomes. Of the ten encouraged tasks, there were three that caused particular concern and necessary changes for the final high-fidelity product. Of course, there were other parts that needed minor updates, but the general flow of the software succeeded. Before analyzing the results, a diagnosis of the tasks needs to be examined. There are two overall aspects to the developed product. The first, food intake, and the second, exercise plans and both of their statistics. Between these two premises, the food data outweighs the exercise information in that it is more prevalent in the program and requires more effort to use it correctly. After each user performed the ten tasks, eight follow-up questions were asked. Of the eight questions, five were answered on a scale from 1-9, in terms of agreement with the question, and the last three were open ended, yet basic, questions. A description of each user and their individual responses were recorded and analyzed and are concluded here:
Questions during test:
1. Enter and save your physician information, then return to the main menu.
2. Update and save the age and weight fields in your personal physical information and return to the main menu.
3. Select a workout plan that is most interesting to you and return to the main menu.
4. Request a workout plan from your physician and return to the main menu after sending the request.
5. Say you just ate a bowl of cereal and had a 4oz glass of milk. Enter this information into the food database, save it, and return to the main menu.
6. Enter a meal of your choice manually into the food database.
7. Check your nutrition chart for today and then send it to your physician and return to the main menu.
8. Remove the last meal you ate from the food intake database and return to the main menu.
9. Check the food intake graphs. How much vitamin C do you still need today?
10. Upload one food and one exercise chart onto your PC and send them both to your physician too. Now, return to the main menu and exit the program.
Post test questions please circle 1 through 9; 9 = strongly agree:
1. The titles of the screens self-explanatory. 1 2 3 4 5 6 7 8 9
2. It was clear from the options on the screen
how to complete the tasks. 1 2 3 4 5 6 7 8 9
3. It was hard to enter food manually. 1 2 3 4 5 6 7 8 9
4. The charts/graphs were readable. 1 2 3 4 5 6 7 8 9
5. It was easy to contact your physician. 1 2 3 4 5 6 7 8 9
Please write a few thoughts about the following questions:
1. Describe any particular area you had difficulty with.
2. Describe any feature you particularly disliked and why.
3. Please give any comments, criticisms, or suggestions you may have.
Usability Results
User #1: This user was 19 years old and attends college. She currently has no children. After reading the short introduction to what the test was examining, she seemed excited and eager to begin. She referred to herself as an expert in being able to manipulate Windows and has significant experience with computers in general. She remained silent throughout the usability test and did not try to ask for any help or extra information. When asked to select a workout plan (task #3), the user found it difficult which exercise option to select. After numerous attempts, the user found the path to the frame that contained the options to either request an exercise plan or select one from the drop-down menu. She proceeded to use the drop-down menu, which was later confirmed to be because, “it seemed simple and very useful.” In trying to add a desired food to her database (task #5), it was unclear how to actually add the specific food. There was a checkbox available for selection, a “save” button, and an “add this food item” button, which made this operation difficult. Furthermore, when prompted to send a data chart (task #7), the user jumped between the “View Data” and “Transfer Data” options. She made two trips to the incorrect “View Data” area before finally consulting the “Help” menu. The help menu was clear in mentioning that in order to send information to a physician, the correct section would be “Transfer Data”. As previously seen when adding food, the same problem in terms of which button to select arose when deleting a food. There were multiple buttons to press, either “save” or “delete food”.
User #2: This user is a 51-year-old female. She has three children and before taking the usability test mentioned that a product as such might have been useful during her pregnancy. Her computer experience is minimal, mainly used for checking email on AOL or talking to a few people on Instant Messenger. Other than these two applications, she has just used Microsoft Word and says she should be referred to as a novice computer user with very little experience. During the usability test, she became intrigued, and as she progressed through the tasks, she squinted her eyes as if she was thinking hard as to which selection to make and even moved her head closer to the computer screen, probably to see the text more clearly. The text is a bit small, because the software is meant to run on a PDA. When attempting to enter her age and weight (task #2), she was confronted with the decision to enter “Personal Information” or “Health Information”. Twice, she selected the incorrect “Personal Information” area before reading the rest of her options and finally clicked on “Health Information”. She then felt relieved and was happy to move on, feeling a sense of successfulness. Similarly to User #1, she had problems determining which exercise button to click in order to select a workout plan (task #3). The user clicked on “enter workout completed” and thought this was the correct location the task referred to. She filled out the input fields and saved the data. She then went on to the next task, unable to complete task #3. This was due to the button labels not being clarified enough for any difference in the desired task. In addition, the user had trouble understanding the format of the “Enter Food” interface. Eventually, she correctly executed the tasks relating to food, after questioning me about which buttons to select to confirm her selections.
User #3: This user is an 18-year-old college student. She has no children. She said she can be referred to as a very frequent PDA user and was familiar with how to manage data whether it dealt managing files, word processing, or using the Internet. As with the previously tested users, when confronted with several options on how to save entered food (task #5, task #6), she was unsure which button to select and ended up clicking on the correct button to “add food item.” In the middle of task #7 and task #10, she remarked how the word in the usability test, “send” should be consistent with the word used in the prototype, “transfer”. She did, however, succeed in sending/transferring information. After the test, I explained that she had a valid point, but the reason we chose the word “transfer” was because the data can not only be sent to a physician but can be uploaded to the PC as well. She realized this after completing the final task, which required the transfer or data. Another dilemma she was posed with was whether “view data” would enable her to transfer data.
User #4: This user is an 18-year-old female who attends this university. She has no children. She can be regarded as an intermediate computer user. Before even attempting any of the tasks, she looked at the help menu. Because it was short and brief, yet very specific, she confidently moved through the tasks smoothly. As with the other users, she had some trouble when trying to enter food into the database (task #5). Other than this interface predicament, the only other error was logical. When asked to determine how much vitamin C was still required for the remainder of the day (task #9), she did not realize that she simply needed to subtract the current amount from 100%. She rather continued to look for a frame that gave the exact information.
User #5: This user is a 19-year-old female college student who currently has no children. She was the only user who completed the enter food task (task#5), the way it was intended. The interface provides two paths to get to the frame containing information on editing/requesting a workout plan. For the task requiring a workout plan to be selected (task #3), instead of going through the “Exercise” area from the main menu, she went through the “Enter Information” area. The user also used the “Help” menu to determine the difference between the “View Data” and “Transfer Data” areas from the main menu.
In conclusion, the usability tests proved to be successful in that they helped pinpoint where many errors may occur. We have made a priority list consisting of the top four technical issues concerning the user interface:
Issue #1: The layout for the “Enter Food” interface was mediocre. The users were unable to clearly see how to enter food for numerous reasons. Some were perplexed as to where to look in the interface while others did not know which button to click to actually enter the desired food. All of the users were able to arrive at the correct screen, but were extremely hesitant on how to go about task #5 and task #6. The required information fields were in fact duplicated. Once the food was input to the “manual” text field the user still had to click to add the food to the database, which brought up the same frame as if it was a food that already existed in the database. Once inside this frame there were text fields that required the food name and food group to be re-entered. This proved to be inefficient and unnecessary. Also, there was a line that was intended to be used as a dynamic text box that output information based on a selection the user made about the food name or food group. However, it was simply confusing and was misplaced on the frame.
Issue #2: The next area of incorrectness resulted from not being able to transfer data from the “View Data” area. In tasks that required data to be uploaded, the “View Data” area seemed just as reasonable as the “Transfer Data” area. However, when inside the “View Data” area it was not possible to send information to either the physician or to upload information to the PC. The wording of the areas, either needed to be changed, or a link within the “View Data” area to send data was necessary.
Issue #3: This issue dealt with the tasks requiring the users to select/request an exercise plan. Many of the users were confused about what the difference was between entering a workout versus selecting a workout. Again, the title of the button was not clear and created some of the users to use the help menu, become stuck, or even fill out the incorrect frame.
Issue #4: When asked to enter health information the users frequently assumed the “age” and “weight” text fields could be found within the “Personal Contact Information”. However, this was due to them not reading the full list of buttons where it said “Health Information”. Nevertheless, the button titled “Health Information” was vague. After realizing that they could not enter their age and weight in their personal contact information, they then saw the opportunity to click the “Health Information”.
To analyze each individual task they are each assigned a number on a scale from 1 to 5 where 1 was less difficult for the user to complete and 5 was most difficult.
Task #1: 1 Task #6: 5
Task #2: 3 Task #7: 2
Task #3: 4 Task #8: 3
Task #4: 3 Task #9: 2
Task #5: 5 Task #10: 3
Because the usability tests yielded results that portrayed a high difficulty level, the high-fidelity prototype could then be modified more efficiently.