This guideline will give comprehensive insights on how to develop a consistent, user friendly and accessible new openIMIS frontend module.
Content
01 Introduction to openIMIS’s Design
The following section will give you a short overview of the as-is situation of openIMIS’s user experience (UX) and user interface (UI). Therefore, we will introduce you to the current situation of openIMIS’s frontend, the found potentials and problems as well as the objectives of having this Design Guideline in place.
Current Situation (Release 2024-10):
Based on the Project Student Project 2024 UI/UX the UI and UX of openIMIS were evaluated. The approach included three different methods to collect information about the usability of the software. The first method which was applied was a user survey to get direct, anonymous feedback on the overall frontend. Secondly, a usability testing phase was done, including three attendees. Lastly, the current state of the UI/UX were checked against standardized heuristics.
The outcome of the evaluation can be found here: 02 Potentials & Problems.
As a result of the analysis it can be said, that openIMIS does already implement several design elements to enhance the user experience. With a moreover consistent UI and “Material Design” as a baseline framework, it isn’t mandatory to completely implement a new design strategy. That’s why the following design guideline will help developers to implement new frontend modules, still based on the current openIMIS design-
Potentials and Problems:
As mentioned in the section before, potentials and problems were found during the analysis. All possible enhancements were documented (List of findings). All findings were checked against an evidence or observation. Lastly, recommendations to solve those problems were invented and documented as well.
Objectives:
The following Guideline will have the objectives mentioned below:
Ensure a consistent UX/UI of openIMIS
Introduce the design principles of the software to new developers
Providing information to develop new frontend modules
Enhance accessibility and efficiency of the openIMIS platform
02 General principles
The general principle section will introduce concepts and frameworks which should be used overall in openIMIS UI, whether you create a new module or just change the existing components.
Material Design Framework:
The openIMIS frontend uses Googles “Material Design” design system as backbone. Therefore, it is useful to go through their official documentary to get familiar with the concepts. As the detailed documentation includes all needed information, this guideline will not provide any deep-dive into the system. You can find the documents at https://m3.material.io/.
User-Centered-Design (UCD):
By applying UCD to the development process it enhances the acceptance of an application as well as minimizes the amount of needed UI/UX changes after the release. Implementing UCD means to involve the user at a early development stage already, to discuss for example about the page navigation or needed controls. Thats why, including a design review into the development of a new frontend module with a current openIMIS user would be useful!
To dive deeper into user-centered-design you can find a comprehensive article here:
https://usabilitygeek.com/user-centered-design-introduction/#:~:text=User%2Dcentred%20design%20(UCD),user%27s%20requirements%2C%20objectives%20and%20feedback.
Usability best-practices:
Getting familiar with usability is crucial to develop a user friendly interface. As the subject includes several areas and a lot of topics to cover, it is good to know the basics. Thats why getting familiar with the basic heuristics is recommended. One possible source can be the 10 UX Heuristics by Nielsen https://www.nngroup.com/articles/ten-usability-heuristics/. Those cover topics like consistency, visibility, user controls or error prevention.
Responsive Web Design:
As the amount of different devices and therefore screen ratios varies between the users of openIMIS the layout of the application should comply with responsive design. Hence, all implemented components should scale in a way, that they still provide an acceptable user experience (no overlapping of components, readable labels and font size, etc.)
If you want to know more about “Responsive Web Design” then look at the following article. You will find a introduction into the topic as well as some solution concepts in HTML and CSS.
https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Responsive_Design
03 Branding overview
The openIMIS initiative already established a corporate identity which introduces colors, fonts, logos, icons and texts. Hence, taking a closer look at the following documentations is really helpful to develop frontend components. Most of the already developed UI-Components will already include the colors and icons, but if you want to introduce a new one, you should check, whether a suitable icon exists or which colors to use.
OpenIMIS Colors & Logos | |
OpenIMIS Icons |
You can find all existing documentation to the branding of OpenIMIS here: https://openimis.atlassian.net/wiki/x/BwCrCw
04 Navigation Guide
Navigation between different screens inside the application is a core part of the user experience. The following principles set a baseline for a consistent and intuitive user experience across OpenIMIS.
The navigation system overall should rather be build more broad then going into depth. Means, it is better for users to have many menu items on one navigation level rather then building a structure where they have to drill-down into several levels. To provide an overview of the navigation system you can take a look at the following navigation model.
Navigation Model
The model includes several Screens, Triggers and Actions. All those will be described in the sections below. It is based on Material Design best-practices. With a depth of three levels and also just 4 different screens it provides a easy understandable but also comprehensive approach to build a consistent, user-friendly navigation. As the user does not need to recognize all the time, how to open the list of entries or how to add one, it will make it easier to navigate through the app.
Within the shown model it is possible to add another navigation level. As some entities (e.g. policy holders) do have direct related entities (e.g. policy holder insurees) it is possible to add a List Screen to an existing Detail Screen. This would result in the following navigation path:
Home Screen
→ List Screen (e.g. Policy Holders)
→ Detail Screen (e.g. one Policy Holder)
→ List Screen (e.g. Policy Holder Insurees)
→ Detail Screen (e.g. Insuree)
The developed navigation model is shown below:
Screens and Menus
For OpenIMIS the following navigation principles and components should be used:
Home Screen
This screen is always the first one to show after entering the application (after the login). It does provide the user as a starting point into the different menus. From here is it crucial, that already a lot of menu items are available, in best case grouped into logical segments. The Home Screen as described is already a core component of OpenIMIS and is used as the starting point of the application.
Besides the menu items, the Home Screen should also provide a search component to give the user the chance to navigate to List Screen alternatively. The search should not redirect the user to the Detail Screen.
The above described tasks of the Home Screen also include that other operations (like Add, Update, Delete) should not be accessible directly. Therefore, the user should be redirected to the foreseen screen. The following overview will describe what the do’s and dont’s for the development of the Home Screen are.
Do:
Add many menu items on the this level to reduce deep levels of navigation
Provide a search to the users with that they can navigate into a List Screen directly by searching an entry
Dont:
Add possibilities for the users to directly jump into the Detail Screen
List Screen
On the second navigation layer we use lists to show the users multiple entries to a specific entity/topic. Therefore, the screen includes two main components, first the search query grid and secondly the list of entries. At this screen the users will have the most possible control over an entry. They could: add a new one, delete an existing one, select one or multiple ones as well as show one in detail (redirect to Detail Page).
Add new entry:
To add a new entry to the list the user has the the possibility to click on the existing “Add-Button”. If no added context (e.g. Family for Insuree) is needed, then the user gets redirected to the empty Detail Page to insert the needed data for creating an entry.
Detail Screen
Context Screen