Bridging Design and Functionality

I’m Meena, a developer at GeekyAnts, specializing in React and React Native, and this is Tanisha, my colleague who’s recently started to get all the dev jokes.

Hello everyone! I’m Tanisha, and I work as a designer at GeekyAnts. Designer, right? I’m here to share that apart from getting those developer jokes, I’ve also started to dive deep into the developer mindset while collaborating with my team. At GeekyAnts, we aren’t just about code; we’re a community of memes, hackathons, birthday celebrations, and epic trips. You’ll find us in heated foosball matches or planning our next tennis game. But if you look closely, what truly binds us is our shared passion for research, collaboration, and building amazing things.

Meena and I work closely, often side-by-side in the React Native ecosystem, but despite our proximity, we’ve realized that miscommunication can create hurdles. So today, we’re here to talk about something many of you have probably experienced—bridging the gap between design and development. It’s a conversation many are having, especially when designers promise, "just one last change," and developers start to feel faint.

If you follow conversations online, you’ll notice that designers are being encouraged to learn to code, and developers are being asked to familiarize themselves with design terminologies like tokens. So, today, we’ve chosen to talk about bridging the gap between design and functionality. We’ll share the challenges, a possible solution, and how we built a universal component library that’s shaping our collaborative process.

Before we dive into the details, let’s acknowledge that the designer and developer mindsets are fundamentally different. This isn’t about a "versus" situation; it’s about how each perspective enhances the final product. When a designer hears about a new project, their mind races with ideas about user interfaces, brand consistency, and user flows. As a developer, I’m more concerned with performance, APIs, and the technicalities that make it all work. We both have a vision, but they don’t always align.

One of the common issues is when I, as a developer, see a design like a complex animation, and I immediately start thinking about how it will impact performance. We’ve even studied the performance of 20 websites, and let’s just say, the results didn’t live up to the design's promises.

Let’s talk about shadows for a moment. As a designer, Tanisha might meticulously craft the perfect shadow, considering its purpose, light source, intensity, and properties like blur and spread. But for me, implementing shadows across platforms—Android, iOS, and web—is far from straightforward. Each platform handles shadows differently. There are even open-source tools that attempt to bridge this gap, but they often fall short. We need tools that are truly designer-friendly, translating their vision into the technical realm seamlessly.

Now, let’s blow your mind with a simple riddle. Here are three squares, all with the same dimensions, 170 pixels by 170 pixels. But, visually, they look completely different. Can you tell why? It turns out that design tools like Figma allow for strokes to be inside, outside, or centered, but this isn’t reflected in the developer's specifications. For us, borders are just borders—they don’t change the box’s dimensions. This kind of discrepancy is just one example of how we, as designers and developers, need to bridge the communication gap.

So, how do we fix this? The first step is building a common language. We realized that even though we were talking about the same concepts, our terminology differed. For a designer, it’s an artboard; for a developer, it’s a viewport. Designers talk about opacity, developers mention alpha, designers use layers, and developers work with z-index. Improving communication is critical, but where do we start? That’s where our small side project, Bridge the Gap, comes in.

Another solution that’s gaining traction across the industry is a tokenized system, which helps foster collaboration between design and development. Many companies have adopted it as part of their design systems, and it’s something we’re actively working on at GeekyAnts as we develop Glue Stack UI.

Why are we speaking about this today? Well, Meena and I have first-hand experience from building NativeBase and now GlueStack UI. Despite sitting next to each other, there were constant communication gaps, especially around design handoff and the development process. That’s why we’re here to share the lessons we’ve learned and the systems we’ve built to close those gaps.

Let’s take a look at an example. Modal vs. Action Sheet—two similar components with very different behaviors depending on the platform. On the web, it’s a modal, but on mobile, it might be an action sheet. Our solution needed to be flexible enough to accommodate both, which is why we opted to let users choose.

The same goes for gradients. While designers can easily create radial gradients in Figma, implementing them in React Native isn’t as straightforward. Often, we have to rely on third-party libraries or SVGs.

Breaking Silos, Building Teams—We’ve covered some common issues and solutions, but now let’s talk about what we did differently. Instead of siloing designers and developers into separate teams, we created integrated squads that promote daily interaction. We also have design system leads who maintain the consistency of components and document everything so the entire team can stay on the same page.

On the process side, early collaboration is key. We started holding regular cross-functional meetings, demos, and feedback loops. We even created workshops that both designers and developers could attend together, fostering a shared understanding of each other’s work.

Building a Library That Everyone Can Use—When it comes to project execution, we laid down a clear structure. We forked an open-source design system and customized it to create our internal system, which we use across multiple projects. We also built a development structure that allows for easy customization and reuse of components.

We’ve implemented checklists for every stage of development, from the requirement gathering phase, where we ask existential questions like, "What is the primary purpose of this component?" to the design phase, where we consider how components will interact with each other and align with the overall design system.

Handing Off Without Dropping the Ball

In terms of developer handoff, we created a specification sheet that includes APIs, tokens, and all the necessary details for each component. This way, anyone on the team can refer to it and understand exactly how the component should behave.

We even took it a step further and developed tools like DSX, a design system builder that allows designers to generate foundation-level tokens that can be directly used in code. We also created Figma plugins that translate code into design files, ensuring a seamless handoff between design and development.

As we’ve grown, so has our community. Tools like Figma’s Dev Mode, Framer, Webflow, and Storybook have played a significant role in improving collaboration, and we’ve been excited to contribute to that conversation by sharing our experiences and solutions.

In closing, it’s all about balance. The balance between creativity and functionality, aesthetics and usability, and innovation and practicality. This balance is what drives successful projects and fosters a thriving environment for both designers and developers.

Thank you all for being here today. If you want to continue the conversation or see more of what we’re working on, feel free to reach out.