December 10, 2009Doug Hadden
Comprehensively functional software fails when not usable or intuitive. Government Resource Planning (GRP) software has become more comprehensive in scope. Many government organizations seek out the most GRP features available. Yet, this can provide so-called “feature bloat” that makes it difficult for users.
Usability is an important requirement for FreeBalance software because the applications are often used by people with limited computer and financial skills. There is recognition that usability in enterprise class software needs to be improved.
Governments have unique usability needs. There is often significant movement in civil services meaning that training programs for complex software can be unsustainable. Information Technology and government financial management capacity can differ widely among government organizations in any country. Some government agencies are small where internal product support for complex software is not sustainable.
Enterprise-class software vendors have been fighting the “feature wars”. Software with the most features has usually won. This has created software with far too many unneeded features, often referred to as “featuritis”
The battle for features begins when a new software category is created. The features in software typically do not meet the full requirements of the customer. More can be added over time. Customers who use software are able to consume more and more features.
Eventually software features exceed the ability for the customer to consume. Additional features make the software more difficult to use. Customers begin to object to paying for additional features that are not used or being forced to upgrade. Each new feature begins to have a lower value to the customer.
Designed for the Purpose in Mind
Software is becoming more complex where users are expected to figure out functions. The new wave in design is moving to user-centric design. In user-centric design, software is developed based on user goals rather than on abstract functions. We believe that this approach should also extend to the domain. Software designed specifically for Government Resource Planning (GRP) is more likely to be usable by public servants than software designed for the banking sector.
GRP differs from generic financial management applications. GRP covers the entire budget cycle, supports commitment accounting and provides modules appropriate to government. The budget cycle workflow is implicit in GRP, so financial functions follow standard government practices. And, all modules, including human resources, assets and procurement, are integrated with the budget.
Many organizations recognize that leading software suites were not designed with government in mind. There is an expectation that software screens need to be adapted in order to support the government context. This is true for generic software, but is often not necessary for GRP.
Parameter settings in the FreeBalance Accountability Suite support screen and field adjustment. Fields can be set a mandatory and optional. Additional fields and custom domains can be added to support the unique needs of the government organization.
Language and Terminology
GRP software must adapt to the local language and must support existing government terminology. Civil servants should not be expected to operate systems in unfamiliar languages. And, civil servants should not be expected to use unfamiliar terminology.
Terminology can be a barrier to effective use of software. For example, in government financial management, an approved purchase order commits funds. The term used for this type of commitment differs: commitment, hard commitment, obligation, or encumbrance.
FreeBalance software is multi-lingual. The software facilitates translation. All terms, labels and help items are provided in a file. Translated terms are created in a spreadsheet and uploaded. Terminology can be adjusted through parameters at any time.
Multi-lingual design requires a simplification in screen design. The number of characters required for a label or a field differs among languages. The FreeBalance Accountability Suite provides a simplified data entry screen that adapts easily to multiple languages.
Software applications and software tools
Microsoft Windows is the standard user interface for client/server applications. The Windows interface metaphor is used by most operating systems This set expectations for users by setting conventions. Users become familiar with the conventions and are better able to use additional software.
• Conventions are often mistaken for usability. The standard convention of presenting menus from ‘file’ through ‘help’ is replicated in browser interfaces.
• Applications must conform tightly to OS conventions in order to achieve certifications.
• Changes to the conventions generate significant user problems.
The problem with Microsoft Windows conventions is that these were designed with the notion of “tool” in mind rather than “application”. A user of Microsoft Word or Excel opens the software with a blank slate. The Word document could be a memo, report, table or letter. The user selects various functions to achieve goals. Sometimes, the user can leverage a template or a wizard to overcome the fact that Word is oriented for usage as a tool. Of course, it is impossible for Microsoft to predict all of the potential uses of Word.
Users of FreeBalance software have predictable goals that follow established processes. For example, creating a requisition or approving expense vouchers must follow an established workflow. So, many of the Windows conventions are not relevant.
The FreeBalance Accountability Suite is web-based. The Suite provides application modules rather than generic tools. Therefore, the user interface is and, should not be bound, to Windows conventions. Windows conventions limit usability.
Most enterprise applications expect that users are familiar with the functions necessary to complete a task. Users are required to navigate menus in order to achieve goals. This functional design approach makes it difficult for users to determine which set of functions are needed to complete a task. For example, managers will need to approve purchase requisitions. Managers should not be expected to use the same menu functions to approve requisitions as to create requisitions.
Many users enter a function in enterprise software only to endure multiple input screens. The user can become confused about where they are in any process. Users are often unaware of the steps required to complete any function.
The FreeBalance Accountability Suite user interface is adapting to this user goal approach. The first release respects the conventions of Version 6 with the addition of goal-based functions. The navigation of menus is being adapted to focus on goals rather than functions.
Help and E-Learning
Government Resource Planning software can be complex. Generic help screens are often insufficient to help users. The workflow and business rule parameters are adjustable in the FreeBalance Accountability Platform. The parameters in use and the screen presentation can be different from the generic documentation. User manuals may not reflect the configuration in use by the government.
The approach of generic help and printed/PDF user manuals makes it difficult to find relevant help information. This can be compounded when there are additional training and internal procedure manuals. On-line knowledge bases are an additional medium used for software support. Users struggle with this collection of information.
FreeBalance has developed a new approach. The help and user manual documentation in the FreeBalance Accountability Suite is included in a single content management system. This approach enables governments to add custom documentation, attachments and embed e-learning. The on-line knowledge base is connected to the content system. Users find help in one place. That help is fully adaptable.
Simplifying Data Input and Reducing Errors
Data entry in Government Resource Planning can be complex. The Chart of Accounts used by governments tends to be more complex than used by companies. Data input complexity leads to errors. Like almost all Commercial-Off-The-Shelf (COTS) software, the FreeBalance Accountability Suite supports validation on data entry. Unlike most COTS applications, the validation rules can be adapted without code customization. The FreeBalance Accountability Suite supports Valid Code Combinations and Offsets to simplify data input and reduce errors.
Valid Code Combination functionality allows authorized users to setup a range or a variety of ranges of combination of codes to be used by the users. Anything outside the range configured by the authorized user would be blocked or rejected by the system thus enhancing usability and reducing user error. For example, users could be restricted to entering data from a project to a single fund or a single organization.
Offsetting entries and specific account restrictions can be defined at the financial coding block level. These offsets can be designed for specified users based on profile and functional security permissions. For example, a user who enters a purchase order for supplies will be provided with the proper offset entry as a default.
Web 2.0 Metaphors
Enterprise software has complex features and functions. Customers have come to accept that there is a price to learn and maintain this software, it has become the “cost of doing business”. Yet Web 2.0 software, like Facebook, Wikipedia and Drupal, is every bit as complex, yet much easier to use. Web 2.0 has created new web-based interface metaphors and design that makes it easier to use.
Financial software tends to be designed using the form metaphor for data input and the form and report metaphor for data output. This, again, limits usability.
The FreeBalance Accountability Suite includes some Web 2.0 methods for user interaction. Release 7 focuses on functional completeness. Subsequent releases will include more social collaboration features.
Latest posts by Doug Hadden (see all)
- The (IT) Project was a Success, but the Patient Died [Part 2] - September 21, 2016
- The (IT) Project was a Success, but the Patient Died [Part 1] - September 20, 2016
- Have we over-complicated the ‘smart’ in smart government? - September 8, 2016
- Why PFM reform is integral to smart government - September 8, 2016