Since this was my first project as a solo designer at Visual Boston, it was my responsibility to make all major project-related decisions. And although the UX research phase here was rather linear and limited, my tactical experience from working on the
O2X App helped me — for instance, in developing
variable designs for sections such as Resources. I personally conducted a mini-study, testing this section on the existing portal, identifying the most challenging points, and proposing navigation improvements for more effective access to scientific and press materials.

resources nav: (1) collapsing the sections by default since not everyone needs the searching tools right away; (2) the types are generally matching the types of the users visiting the section; (3) an important for the scientific materials tool
A crucial part of the process was developing the design system. While working on it, I paid special attention to ensuring that the instructions for its future use were clear, since
one of the main goals was for the Linus Health internal team to be able to use components, change media content, and easily create new website sections when needed.

my atomic ds baby
Interestingly, it was the moment when my years of volunteering and work in non-formal education came in handy. Through annotated and ready-to-use components, a detailed Loom manual I recorded, and a live workshop with the Linus Health team, I managed to leave a legacy in the form of a working design system that they still use today.
Of course, with Figma’s constant updates, I regularly adapted and re-adapted component execution. Also, thanks to the bugs I always were keeping myself busy.
A fun fact: not all Figma updates made it into the project. For example, that was when Figma introduced Booleans for components. At first, we were excited that it would eliminate the need to duplicate components in the design system — but when it came to implementation,
it turned out engineers needed to see all component versions in real time to compare and clearly visualize changes from breakpoint to breakpoint and state to state. So, in the end, we still had to include all variations of each component in the design system.
Highly usable design heritage:
→ crearte clear instructions on further use
→ create high-quality and double check usability of the components and DS
→ hold workshops on components use
Raising clarity and responsiveness of the UIs:
→ use best practice for better responsiveness of the sections
→ double check of the prototype and QA at different break points