Bridging the Gap Between Design and Development
Initiated a new design documentation framework called Design Sync, with the aim of setting a clear standard for design handoff.
During the redesign of the HNB Digital Banking app in 2021, one of the key challenges was the lack of a clear, standardised way to communicate design intent, especially animations, transitions, and interaction behaviours between the design and engineering teams.
This was before Figma’s Dev Mode was released, and while we had a design system in place, critical behaviours and interactions were often lost in translation.
- Inconsistent implementation of components.
- Misalignment in interaction behaviours and transitions.
- Repeated QA cycles due to overlooked micro-details.
- Developers needing clarification for missing specs.
At the time, Figma Dev Mode hadn’t been released, and there was no structured way to communicate animation, interaction, and edge-case behaviours to engineers. My goal was to introduce a specification workflow that clearly documented how each design element should behave and adapt across platforms.
I wanted to remove the guesswork by introducing a shared visual language for specifications, so engineers weren’t interpreting documentation differently depending on the designer. This meant creating a reusable system of annotations, measurements, and behaviour notes.
Standardise visual documentation and specifications (such as spacing, behaviours, motion, and interactions) to minimise design inconsistencies and UI bugs post-release.
We introduced detailed spec documents for every key screen and component. These included:
- Clear annotations for spacing, sizes, and states.
- Motion behavior descriptions for animations and transitions.
- Interaction notes to define tap, scroll, and swipe responses.
- Edge-case flows for situations like failed logins or network errors
To avoid inconsistency across designers, I created a shared design spec toolkit inside Figma. This included reusable components such as:
- Annotation labels and lines.
- Platform-specific spacing guides.
- Icon and color usage callouts.
- Behavior tags (e.g., “animated”, “on hover”, “error state”).
This meant any designer could jump in and create clear, consistent, and developer-friendly documentation—minimizing guesswork and speeding up reviews.
The specification documents acted as a secondary QA layer before development even began. By detailing interactions, constraints, and usage upfront, we significantly reduced:
- UI bugs caused by missing information.
- Design inconsistencies across platforms.
- Back-and-forth between design and engineering during sprints.
The specification documents acted as a secondary QA layer before development even began. By detailing interactions, constraints, and usage upfront, we significantly reduced:
By introducing a structured design specification document, communication between design and development became significantly more efficient. Animations, edge cases, and platform-specific behaviors were clearly documented, reducing back-and-forth and ambiguity.
With a shared visual language and standardised annotation system, engineers could interpret specifications consistently, regardless of the designer. This reduced inconsistencies in the final product and created a more unified user experience.
The clarity of design specifications resulted in a noticeable reduction in UI bugs during QA and post-release phases.
Creating this documentation taught me how to better communicate nuanced design behavior to developers—and to speak their language while advocating for the user.
Creating this documentation taught me how to better communicate nuanced design behavior to developers—and to speak their language while advocating for the user.
Thinking ahead to how UI should behave in different states (errors, loading, edge cases) became second nature. Designing for the ideal path is easy; designing for the unexpected is what makes it great.