CONTEXT
Understanding existing design operations
As I eased into my first few days at Remitbee, it was vital for me to foster an understanding of how different stakeholders work in tandem to inform and contextualize design decisions. During my first week, I conducted an initial audit of Remitbee's design files in Figma, outlining user flows and applications of the Honeycomb design system across its four digital products—web, mobile web, iOS, and Android.
An initial discovery during this period was that Remitbee, as of my internship, had only ever had one full-time design hire, with several previous design initiatives organized by student interns and co-ops. Consequently, few regulated practices were established for design system management and collaboration with developers, with communication typically handled primarily through a sole product manager. Honeycomb had gone through several iterations prior to my internship but required consolidation in the following areas:
Product flows for Remitbee's web application lack established guidelines for responsive scaling from desktop to mobile, creating a disconnect between design practice and the shipped platforms.
Few component sets within Honeycomb leverage native Figma functionality to scale components and other design assets, including auto-layout, variants, and boolean properties.
Large component sets with nested elements (e.g., cards, progress visualizers) did not reference existing components, leading to component bloat and hindering design modularity.
From this point onward, my work on Honeycomb focused exclusively on bridging the disconnect between the web and mobile-web design systems, while my design colleague did the same for Remitbee's native mobile applications for iOS and Android. Though the breadth of our work varied, it was vital for us to facilitate regular progress check-ins with each other and our product manager to establish uniform practices across both systems.
BUILD
Unifying web and mobile-web experiences
Prior to my internship, Honeycomb had separate design system files for its web and mobile-web products, known within operations as the Remitbee Client Portal. This separation created a disconnect between the two products and limited the prospects of responsive scaling using emerging design system technology in the form of native design tokens.
While situating web and mobile-web components within the same component sets is not feasible due to the current nature of conversion, placing them within the same file streamlines the process of pushing updates for shared properties and supports the visualization of component anatomy.
Document structure established for the revised Client Portal design system.
Atomic design in practice
Coined by design technologist Brad Frost,
atomic design is a methodology in which a user interface is broken down into its smallest components and then combined to build larger, more complex structures, such as templates and entire pages.
By using variants within Figma, components with multiple states, including buttons and input fields, became much easier to manage when applied to broader templates that host multiple components at a time. Through atomic design, we focused on creating 'base' components (instances of the smallest components and their various states) to optimize the modularity of Honeycomb components. This approach addressed the absence of modularity in previous iterations and reduced the influx of unused elements.
Design system documentation
For designers on Remitbee's product team, Figma serves as a single source of truth for design specifications. In previous iterations of Honeycomb, documentation was prevalent across visual design assets (namely, colour and typography) but not in components, their respective states, and templates that leverage more than one component at a time.
By adopting atomic design as a framework to support cross-collaboration, documenting the following properties became especially important for future scale:
- Component anatomy
- Variants
- Edge cases
- Margin, padding, and touch targets
- CSS display properties and breakpoints
next steps
Exploring design tokens to optimize designer workflow—and why Honeycomb wasn't ready
In evaluating options to streamline the prototyping experience across all Remitbee products, our team assessed the viability of adopting a token-based system within Figma. For many teams, design tokens serve as a pivotal way to support communication between designers and developers, enabling both stakeholders to collaborate effectively beyond handoff. During my internship, Figma did not support design tokens natively, meaning external plugins (such as Tokens Studio) were the only way designers could engage with tokens directly in their processes.
Beyond this limitation, Honeycomb was not ready to utilize a tokenized system directly in Figma due to the extra layer of complexity it would entail for a rapidly changing design team of temporary designers. This would inadvertently set the precedent that all future hires would be required to fulfill a more technical role. At this time, it was more important for Honeycomb to adopt foundational design system practices to ensure cross-platform consistency.
Migration to Zeplin for design handoff
Though introducing design tokens in Figma was not feasible for existing design practices, tokenized systems are still commonly used by developers to maintain uniformity in theming and are often defined in formats such as JSON or CSS variables.
As Zeplin supports the import of design tokens from various sources, designers and developers are supported in facilitating common practice. By migrating to Zeplin for handoff, designers can still achieve buy-in throughout the process, even if tokens aren't utilized directly in their design tools and workflows.
retrospective
My first UX internship—at scale
My time at Remitbee came and went, and as I reflect on my experiences working on Honeycomb, I completed my internship with several key takeaways that supported my growth in design operations:
Build context, achieve meaningful buy-in: When I began my internship with Remitbee, I was eager to dive headfirst into my work on design systems. However, it was crucial to first understand team dynamics, internal tools, and preestablished design practices to support my transition into day-to-day work.
More than just building blocks: Remitbee was my first opportunity to work on an existing design system firsthand, and I quickly learned about its intrinsic value beyond prototyping. As design systems are contextual and rooted in preexisting workflows, it's important to be mindful of how they can catalyze broader practice.
