The company I worked for was developing an open-source Human Capital Management (HCM) software based on an older Customer Relationship Management (CRM) software. While the software had a basic responsive view for mobile devices, the process and pages of the desktop version were simply copied 1:1 to the mobile view, regardless of whether they were useful or not.
For example, some pages included large data tables that had to be horizontally scrolled on mobile devices. In order to address these issues and consider actual mobile use cases, the company decided to build a mobile app.
As the in-house designer, I joined a team of analysts, backend developers, and mobile developers to work on the project. My responsibilities included ideating and preparing early sketches that would be later discussed by the team, suggesting mobile-friendly solutions for existing system features, testing the proposals with users, and creating final mockups for the development team.
I was also responsible for choosing and adapting a design system for the project. I chose the Material Design System due to its solid documentation, ease of cross-platform implementation (our team used the Vuetify framework), and my familiarity with it.
The HCM system was intended for use by the entire organization, not just the HR department. Every employee had their own account and could perform various tasks, the scope of which was determined by the system roles. This meant that the system needed to be easy for all employees to navigate and find what they need from day one, rather than being a software dedicated only to specialists.
Since the system had already been heavily used in our organization for a couple of years, I gathered insights and pain points from my colleagues, who were mostly IT professionals with high digital literacy and knowledge of similar CRM systems. However, I made it a point to approach the system as a newcomer and ask “silly” questions in order to understand any challenges or frustrations that a less tech-savvy user might experience.
We worked in weekly sprints, with my mockups serving as the basis for the development team’s work the following week. The outdated desktop system was still the basis for all the processes and general functionalities, but knowing that the mobile app would be built using the React Native framework gave me some flexibility to deviate from the desktop version.
To begin, I applied the company’s branding to the standard Material Design UI kit and created a library of UI components. I designed the login screen, including various error states, language options, and handling of no internet connection. I also designed the main menu, which gave users access to all of the app’s modules.
Next on the agenda was designing a standard record list view, which was crucial for the development team as they prepared to test the backbone of the app. Most of the system relied on these record lists, so it was important for the team to have a clear understanding of them.
To improve the user experience, I decided to replace the classic data table view with expandable cards. This eliminated the inconvenient horizontal scroll and gave users a better overview of the records. They could expand each card to see more information about the record or open it to view all of the details.
I also added a quick search box with friendly auto-complete to the main menu to help users find what they needed more easily. The desktop version had dozens of modules listed in a single drop-down menu, which made it difficult for users to navigate.
Another challenge was the calendar. There wasn’t enough room on the screen to present the whole week of work schedules and meetings. I designed a calendar with an expanding week/month view, drawing inspiration from both iOS and Android solutions. This allowed users to select each day and browse the items on the agenda separately.
I also aimed to improve the process of planning work schedules and meetings. For example, when it came to repeating events, I eliminated the tedious process of manually selecting specific intervals and days of the week. While this approach allowed for the creation of highly specific schedules, most users only needed to repeat events weekly or bi-weekly. To streamline this process, I designed radio buttons that automatically suggested the most common repeat intervals.
Testing was an ongoing process that I tried to inject into every part of the project. To ensure that the designs were effective and user-friendly, I tested them with both the project team and other employees in the company. I knew that the advanced knowledge of the system that the project team had could make them poor test subjects, so I also sought out other employees to perform small tasks on the interactive mockups. This helped me to identify any challenges or frustrations that less tech-savvy users might experience.
We also released a pre-production version of the app to a limited number of employees to gather insights from real use cases. Two things needing attention emerged early on. The color scheme of the app was closely connected with the product branding, with disregard to accessibility. I opted for adjusting the scheme for better contrast. Another issue was that the font that I chose in the beginning was too decorative and not legible for large datasets with lots of numbers, so I replaced it with a more suitable one.