Cross Platform Development

3 posts

slack2 min readCurated summary

How Slack Rebuilt Notifications 📣

Slack rebuilt its notification system to reduce noise by replacing years of inconsistent, tightly coupled behavior with a unified model. The redesign separates what activity users see from how they receive interruptions, while aligning desktop and mobile settings. By combining backend migration strategies, auto-saving controls, and shared UI patterns, Slack aims to make notifications predictable and easier to manage. ## Diagnosing Notification Overload - Notification frustration is common, especially for users in many channels. - Notification issues are among Slack’s top three sources of Customer Experience tickets. - The underlying problem was architectural as well as behavioral: - Desktop and mobile used conflicting preference systems. - Equivalent settings, such as “Nothing” and “Off,” behaved differently across clients. - Activity preferences were coupled to push delivery. - Settings could fall out of sync between desktop and mobile. - Advanced options were scattered or difficult to discover. ## A Unified Notification Model Slack introduced a simpler set of controls: - Channel notifications now offer: - **All new posts** - **Mentions** - **Mute** - Push notifications have separate on/off controls across desktop and mobile. - Advanced features, including mobile “badge all unreads,” are easier to find. - Global preferences use consistent structure and language. - Simplified preference logic improves synchronization between clients. ## Refactoring Preferences Safely - Slack migrated users from four conflicting preference systems to a unified model. - The new model separates: - Desktop activity: **Everything** or **Mentions** - Desktop push: `desktop_push_enabled` set to `true` or `false` - Mobile activity and push behavior: **Everything**, **Mentions**, or **Nothing** - Rather than changing millions of database records directly, Slack used read-time interpretation to preserve backward compatibility and allow rollback. - Existing “Off” settings now behave as “Mentions” with push disabled. - A backfill populated the new desktop push preference based on users’ previous settings. - This preserves in-app awareness while allowing push interruptions to be controlled independently. ## Auto-Saving and Clearer Controls - The previous modal required users to press **Save**, which caused accidental abandoned changes. - The redesigned interface applies changes immediately through auto-save. - Users can independently choose what activity to see and how they want to receive it. - Shared React components replaced legacy mobile-specific UI code, improving consistency across platforms. - Users can now, for example, view all activity while receiving push notifications only for mentions. Slack’s approach demonstrates that reducing notification noise requires more than a visual redesign. Separating activity from delivery, simplifying preference states, and keeping clients synchronized gives users clearer and more reliable control over interruptions.

Read original(opens in new tab)
figma2 min readCurated summary

Forrester Analyzes The ROI Of Dev Mode | Figma Blog

Dev Mode is presented as a way to reduce friction between designers and developers, especially during handoff and implementation. A Forrester Total Economic Impact study found that it can increase developer output by 20–30%, save more than 90 minutes per developer each week, and generate significant financial benefits over three years. The central conclusion is that a shared, inspectable source of truth helps teams ship faster without sacrificing product quality. ## The Business Case for Dev Mode - Figma commissioned Forrester two years after Dev Mode launched. - Forrester interviewed four decision-makers and modeled a composite organization with 100–1,000 designers and developers. - The study identified inefficient handoffs and redundant work as major sources of lost time. - Its modeled benefits include: - 20–30% higher developer output - More than 90 minutes saved per developer each week - Approximately $10 million in developer-efficiency time savings over three years - Approximately $2 million in increased profit from faster time to market ## One Shared Source of Truth - Teams working in a shared space can collaborate continuously instead of waiting for a formal design handoff. - One organization reportedly moved from design completion to release in six to eight months, compared with an earlier process that could take two or three years. - A survey of 200 developers at another company found average savings of 98 minutes per week. - Developers can inspect design files directly to find: - Variables and specifications - Exact assets - Documentation - Code snippets - This reduces dependence on Slack messages, meetings, time-zone coordination, and manually maintained annotations. ## More Autonomous Developers - Dev Mode allows developers to resolve many implementation questions independently. - By seeing design intent and technical details directly in Figma, developers spend less time clarifying requirements with designers. - Reduced context switching and fewer back-and-forth conversations let developers focus more of their time on building products. - The broader benefit is not simply faster execution, but lower mental overhead and smoother collaboration between disciplines. The study supports adopting Dev Mode—or similar workflow improvements—when teams need to accelerate delivery while preserving design quality. Its strongest value comes from making design information immediately accessible and enabling designers and developers to collaborate before either side has finished their work.

