Simplified Blood Pressure Monitor
Problem |
Background |
Self Blood Pressure Monitors |
Commercial Systems |
Previous Academic Papers |
Relavent Websites
*transition diagram
Our approach to the design of this project was to observe what has been done before and to see what works and what does not work in current commercial blood pressure monitors. We decided on what elements should be included in the design of our blood pressure monitor by using information that we obtained from this course, user feedback on consumer websites, and papers on the usability of home monitoring products. We incorporated design elements that we felt would make our user interface usable and ultimately useful for home blood pressure monitoring. We tried to do all the things that people are supposed to do and make the tasks simple to perform. In this way we hoped it would encourage users to do their blood pressure monitoring more often, giving the Doctor more data to work with. Furthermore, we tried to do better than the leading devices in areas we found to be lacking from the viewpoint of the user or the Doctor. The Simplified Blood Pressure Monitor should be useable for a single user for four months or a couple of users for 2 months each.
*SBPM initial setup screen
The task of taking ones blood pressure is something that is very important to the health of many people. This is especially true for the elderly, and those with diabetics. Monitoring ones blood pressure daily has the potential to save a seemingly healthy person from the effects of high blood pressure, which can go unseen until it is too late. At the same time home monitoring is especially useful for those whom a doctor has suggested daily monitoring. Without easy to use home monitoring systems the user may find it difficult or undesirable to test blood pressure as often as prescribed. This would leave the doctor with potentially large gaps in the requested data. This could hinder the finding of trends in blood pressure readings since the last visit. Our goal with the Simplified Blood Pressure Monitor is to have a device that balances ease of use with information gathering. When an activity that people have to perform becomes a chore they do not perform that activity well or consistently. As an example, Doctors may ask a patient to take his/her blood pressure two times a day and to write in a diary what they were doing around the time of the reading. Although the doctor's orders should always be followed even simple tasks such as these may not be done consistently by patients. If the home monitoring system is not useable they may not take their readings regularly. If they are in a hurry or do not feel like it, they may not put anything in the diary and just make it up before they go back to the Doctor. The SBPM is a simple to use blood pressure monitor that combines the functionality of a blood pressure monitor, with memory for saving readings, a simple diary input page that monitors activity and mood level at time of reading, the ability to view and analyze aggregated data, and data transfer to pc or email. It takes into account that people may not always do things the way they are supposed to. However, if they use the SBPM they will at least give the Doctor usable and analyzable information for that day. The functionality of the machine is also easily accessible because there are prompts on each page that tell you what you are supposed to do to perform specific actions. This will aid users by not having to remember directions, or pull out a manual to perform the main tasks of the application.
The current crop of blood pressure monitors are well designed, but they can still be improved in some areas. These areas include screen visibility, data transfer, and sound. These are some of the areas that the SBPM addresses. The screen size takes up a fair amount of space and should be easily viewable. The screen is color, backlit, and high contrast like that of an ipod or pda. The reason for this choice is that although users of home monitors liked the large screens of their devices, those with low visibility problems complained that the usual black on grey LCD screen was hard to read in various, normal lighting conditions. The buttons are tactile and are sized related to their importance. Furthermore our device enables transfer of information via wifi or usb. This will enable people to analyze their data on other devices, and easily transfer data to the Doctor. A production model would include different clicks for different button groups and a voice that would state the results of the test at least 3 times or until a button is pressed.
Usability features include:
The final interface design for our product came about through group discussions about what we felt was important for the application and user tests. The main functionality of the device including the on button has 4 buttons and a navigational unit of 4 buttons. This adds up to 8 buttons, however, we feel the navigational buttons serve as a single directional unit. Furthermore, the on button is only ever used to start up and is not visible. Therefore, there can be said to be only 4 things to keep track of in the solid user interface. This will be aided by on-screen cues as to what you have to do at each step, and what buttons are needed to perform the next logical function. Also, each button will have a group specific color, will click, and be tactile to aid in memorization. The layout is functional and intuitive with the two largest buttons having to do with the actual test, and the four navigational buttons laid out as a single navigational unit.
Because we are making a standalone unit we had to take into account the solid and graphical user interfaces when we were producing this application. The solid user interface (SUI) was created as the main way the user would have to interact with the program. The graphical user interface (GUI) would mirror the buttons on the SUI when appropriate. The two different ways of interaction with the application were a result of the idea of user prompts. It made sense to use graphical representations of the buttons in the prompts to help the user through the application. Since the buttons were already represented on the screen, it was easy to make them functional. This would just give the user another means of interaction. The application has multiple paths that can be taken. You can test your blood pressure, which involves inputting data into the Diary. You can transfer your data to your doctor or to your computer in Excel format via WIFI or USB. You can look at graphs of all your previous reading. You can look at charts of your previous readings. Lastly, you or your Doctor can analyze and manipulate all stored data to look for trends that the Doctor use to look for patterns telling why your blood pressure may be to high.
The Solid User Interface uses metaphor and affordance to give the user hints about what things do. It also visually and tactilely helps the user remember where things are. As well as, logically group buttons with similar task. An example would be the four navigational buttons that act as a single directional unit for navigating through the application. Metaphors are when the function of something in an interface can be discerned by its similarity to everyday objects the user may have encountered. An example of metaphor in the SUI would be the Start and Stop buttons. The Start button is large, circular, and green. This is used to begin the test, and is supposed to remind the user of a green light at an intersection. Likewise, the Stop button is large, red and angular. In this way it is supposed to resemble a stop sign. Affordance is when it is clear how to tell how an object works by looking at it. One way of doing this is by manipulating real or perceived positive or negative space. Examples of affordance in the SUI would be the concavity in center of the Start and Enter buttons, or the convex shape of the directional buttons. Having a 3D shape can afford pushing. And having concavity in the Start and Enter buttons afford placing your thumb or finger there. Since these are two very important elements of the application we want people to feel comfortable with there use. The Stop button on the other hand is not very inviting and is slightly harder to push than the other buttons.
Descriptions of the main controls are as follows:
*SBPM with start, stop, enter and navigational buttons
Start:
Stop:
Enter:
Navigational Unit:
The placement of the buttons was chosen based on button importance and usability. The two largest buttons, Start and Stop, are used for testing. Since this is the main functionality of the application it was important that they were prominent on the device and easy to hit. This is why they are placed on the lower edges of the machine, and take up so much space. The users of the device may have a hard time seeing and this placement allows the user to easily find both buttons. Placement along the edge, along with their size, makes hitting these buttons trivial. It was especially important that stop be easy to find. If a user's cuff is too tight they could be injured by the device. The Stop button allows for emergency deflation of the cuff and immediate stoppage of testing. The Enter button and Navigational Unit are along the left side as opposed to an original design that had the Enter button as the center button in the navigational Unit. This separation disallows accidental pushing of a directional button when pushing Enter and vice versa. It also had the effect of lengthening the screen's viewing area. This allowed for larger fonts on the screen for better visibility.
The coloring of the buttons was chosen for contrast with the console and with each other. We felt that this would aid in memorization and visibility of the buttons. The colors of Stop and Start are self explanatory and have been mentioned previously. The colors of the directional buttons was chosen for contrast between the button and the raised arrow on top. The Enter button is beige because it contrasted with the console and seemed pleasant. It was also found to be important to differentiate it from Start which has a similar shape.
Tactilely, we wanted to give the user more ways to differentiate the various buttons. It would also make some buttons more comfortable to touch than others. The directional buttons have raised arrows on top that can be felt to point in their respective directions. This is in addition to there placement relative to the other buttons in the cross formation. The Start and Enter buttons are both soft rubber with the names embedded into them. The softness should make the buttons inviting to touch. Furthermore, their different sizes and positions should keep them from getting mixed up. The Stop button is made of hard plastic with raised bumps, and is not as inviting. It is also the harder to push indicating that it is to be used rarely.
In the production model of SBPM buttons will click. The clicking of the buttons should be good for the vision impaired, since the click of each group of buttons should be slightly different. Stop will have the loudest click, while the other buttons clicks will relate to their hardness.
The Graphical User Interface shows the connection between the GUI, the SUI and the task that can be accomplished on screen through interaction with the SUI. The GUI basically uses graphical representations of the SUI controls and text to guide the user through the application at every point. The graphical representation of SUI buttons can also be pressed, just as the real buttons can. As an aid to the functionality of the device, there is always text accompanying the graphical representation of the buttons. This text is immediately updated, and tells what the buttons function is at this point in the program. Having text telling what buttons do help to guide the user, so you do not have to fight the user's own user model for what each button should do. The user model is the users interior model of what an application should do based on experience. Since we are assuming a lack of experience with technology for our older users, this prompting is a way to reduce confusion. Start and Stop still have pretty specific functions that do not really change, but the user still should be prompted as to when they should be pushed. As the user would expect, Start starts the test, Stop stops it and Enter is used mostly for confirmation. However, the pressing of each of these buttons at certain times is critical.
The text in the application comes in three colors. The dark blue, usually for inactive buttons, or just data. The black is used for data or static text, and light blue is for active buttons in the Navigational Box at the bottom of the screen. These prompts were colored so that the user knew which buttons were valid at any given time, by the text that accompanied it. The directional buttons have constantly changing functionality so this was found necessary to make sure that at any given point the user was well informed of what choices were available. The font that was picked was Stone Sans ITT TT Semi. We chose this font because it was bold, wide, sharp, and readable at a distance. While looking at Flash sites on the internet it was found that fonts like Times that have serifs can be hard to see in Flash due to anti-aliasing. Therefore, we needed to think about font and font size for the usability of this product. The average font size is 24pt, with the test results font size being off the chart. At the very least someone should be able to make the out test results.
The buttons on the GUI mimic the buttons on the SUI, and appear at appropriate times in the operation of the device. Buttons like the Navigation buttons live semi-permanently in a box on the bottom of the screen. They are accompanied at all times by text that tells whether that particular button is active or inactive. Furthermore, if it is active what pushing it will accomplish for the user. Text for active buttons is bright blue, while inactive is dark blue. Other buttons on the screen mostly come up in the center box on the screen's right side. This is called the inputInfo box. Since directional buttons are just for navigation any other buttons will show up when they are relevant for the page the user is currently on. The buttons on the screen are 3D to afford pushing. This is because of the ability to select GUI buttons on the screen. It became necessary to make sure people thought that they could interact with those buttons as well. However, they even though they look like the SUI buttons they do act like normal screen buttons. They have a rollover and click state that looks nothing like the user buttons. They give feedback to the user so they know that an action was taken, and differentiate themselves from the 'real' buttons. This helps to simulate the feeling that the screen is a real screen in our Flash mockup.
One aspect of the device that was crucial in the development in a usable interface for our device was information dissemination. Basically, how were we going to display pertinent information to the user in a way that would be consistent and easy to visually parse. We figured the best way to visually organize the information would be to have designated boxes for certain information. Then we would be as consistent in its use as sensible. There would obviously be times when we would have to deviate from the structure, but we tried to keep this at a minimum. The results, internal controls and visual prompts generally exist in six boxes.
*Screen with different information boxes
Box2: the UserChoice Box
Box3: the Result Box
Box4: the InputInfo Box
Box5: the NavInfo Box
Box6: the Pulse Box
The placement of these boxes in very consistent to aid the user in finding the information they are expecting to be in certain places. We did not want to change things much on people so the device would be quicker to learn. Positioning was an issue for the device since it was felt that the original design was too cramped to correctly show charts of readings. So the screen was widened, and boxes repositioned to their current state. The NavInfo Box, which was originally in the place of the Pulse Box was repositioned and reoriented to its present position. Furthermore, the Pulse Box was created to keep track of the patients pulse, as well as, blood pressure. This change gave us more room for results and help text, it also allowed us to display more information than the original design.
The main color for the screen highlighting important information is blue. Important text is a shade of blue, active buttons have a shade of blue text and active regions in some pages have a light blue accent. We wanted to make sure to not overwhelm the user with many colors, so the main use of color on the screen is really the graphical representations of the buttons. We found the blue to be a good highlight color because it is noticeable but not distracting. Furthermore, we felt it was a calming color, which may help relax the user. Use of any other colors were kept to a minimum. The only other color of note is black. This is used for static text like "Pulse", in the Pulse Box. This nearly monochromatic scheme keeps the buttons on the screen the main attraction. The black text and the black borders around the boxes, ground the screen so important information is not lost in a sea of blues.
The application that was created was created to be simple enough to encourage everyday usage. This means we wanted to promote consistent usage so that the Doctor would have more useful data to look at. People may be ordered by their Doctor to take their blood pressure and keep a diary multiple times a day. When the Doctor prescribes this course of action the patient most likely has every intention of doing just that. However, life gets in the way, had to go to a long meeting, kids needed to be picked up early, etc... They may forget to take their tests and that happens. Still, even in the absence of these impediments they may not do their testing because of the hassle of the actual tests. It does not even have to be that difficult. They may not feel like writing in their diary, or they may feel uncomfortable with the technology involved in taking their blood pressure and wish the Doctor would do it. They could also take the test and not keep the diary, and just guess what they were doing for the last month before they report back to the Doctor. The Simplified Blood Pressure Monitor tries to gain more compliance with the Doctor's orders and give the Doctor more malleable data. It does this by making sure that the user is aware of what is available to them at each point of the way. This way they can feel secure in their mastery of the device and do not get confused or bewildered. Furthermore, the device has a rudimentary Diary function within it. This way the Doctor has some basic information that can be used to figure out what if any thing is wrong with the patient by what they inputted into the Diary. SBPM was designed to be able to allow data to be stored and analyzed either on the device itself or on the computer by the user or the Doctor. It has a lot of useful functionality, without being difficult or scary to use. Using SBPM allows the user to do what they want to do with out thinking about it, and without frustrating them. It allows the use of the machines main functionality without looking at a manual. Lastly, it allows for the collection of pertinent information that can be analyzed and manipulated by the user or the Doctor.
The display is non-complicated, and gives hints as to what can be done from the page you are currently on. These guides help to mold the user model so the device will act the way the users think it should, because it should do what it said it would in the prompt. The ease of use should allow for more compliance with Doctor's orders because it takes so little time and is easy to master. Even though we are guiding users through they have many choices as to what they can do. They can check a graph of their readings so far, they can see a spreadsheet of their readings, can send their readings to their computer in Excel, setup a time to email the results to their Doctor, or analyze their data on the device if they choose. We gave users choices at appropriate times that were appropriate for their task, and did not make them have to make decisions that they should not have to make. We basically gave them enough freedom to feel free in doing their task, but not enough to hang themselves with. Furthermore, their should not be a great need to look at the manual since their are prompts on every screen. We assumed most people do not read the manual anyway. This way we had to make the device as usable as possible without it.
The words that were used to communicate with the user were purposefully terse to minimize the words on the screen. This was not only to fit words on the screen but to minimize the amount of reading a user had to do. We felt this would increase the chance that the user would actually read what was on the screen. We also tried to differentiate words that had special meaning by their placement and color.
The pages for SBPM's functionalities are as follows. The Initial Setup page is the page were users input important information for the application so it can properly store and present the test information. There can be up to 2 users per SBPM, but this halves the amount of time that the it can be used. However, since the starting time is 4 months, and you can increase the amount of time you use it by buying a larger memory card, this is not a large problem. Since there are no letter buttons on the SBPM when the user enters Initial Setup and gets to a field that requires alphanumeric input a keyboard pops up with the field you need to fill in attached. The input of information into the device is also made simpler by not having to input odd characters, such as, @. This is already shown in the input field and you just input the words. An example would be ______@______ (_ indicates user places text there). This should reduce errors and should make things less confusing for the user. The user is asked to input the Doctor's email for when they want the readings emailed to the Doctor using the wifi connection. The input of time is also format-specific and offers the choice of military or classical time. The input of the date is mm/dd/yyyy but also can be done very easily by a calendar popup. Which should keep people from making errors by looking for a calendar or trying to remember the date themselves. The rest of the Initial Setup includes choosing whether your last reading or your average should be displayed on startup and your goal test reading.
The Warning Pages basically tell if you are out of power, nearing out of memory, or there was a transmission error to your email or computer. You are given a 5 day warning for out of memory so that you have time do something about it. The SBPM's warnings are terse but useful. They avoid technical jargon and instead tell the user useful information about what they can do to correct the situation. This gives them internal locus of control and is another way that they can feel that they have mastery over the device. The user is presented suggestion in normal terms and are not frightened by bright colors which could alarm them that they have done something terrible. Transfer pages for data transfer or testing are there just to give the user feedback while a process that may take awhile is going on. They make sure the user does not think that something went wrong.
Normal dual user start can be preceded by either the low battery or low memory warning pages if it is applicable. Otherwise, it shows the last reading that was done and offers a choice of users to be tested.
Normal user start will show this users average or last reading, and allow the user to either enter testing mode or see a graph of all previous readings, a chart of the same, allow transfer of their data to the computer or Doctor, or do an analysis of their readings. Though this functionality is for the Doctor, being able to do this may allow the user to notice trends for themselves that they can later discuss at their next appointment.
The Graph and Chart pages are self explanatory. These pages are read-only and cannot be interacted with. However, they do provide a good look at the data that you have accumulated. They also give the user a couple places where they can judge how well they are doing.
Data Transfer can send data to the user's computer using wifi or USB. It can also set up a schedule to email cumulative data to the user's Doctor, or send data now. The list of choices for email scheduling on the Email Setup Page are Monthly, Weekly, and Now. Now is last on purpose so the Doctor is not flooded with emails of single readings.
The Data Analysis page allows the user to manipulate the readings by different variables. A user could see their reading by week, or see there readings for certain days, like Tuesdays, and even see morning or evenings. More ordering is possible with a transferring of the information to a computer where the user could create his own functions in addition to the ones provided. This is obviously for advanced users but the option exists anyway.
Before starting the actual test. The user has to enter their activity and mood levels into the diary. There are many reasons for high blood pressure and if there is a reason for a particular day's reading being high the key to this could be found in the Diary. If the user did not make a full paper diary, at least this diary entry will be available. For each category the user will be asked to choose between high, medium, and low levels. The default answer is high since if it was normal people may never change it. We want to get answers as close to reality as possible. The choice the user made is displayed on the screen so they do not have to remember what they picked for each category. This lessens that amount the user has to remember, since the pop-up drawer disappears after the choice is made.
*SBPM working on user's blood pressure test
Once all Diary fields have been entered the user may begin the test. A Transfer page of a heart beating will appear indicating that the test is taking place. A Stop button will be visible underneath in case the test needs to be stopped because the cuff is to tight or some other danger.
Afterwards, the RESULTS page will show the results of the test and will allow you to re-test if you feel for some reason you want to take the test again. Maybe, your reading was too low because your cuff was too loose, etc... Otherwise you can press Done, and the test is over.
SBPM tries to balance ease of use and getting more relevant information out of users. It offers functionality that is both useful and usable. With the user prompts it helps give a feeling of mastery to its core audience of older individuals who may not be familiar with electronic technology. And with its abilities to be shared, store data and manipulate it, it offers the user attractive functionality. Since the user should be able to gain quick mastery of the device it is hoped that it will lead to testing being done more often, and prevent long lasting injury due to high blood pressure.
| ©2005 SBPM
