Development Process

This section details the creation and development of two R.I.S.E low fidelity prototypes, with a look back at a few of their original mock screen shots.The motivations and goals behind those designs are discussed, as well as the process used in arriving at the high fidelity prototype.Finally, a discussion of the usability tests is presented.

Two separate low fidelity prototypes were initially created.Both designs took similar approaches to meet our system goals for functionality, usability, and attractiveness.Letís examine both now.

First Low Fidelity Prototype:A Good Starting Point

Figure 3.1

Our first low fidelity prototype for R.I.S.E. presented a good starting point for how a few of our system components would ultimately look and run.

In general, the screen shots in this design fulfilled some of our systems most basic functionalities.Figure 3.1 shows a mock screen shot for a calendar that would allow the user to keep track of daily, weekly, and monthly tasks and appointments.The user would also have the ability to both edit and add notes at his or her discretion.

†††††††††††††††††††††††††††††††††††Figure 3.2

Meanwhile, this design would dock both the left and bottom portions of the calendar screen.What is visible would depend on whether the user has selected weekly, monthly, or daily as his or her plan of action.Each different option would entail a different screen to be displayed.Under this design, the menu and logout buttons would be visible at all times.The idea here is that the user can easily navigate back to the menu or exit the program both quickly and easily with one press of a button.

The screen shot sketch in Figure 3.2 also shows these feature as well.The mode of display here is again the same.Docked are the options for video, audio, and pictures as well as the menu and logout buttons.One more screen shot shown in Figure 3.3 shows how a user might customize certain features.These included color, ordering of items, different animations, and more.Once again, the same principle holds where the item, menu, and logout buttons are docked to the left and bottom of the display area.

††††††††††††††††††††††††††††††††††† Figure 3.3

This theme fit our goal to have a consistent interface very well.A problem that our group foresaw, however, was the limitation the docked toolbars would have on the display size of the screen.With our application especially being on a small PDA device, we felt it would be of more interest to maximize the display size while figuring out another means to improve usability. Other meaningful design feedbacks were pulled from this prototype as well, including attempts to be consistent in the user interface and having side menus to reduce backtracking.

Second Low Fidelity Prototype:A Comprehensive Look

The second low fidelity prototype gave us a more comprehensive idea of not only what our system would look like, but also how screens would flow and interact under user control.Ultimately, concepts and ideas from this second prototype became the primary basis for our preliminary implementations of our high fidelity prototype using Visual Basic.

Like the first prototype, mock screen shots were made for each of our most important features.Interactive screen shots were also added to experiment with the systems overall look and feel.These included login, menu, and transitional screens, all of which we recognized as being vital to the effectiveness and usability of our software system.

It is important to keep in mind these screens strived to meet our original functionality and user targets before our usability testing later gave us the necessary feedback to make important changes.Certain features and needs in this low fidelity prototype were later discarded or for the most part significantly changed.Coming to terms with the high fidelity prototype will be discussed in greater detail later in this section during the usability test walkthrough.

In the second prototype, the welcome screen, shown in Figure 3.4, fulfilled our original requirement for user authentication and privacy.Although we later aborted the need for authentication, the screen shot provided the conceptual and visual framework for our welcome screen.We were originally targeting our system to one user of his or her PDA.The screen did not ask for a user name or personal information in the welcome screen.This would ideally have been given and stored in the initial setup and installation stage.We assumed here that our user had already initialized the system and was logging in beyond their very first time.With that, our user would be ready to start interaction with R.I.S.E.

††††††††††††††††††††††††††††††††††† Figure 3.4

Note:All of the screens for the second prototype as laid out side by side are provided near the end of this section as a complete whole in order to facilitate viewing the transitions and interactions between the screens.

Before our main menu page is viewed by our user, we felt a quick reminder of important events, meeting, or tasks would be convenient and useful.Any favorite quotes, pictures, or scheduled events would go here as well.Ideally, this page would have been easy to customize to whatever the user wants shown here.Other parts of our system would have the option of being customized as well.We felt this would be an important feature to better tailor our system to our users.

††††††††††††††††††††††††††††††††††† Figure 3.5

The main menu, shown in Figure 3.5, then sets the stage for navigating to all of our targeted features for R.I.S.E.Here we have the more prioritized tasks ordered from top to bottom.These include daily log, reading materials, video/audio, medication, calendar, contact, and customize menu.Usability tests and walkthroughs later gave us a better understanding of which tasks were more frequent and helped us narrow down these choices to a manageable few.Several menu items and the names of each menu item seemed to have been the most appropriate at the time.

Ideally, our intention was to have our users complete some sort of nightly journal at the end of each day.To make this easier to remember, we felt a feature was needed to provide a notice of whether this task has been completed or not completed.

†††††††††††††††††††††††††††††††††† Figure 3.6

Inside of our daily log menu, as shown in Figure 3.6, we formulated several options.One was to allow our user to record his or her current mood at any particular time of day, any number of times.Choosing to do so would take the user to a screen where they can enter in their anxiety and depression levels.Figure 3.7 shows this screen.From here, the user would have the option of also accessing our self-help tutorials and guides (We later saw the importance of this task and made access to Immediate Self Help directly available from the login screen in our high fidelity prototype).If the user did not want to write for whatever reason, the log would be stored and shown on a separate screen along with any other logs that have been completed that day.

††††††††††††††††††††††††††††††††††† Figure 3.7

Accessing the self help tutorial would have taken the user through several screens focused on physical and cognitive therapy, ending with a post test of their anxiety and depression levels (The full layout of screen shots at the end of this section gives a detailed view of this concept).

Indicators on how the self-help affected their anxiety and depression levels will be visible on the log chart.Further, completing the nightly journal will take the user to the daily logs screen so that the user can see and reflect on the events and feeling of that particular day.Another option would allow the user to write the journal on another platform or on a personal computer and upload the entry.Emailing this entry to his or her therapy group or psychiatrist is another option.Other forms of communication between the user and both the therapy group and the psychiatrist are available through email or a phone list, as shown below in Figure 3.8.

††††††††††††††††††††††††††††††††††† Figure 3.8

Other features include video, picture, and audio capabilities for the user to view his or her favorite movies, to bring up pictures of loved ones, or to listen to their favorite song.Shots of these original screens are viewable in the accompanying screenshot sketches at the end of this section.Additional screenshots include areas to enter detailed information about prescription drugs, refills, and notification alarms. A daily or monthly calendar also allows the user to track day-to-day activities and monthly events.

These additional features serve the purpose of making R.I.S.E. as much a universal and everyday application as possible while doubly serving its main purpose of treating depression and anxiety.Most of these features were kept for the high fidelity prototype.Slight modifications to the interface were made following the usability tests, the topic of our next discussion.

Complete screenshot sketches and transitions for the second low fidelity prototype:

Click on each thumbnail to view larger image.

Figure 3.10†††††††††††††††††††††††††Figure 3.11†††††††††††††††††††††††††Figure 3.12††††††††††††††††††††††††††Figure 3.13

†††††† ††††††††††††††††

Prev Topic Next Topic