Read original(opens in new tab)
figma4 min readCurated summary

How Razorpay Sharpened Developer Workflows | Figma Blog

Razorpay built Blade, a cross-platform design system, to create consistent, accessible experiences across its many products while accelerating collaboration between designers and developers. Its success depends not only on reusable components, but also on adoption metrics, advocacy, developer tooling, and tight integration between design and code. Tools such as Blade Coverage, RazorSharp, Dev Mode, Storybook links, and Figma variables have significantly reduced handoff friction and improved productivity. ## Blade’s Cross-Platform Structure - Razorpay has around 70 designers and 100 front-end developers. - Three designers and five engineers work full-time on Blade. - Blade supports desktop web, mobile web, iOS, and Android through a shared API and common properties. - This allows developers to transfer knowledge between platforms without rebuilding the system for each one. ## Problems Blade Solved - Before Blade, teams frequently hard-coded custom components and missed details such as: - Button states - Text-field error handling - Accessibility requirements - Repetitive, ad hoc development led to inconsistent user experiences across Razorpay’s products and domains. - Blade provides: - A shared design and development language - More consistent experiences across products - Built-in accessibility - Faster collaboration and shorter time to market - Designers and developers are treated as Blade’s customers, while end users benefit from the resulting consistency and reliability. ## Driving Design System Adoption - Razorpay uses several strategies to reduce adoption friction: - Securing leadership support for funding and organizational adoption - Tracking metrics such as onboarded projects and the percentage of apps using Blade components - Holding office hours and maintaining a support Slack channel - Creating an advocacy group of designers from consumer teams - Announcing new components through demo videos and status-page updates - These practices make Blade visible, supported, and easier for individual teams to adopt. ## Measuring Impact and Coverage - Blade’s north star is enabling teams to ship polished interfaces while the system handles common design and implementation work. - Its adoption targets are: - 70% Blade usage for new features - 50% usage for existing product surfaces - Razorpay discovered that adoption begins during design, not just development. - The Blade Coverage plugin shows designers where their designs diverge from Blade components, helping them: - Identify issues earlier - Predict launch timelines more accurately - Reduce handoff friction - Quantitative metrics are supplemented with surveys and focus groups measuring speed, documentation, training, collaboration, and user experience. - These findings contribute to an annual Net Promoter Score for the design system. ## RazorSharp and Improved Developer Handoffs - Before Dev Mode, developers had to inspect designs manually, identify components and properties, and reproduce them in code. - A developer created RazorSharp as a private plugin that automatically generated equivalent code for designs. - Initially, Figma required edit access to run plugins, forcing developers to clone shared files before using RazorSharp. - When Figma introduced Dev Mode, Razorpay adapted RazorSharp to work there in just two days. - Developers can now inspect designs and generate implementation code without editing or duplicating files. - Dev Mode also includes links to Storybook, allowing developers to move directly from a design component to its code playground. ## Variables and Design Tokens - Razorpay is transitioning its design tokens to Figma variables. - This makes token copying more seamless and supports developer-friendly naming such as `surface.text.subtle`. - Spacing tokens are now mapped to variables, addressing a frequent request from consuming teams. - Variables make light and dark modes easier to implement without duplicating entire designs. - Previously, multiple themes and modes caused Blade files to consume large amounts of memory and slowed designers down. - Consolidating Blade into a single theme with variables has substantially improved design performance. Razorpay’s approach shows that a design system is most effective when it is treated as an internal product: it needs leadership support, measurable adoption goals, user support, and tooling that connects design directly to implementation. Teams building similar systems should invest in both component quality and the workflows that make those components easy to discover and use.

Read original(opens in new tab)