-
Notifications
You must be signed in to change notification settings - Fork 2
Useability Guide
Copyright 2009 – VillageReach.
This usability guide is designed for use by VillageReach developers who are implementing openLMIS, a management information system for the public/private health system employees in developing countries. The purpose of openLMIS is to support efficient forecasting, procurement, and logistics information management at the last mile. Unlike other Logistics Management Information Systems (LMIS), openLMIS includes important data collection and report generation for outcome measurement and cold chain management. By providing local community-based health workers data management tools and training, they will be able to track and manage inventory, reduce medicine stock-outs, and ensure vaccine and medical stores availability and viability. The original audience is located in Mozambique, but there are plans to use the system in other developing countries, as well.
The purpose of this guide is as a reference that describes typical system users and user experience guidelines that are particularly relevant for those users. Since the developers and users have radically different environments and technology literacy, developers may find it useful to actively remind themselves of these guidelines.
In general, the user experience (UX) and human-computer interaction (HCI) fields are well established in terms of best practices and well-know experts. A few of particularly useful texts are listed in the bibliography and worth reading if you are new to UX and HCI. However, UX and HCI best practices for users in developing countries are not well established, particularly for those designing web-based work applications as opposed to mobile technology or general internet use. Also, much of the information is produced by researchers for articles or conference presentations. The goal of this guide to present much of that knowledge in a format for developers. Ideally, this document should be updated as continued experience leads to improved best practices. Developers are encouraged to get feedback from users and from organization members that directly observe users.
This section contains interface element guidelines. This list may seem common sense, but not following these guidelines will cause more substantial problems for local vrMIS users than a typical US user. Referring to this list is valuable in early design stages so that usability principles are a fundamental part of the design.
{graphic}
Because users are likely to have small monitors, pay close attention to how the interface would look on their monitors.
Remove or reduce the global elements to leave the largest area possible for displaying tables, lists, and reports.
Because your monitor is likely larger than your users, be aware of the typical user’s screen dimensions and check where that fold is on each page.
For vrMIS3, the browser dimensions are assumed to be width = 970 and default height = 580.
Because users are likely to scroll, include action buttons at both the top and bottom of the page.
{graphic}
Navigation cues
Because users are likely to be looking down at paper or get distracted during a task, make sure that they can always quickly identify where they are on a page.
Use breadcrumbs that include the tab name so you reinforce users sense of where they are in the interface.
Use consistent labeling on every page so users have a reliable place to check and figure out where they are.
When possible, prompt user with their previous location/activity, such as including a Recent Activity box or taking them to the last place of interaction, such as the third out of four tables on a page. This is similar to the Open Recent concept in many applications.
Use highlighting and color to visually connect tabs/area identifiers to the text below.
Because users are probably still learning how to page through electronic data as opposed to physical data, highlight the total data amount and how to navigate it.
Aim for consistent search behavior across the system so that using a search box is a rote experience for the user.
Smart search/autofill when possible, as recognizing what to select or enter is easier than recall. Also, this will prevent frustration that can arise from spelling mistakes and inconsistencies.
Support browsing the data instead of only searching, particularly until reporting is sophisticated enough to draw attention to trends and outliers. This will encourage users to explore the data set.
Help them navigate through large amounts of data with visual cues (e.g., 1-20 of XX with next/previous) and data management tools (e.g., ways to search, filter, and sort).
Text, Labels, Table Cells
Because the system will be translated into several languages, keep the text clear and concise, and avoid jargon or colloquial expressions.
Because these users are highly unfamiliar with “system terms,” consider how a user would describe what they are doing, instead of what is occurring in the system. For example, a user confirms or saves their changes while the system commits or submits, so use “Save” or “Confirm” on the label.
Data concepts such as dimensions of analysis, while clear to a developer, should be simplified to more common/pedestrian terms like “outcome measures.” Similarly, user-facing error messages must be simple, clear, and non-jargony if you expect a user to understand their next action. Imagine sitting next to a non-computer literate friend and explaining the problem and what they should do about it in very basic terms, then use that terminology in the error message.
Because users scan tables, help them compare like quantities to like quantities. Align table cells and report outputs on the decimal to facilitate easy quantity comparison.
Because users may not have color printers or they may be color blind (red/green or blue/yellow), use two codes to convey information, such as color and shape. If using red and green, the double coding will still give color blind people the necessary information.
Because colors convey different messages in different cultures, consider if the intended audience has cultural implications/interpretation for colors that differ from US implications/interpretations.
The pros and cons to using images in an interface for developing world users are discussed here. It also provides general guidelines on creating and displaying reports.
Images and icons can be a useful way to reduce translation efforts and make the interface engaging. However, they must load quickly or fail gracefully (useful alt text), and they must mean the same thing to multiple audiences. A confusing image is worse usability than a good word.
Some research on developing world users recommends using icons to overcome literacy challenges. However, many of the current vrMIS users should be literate enough to use words, since they also have words on their visit forms. If the system expands to include field workers, revisit the idea of using icons for more of the interface.
As mentioned in the Color section, do not rely on color alone to convey information in an image or graph.
Consider how reporting images may fail in low resource environments, particularly low bandwidth and smaller monitors. Brainstorm different ways to communicate the same information with simple graphics or words and provide a “basic” reporting option for these users.
Uses of typical graphs and tables:
Line graph: Shows trends by comparing two elements over time. Y axis is usually a quantity (total or percentage) and X axis is usually time.
Can
a) quantities of the same items at different times (coverage for men and women in 2000, 2002, and 2004)
b) quantities of different items during fixed period (numbers of working fridges and broken fridges at each health center in 2008)
c) quantities of different parts of an item that makes up a whole (stacked bar graph, numbers of fridges at each status for all fridges in the specified area)
Table: Shows specific, detailed information. Often more accurate than graphs, but less useful for showing trends.
Maps: While maps can be very useful, they must be properly constructed. Keep in mind the following:
Provide options for dealing with limited connectivity, such as offering non-zooming maps as well as zooming ones.
If providing directions, consider how locals navigate (often by landmark instead of street address) and try to leverage this in your directions.
The current guideline for vrMIS is to avoid wizards, as they are difficult to recover from if a user loses connectivity or has to leave the system. Instead, favor designs that prompt users to go in a certain direction through Next/Prev and Newer/Older buttons and include a progress bar.
See the Site Visits area for an example of this design pattern.
Assumptions about the audience and environment
Refer to this section frequently to keep the users’ habits and environment firmly in mind when making design decisions. Learns these characteristics and refer back to them in planning and coding sessions; designing for a consistent persona leads to a more consistent design.
There are many possible designs to support users and work around their environmental limitations. Some design considerations are listed here. Other related design guidelines are found in other sections of this report.
Here are the assumptions about how different user types are expected to use VillageReach applications. Topics covered include a local user persona, how they are expected to work through the application (task flow and use cases), skills (computer literacy), and how long they are expected to be in their role (longevity).
When imagining local users, picture your family member or friend with the least exposure to computers. Connectivity is coming to many developing regions, but it’s still slow and can be expensive to access. It’s unlikely that these users use the computer for much else and are probably very unfamiliar with typical computer and web conventions. As far as interactions, they are likely to do what they have been taught in the order that they were taught it.
There’s a good chance that they are the most computer literate people they know, particularly when it comes to work applications as opposed to general internet use. These users probably have not been exposed to how computers work, so system terms like “commit,” “export,” or “bug” won’t mean much to them. They haven’t seen many other programs, so they may not be able to imagine new features or new ways of interacting with the system on their own. For example, they probably can’t imagine a drag and drop interface – someone would need to show it to them and help them understand what it is and why they would want to use it.
They probably have limited understanding of what is “happening” – where things go when they disappear, what is happening when the system takes a long time, and how to think critically about troubleshooting. Feedback (progress bars, confirmation messages, etc.) is essential for this audience. The predominant learning style is rote as opposed to critical thinking, so they are most comfortable with clear, deliberate steps to accomplish tasks as opposed to flexibility and frequent decision points.
As developers, you need to check your assumptions about what these users will “know” how to do. When possible, have the system do the work for them. For example, skills will vary but they are generally unfamiliar with things like keyboard shortcuts, clicking a logo to return to a home page, using a mouse, advanced searching, or clicking on areas unless they are told to or the object (button, link) has a strong affordance encouraging them to click it. Visualize explaining the steps to a novice user in plain English, and then design the interface to match that description.
On the other hand, these positions are good jobs, and people stay in them for a long time. A typical local user of this system (field coordinator [FC], cold chain manager [CCM], supervisor [S], or Ministry of Health observer) has worked his way up from working at a health center. In Mozambique, there’s a chance that the FCs, CCMs, and Supervisors have used the previous versions of vrMIS and have developed some familiarity with using computers in general, particularly Excel and web-based data entry. vrMIS users receive some training and tech support, although it is limited. Novice users don’t always see themselves as unskilled, and they are likely to become more advanced users. They need an interface that provides a lot of feedback, uses terms that make sense to them, makes decisions on their behalf (avoid “Are you sure?” messages), and uses intelligent defaults so that they can see examples of what vrMIS is expecting in each area. Keep in mind that recognizing what should happen in an area is always easier than trying to recall it from training.
They need an interface that guides them when they are novices but lets them grow into advanced users, such as providing defaults and letting them customize options (such as which columns to hide or display), but allows them to easily reset the defaults.
If the users feel a sense of ownership of vrMIS and feel like it makes their jobs easier, they are likely to adopt it and put in the effort to become advanced users.
Locals: Task flow suffers from frequent interruptions, which could be due to connectivity and equipment issues or from users having competing priorities for their time. Therefore design to help them return to previous tasks (aggressive saving and persistent screens) while giving them the flexibility to quickly switch to other tasks (not trapping them in a process funnel without a graceful exit).
Donors: Often are only interested in accomplishing one task: looking at reports to see how the health system is performing. If they have time and the interface is engaging, they may also explore other reports.
Locals: Primary assumption is that users are working from offline sources (paper, phone, face to face) and then entering the data in the system. There is also an assumption that the interface will encourage them to be more complete with their data entry and be more proactive about solving problems. As some of the new data vrMIS is collecting reaches critical mass, some of the use cases may change as users find ways to change their tasks based on the available information. Therefore VillageReach may need to reconsider its use cases and designs after the system has been in field for some time or when it starts up in a new country.
Donors: Primary use case is to see if they feel VillageReach is providing a worthwhile service and fulfilling its mission of improving last mile health care. For larger donors, like foundations, they may also want to use reports as a way to justify their decision, just as in presentations to other board members or in a newsletter.
Locals: Minimal job turnover, particularly at the field coordinator and above. We assume that they will use vrMIS on a fairly regular basis. Therefore assume users will receive training and have time to adapt to and learn the interface.
Donors: May use the system once or may return frequently to chart progress over time. Use of vrMIS is likely to be infrequent.
Here are the assumptions about the environment in which different user types will be using VillageReach applications. Topics covered include describing attributes of their connectivity, equipment, and information sources (paper, web, mobile, etc.).
Locals: Possible connectivity issues, such as low bandwidth, lack of electricity, or complete lack of internet or phone access. Therefore consider performance issues, graceful failures, and backup methods.
Donors: Generally assumed to have high bandwidth and consistent connectivity. Therefore any pages that are assumed to be most useful to donors can have a heavier page weight.
Locals: Possible equipment limitations, such as small monitors, only black and white printers, and shared workstations. Therefore consider a small and large fold on screen, navigating through lots of data gracefully, double coding so information is not only distinguished by color, and aggressive saving and persisting features to reduce losing work.
Donors: Assume larger monitors, possible (but not guaranteed) access to color printers, and individual computer access, including possible requests to access the vrMIS via smartphone.
Locals: Information may come from many sources: paper, voice (face to face or phone), SMS, smartphone form, Excel spreadsheet, web, or others we haven’t thought of yet. Therefore plan out how the system can be flexible enough to obtain data gracefully from multiple sources. Right now we don’t imagine lots of data sharing, but that may change. At most, allow for printing and exporting to an Excel file.
Donors: Mostly online; may want to distribute data electronically, such as to send to others or export to use in a report or power point. Therefore consider facilitating easy ways to distribute data that is frequently accessed by donors, which is almost exclusively reports.
Creating an interface and system for users and environments that are dramatically unlike you is a significant design challenge, particularly if simultaneously working on projects for more conventional user groups. The users must find the interface usable, useful, and satisfying or vrMIS and VillageReach’s overall “value add” may be abandoned for a more familiar, less robust reporting method. To overcome this challenge, include the steps shown here as part of your standard development process. This will help you maintain focus on the vrMIS users’ needs.
1.Interface Elements Guidelines Review what you know about the intended audience for each interface area. Because vrMIS has several different types of users, take time to discuss how each user is expected to go about their job. Review what you know about their skills and their environment. Good resources are the Assumptions about the audience and environment section and talking to people who have recently worked with users. Since the developers do not have direct interaction with this audience, everyone is likely to have a different idea of what the users need unless everyone comes to a consensus. Skipping this step may result in inconsistent interface interactions and designs that are confusing to the user, which may discourage them from using the system.
2.Identify the primary uses cases for each area/feature. Take time to discuss exactly what the user is doing as they interact with the system. This should include discussing how they are interacting with their data source (like a paper form) and how they are interacting with other people (like what offline actions occur in reaction to information on screen and what activities prompt them to return to vrMIS), Skipping this step may result in designs that create more work for the user so that they decide to stop using the system or that they enter incorrect data because it’s easier than entering the correct data.
3.During the development phase, prototype and test with a realistic data set to see if the interface remains manageable and still allows for graceful navigation. The amount of data in vrMIS will scale up quickly. It is easy for the mockups and prototypes to use too small data sets. Skipping this step may result in the interface becoming unmanageable and overwhelming to users.
4. Conduct usability test with actual users. Since not every aspect of the environment can be recreated here, it is essential that some users be given the chance to test the system before it is fully deployed. The development schedule must include another round of development after this phase. Skipping this step risks isolating users if they do not feel they have some sense of ownership in vrMIS or missing mission critical bugs that only occur in the actual environment. Incorporating the users into the process will increase their willingness to use the system.
This section contains user interface principles that are particularly relevant to the local users of vrMIS. Because the users work in an environment that is so radically different from your environment, keep these key points in mind when designing and implementing the system.
When designing an area, discuss how the primary and secondary users would use this page to accomplish the task at hand. Determine how they are going to get data in or out of the system and then support those actions on-screen.
Remember to consider the entire spectrum of their actions; this may include multiple sources, such as paper, Excel files, face-to-face meetings, phone calls, and SMS.
Focus on the user’s entire task, particularly when it involves more than one screen.
Consider if the user is going to use another medium to accomplish his task, such as paper, Excel files, face-to-face meetings, phone calls, and SMS. Account for these other actions and sources in the interface.
Ensure that the users know which areas they need to visit to complete a task and that they can easily get to those areas.
Given that users may not complete the task in a single session, make sure that they can easily leave and return to the task.
Most users were educated using a rote education system. Therefore, clear instructions and pathing are probably most comfortable for them.
Given the typical use cases and tasks flows, use controls and affordances that make it very obvious how to get from one step in a task to another, like “previous/next” or “older/newer” buttons.
However, do not lock them into a path, particularly if they risk losing work if they do not finish before reaching the final page. Have a flexible enough design to gracefully allow them to leave and come back to a task.
Provide way-finding cues so that users can also quickly locate where they on in the within the system, on a page, and within a task. Some examples are highlighting the active tab in the top-level menu and using breadcrumbs.
Help them return to a task with recent activity prompts and persistent defaults and searches.
Make it clear how much information is available to them. For instance, if a list of recent problems has 20 entries but only displays 5 on screen, write that there are “5 out of 20” entries to encourage them to keep looking through the available information.
Use on-screen text to communicate to users how to use the system, particularly for infrequent but important tasks. They are probably not familiar with accessing online help documentation.
Plan for what users should do if they run into a problem. Make sure they know how to report problems, request enhancements, and report bugs.
Consider if there’s a way to have users help each other, such as a wiki or forum for everyone who uses the system. This may take a lot of effort on the front end, but could contribute substantially to system sustainability.
Make sure that those who have the biggest burden for getting the data into the system also feel that the system makes them more productive. Field Coordinators, in particular, need to feel like this is a value add and worth their time, otherwise the reports used to evaluate the system will be inaccurate.
Make the system enjoyable. For donors, this is probably about making an easy to understand and somewhat fun to use reporting area. For locals, this is probably about increasing their job satisfaction through progress indicators and increasing technical skills.
There are few usability guideline reports written specifically for users in developing countries. However, if you keep in mind the constraints given in the guide, you should be able to determine which conventional guidelines are appropriate to the VillageReach application.
This usability guide is designed for use by VillageReach developers who are implementing openLMIS, a management information system for the public/private health system employees in developing countries. The purpose of openLMIS is to support efficient forecasting, procurement, and logistics information management at the last mile. Unlike other Logistics Management Information Systems (LMIS), openLMIS includes important data collection and report generation for outcome measurement and cold chain management. By providing local community-based health workers data management tools and training, they will be able to track and manage inventory, reduce medicine stock-outs, and ensure vaccine and medical stores availability and viability. The original audience is located in Mozambique, but there are plans to use the system in other developing countries, as well.
Quick, useful reads
Jakob Nielsen’s 10 Usability Heuristics
http://www.useit.com/papers/heuristic/heuristic_list.html
http://designingwebinterfaces.com/6-tips-for-a-great-flex-ux-part-5 (shows good examples of each heuristic)
Donald Norman’s Design of Everyday Things.
Book describes simplifying the structure of tasks, making things visible, getting the mapping right, exploiting the powers of constraint, designing for error, explaining affordances, and seven stages of action. Chapter 1 is particularly useful.
Major UX/HCI guidelines (Apple, Windows)
Apple’s Application Design Fundamentals from Apple Human Interface Guidelines
http://developer.apple.com/mac/library/DOCUMENTATION/UserExperience/Conceptual/AppleHIGuidelines/XHIGPartI/XHIGPartI.html#//apple_ref/doc/uid/TP40002717-TPXREF101
Microsoft’s Windows User Experience Interaction Guidelines
http://msdn.microsoft.com/en-us/library/aa511440.aspx