CAMAS comprises three portals: one for occupational health professionals, one for employers using Perspectief's services, and one for employees benefiting from those services. Each portal features its own tools, tone of voice, personas, and style guide within our Echo design system. Each portal also contains several modules, many of which have counterparts in the other portals.

Due to the old infrastructure, slow speed, and outdated UI of the software, the company decided to migrate CAMAS from version 1 (V1) to version 2 (V2). All portals and their respective modules will undergo this migration process, leaving little time for research.

The AM (Arbeidsmobiliteit / Workforce mobility) module in the Arbo-portal serves as a management tool for AM programs - meant to assist employees who have either been on extended sick leave or are part of a mass layoff in finding more suitable career paths. On the other side, it enables AM advisors - around 50 in the company - to oversee files, add activities, generate reports, manage search profiles, and facilitate job searches for candidates.

After gathering enough insight, I proceeded to changing the existing screens to the new UI, documented in Echo, our design system. This being a migration project, no big changes were expected. However, the preliminary research led to some big decisions being taken, such as entirely removing the Total Activities overview page, which, I now knew, was tailored to a different persona in another module, but unused by AM advisors.

The existing filters were replaced with a data grid in order to improve the overview of files / activities / documents and boost search speed, addressing a major user pain point.
ile dramatically increasing the search speed, something that we knew was a huge pain point for the users. Other small UI changes have been made to enhance the overall usability of the module.

A big role in this every module in the Arbo-portal in CAMAS is played by reports. Within AM, there are four types:

• Trajectplan / Program plan, written at the start of any program.
• Voortgangsrapportage / Follow up report, after every follow-up talk.
• Eindrapportage / Final report, written at the end of a program.
• Haalbarheidsonderzoek / Feasibility study, meant for a special sub-program within AM.

The redesign of all reports within the Arbo-portal, including those from AM, became a separate project, for which I teamed up with another colleague. Given the plethora of typologies, we developed a template to speed up the design and build process while maintaining consistency across various modules.

While we were busy developing the AM module for the Arboportal, we also had to address Baanbreker (untranslatable) - an essential part of CAMAS used by the employees, or as the AM advisors refer to them, candidates. Baanbreker was a tool meant to help candidates create their search profile (similar to a resume), refine their job preferences with assessments, explore job openings using the Jobdigger search engine (which Baanbreker provides access to), and keep track of their activities.

Baanbreker's current form is outdated and no longer meets the needs of stakeholders and users. Moreover, it's operating separately from the Employees' portal, which raises privacy concerns. Recognizing these issues, we understood the necessity of completely redesigning Baanbreker – it wasn't merely a migration project but a comprehensive overhaul.

Simultaneously, I had to shift focus from designing for AM professionals to accommodating individuals from diverse backgrounds, many likely participating in the program due to illness affecting their current job situations.

In the beginning, I took part in a brainstorm session with the stakeholders of the AM module and other closely related modules, which led to the creation of the new vision for Baanbreker:

• The employee takes responsibility and is self-reliant in CAMAS, allowing the advisor to provide the right support.
• Increasing employer engagement.

There was a clear recognition for a new direction for the entire Werknemerportal: modules should no longer be specific to individual programs; instead, employees should have access to generic modules irrespective of the service they're utilizing. Of course, there would be exceptions, with Baanbreker being one of them. This vision was then translated into a series of user stories essential for the MVP, ensuring the continued functionality of Baanbreker and its counterpart, AM, in the Arbo-portal.

The project took various turns. Once I had a clearer structure in mind, I developed wireframes for the most crucial flows. Together with stakeholders, the product Owner and the dev team, we determined what should come first.

It was decided that the next big topic the team should be working on would be Taken / Tasks, a separate module in the WNP through which the candidates can receive, view and complete tasks given by the advisors.
‍
Delaying intuition until the problem is understood continues to be the most effective method. This is the moment during a project when having good questions is far more useful than good solutions. I went back to my pool of AM advisors and stakeholders, this time focusing on how they define, assign and enforce tasks.

Tasks will be categorized into Openstaand / Open and Afgerond / Done, each as separate tabs displaying their contents within containers, to keep things organized. I've done thorough research to make sure that only crucial information is shown in these containers, considering candidates may be experiencing burnout.

To prevent them from feeling stressed or overwhelmed, we aim to keep the number of tasks in the "Open" tab low, ideally not exceeding two. This aligns with advisors' preference to work on 1-2 tasks per session, to be completed by the next one. Conversely, they may accumulate 50 to 100 completed tasks over a year, necessitating a search bar.

It was time to start testing with the AM candidates. As there's no standard approach or incentives within the company due to the delicate nature of the matter, I asked several advisors to facilitate the contact. I gathered 7 people and put together the prototype.

I continued to iterate and test with another pool of candidates. At the moment of this being written, the screens for Taken were ready for production and I was busy checking the connections with the AM module in the portal for professionals.

But as it is the case with any B2B product, these modules are alive and they constantly adapt to the needs of their users, so the work is never done. Next comes the pilot phase and improvements are sure to follow.

As of the current writing, the AM module within the portal for professionals is built and in pilot phase. We are busy tracking its performance and gathering valuable feedback and insights from the pool of users in the pilot. A private channel on intranet ensures fast and clear communication. The info comes back  through the help of surveys, feedback forms, interviews, but also direct comments via this channel.

We used several UX metrics (to be continuosly monitored) that would ensure a well-informed growth strategy, amongst which: