As the only designer in an cross-functional development team I lead a series of initiatives aimed at re-integrate design within the product development process. Our iOS and Android applications for hearing aid wearers offered features like chat, troubleshooting, and a hearing aid wearing time tracker for people aged 60+ in the U.S.A, Canada, and several European countries.
The first order of business was to generate tools to enable the entire team. The design system would serve us all as the source of truth to keep consistency. Out-of-date Sketch files were available, which I used to rebuild the system in Figma, and with the assistance of developers I could cross check the design components with the implemented ones, and add the most recently created ones to the design files.
The Product Owner would have visibility, drafting tools to play, and solid references to approach developers or stakeholders. Developers and QA would have documentation and a source of truth. I would have tools to create high-fidelity designs quickly and provide brand governance – it was a big effort upfront, but it paid off in the long run.
The system helped us keep track of components evolution over time. Taking into account that the maintenance relied solely on me, and we pursued a simple solution for all of us to use, we agreed on a versioning system per file and not per component.
After not having designers for an extended period of time, the team wanted to put special focus on having documentation, open files, multiple references; in summary having memory for posterity. The name of the game was future-proofing.
We had files for Tokens, Atoms, and Molecules, and they were divided between Android and iOS. Part of the goals of reconstructing the libraries was to help the team pursue app-parity as much as possible.
Current files were marked with green release number. Old files were marked with a grey release number, with an [Archive] prefix, and stored in an Archive folder.
Our users are adults and seniors, it was fundamental to make accessibility a priority for our apps. I did an audit of the apps on both OS, taking screenshots of each screen and placing them in a matrix against font sizes. I took especial care of the top font sizes among our users.
The goal of this audit was to find the threshold for diminishing returns at bigger font sizes and set a cap. I color coded the screenshots by the level of impact on the interface, added notes describing the issues, and added suggestions on how to fix them.
We discussed with the developers different approaches to address the issues globally instead of a case-by-case scenario (which was the way it was being handled at the time) and agreed on guidelines. Fundamentally, we set a cap for each text size available, thus eliminating the scenarios where font sizes became so ridiculously big that they would break the interface.
In orange I highlighted the screens that were readable but had display issues. In red I highlighted the screens that could not be read (either partially or completely.)
Side-by-side of a real-life scenario and the design visualizing the same screen with the agreed font limits in place. I created high-fidelity mockups for the most important screens to make sure the agreed typescale would solve the most important cases.
As we improved on the font sizing we also needed to modify our colour palettes to properly address the accessibility issues present in the apps. Our goal was to reach a AAA WCAG standard throughout the apps.
With the accessibility updates we could also finally catch up with the most recent updates to the brand colour palette and make our brand experience more cohesive. Additionally, we had the chance to update the dark-mode colours which hadn't been refined since they were first implemented.
