Skip to main content
Meytal Dahan
Back to insights

Why a Design System Is Infrastructure, Not Decoration

When I design enterprise mobile apps for frontline employees, I treat the Design System as engineering infrastructure, not a style guide that sits in a Figma file. For an R&D leader, the value is concrete: a shared component library with versioned tokens means your team stops re-litigating button states, touch-target sizes, and offline-error patterns on every screen. That consistency is what makes a 'mandated' app feel trustworthy enough that field employees actually open it. I architect the system around the realities of B2E mobile: large tap targets for gloved hands, components that degrade gracefully in Offline Mode, and states for slow or failed syncs baked in as first-class variants rather than afterthoughts. I also push for tokens that map cleanly to platform primitives, so the system survives an OS update without a rewrite. The payoff your team feels is velocity: new field workflows get composed from trusted parts instead of hand-built, QA surface shrinks, and accessibility (WCAG contrast, dynamic type) is enforced by default. A Design System done right is a contract between design and engineering that lowers the long-term cost of every screen you ship.

Get in touch

Have a project in mind?

Drop a line. Meytalyav@gmail.com

Related articles

Enterprise Mobile
Engineering LeadersIndustry-Specific Accessibility

Accessibility in the Field Means Gloves, Glare, and One Free Hand

WCAG is the floor for frontline apps, not the ceiling. The real accessibility test is the field: gloves that defeat small tap targets, sunlight that erases low-contrast text, one free hand on a noisy loading dock. Situational and permanent disability collapse into the same requirements out there. Big targets, glare-proof contrast, camera/QR over forms, a single confirming tap. Bonus for R&D: fewer input errors at the source means cleaner data into payroll. Design for the glove and the glare — you'll clear WCAG along the way.

Read
Enterprise Mobile
CEOsSpecific Feature ROI

The ROI Hides in the Feature Nobody Mandated

CEOs often ask me to justify a B2E feature in isolation. Wrong frame. The mandated features get compliance, not adoption. The feature that gives the field worker something back — offline schedules, a camera report that kills minutes of typing, a payslip without a call to HR — is what makes them open the app at all. And once they open it, your mandated workflows finally get used. Don't price a feature by its own ROI. Price the adoption it unlocks across the whole product.

Read
Enterprise Mobile
Engineering Leaders

B2E Apps With Complex Integrations: How Do You Design Mobile-First So It Doesn't Break on Legacy Systems?

Engineering leaders on B2E apps: the challenge isn't the build – it's the integrations with legacy systems. In our enterprise mobile app project, we designed "Cached Display" for latency situations and full Offline Mode for field workers. Design + technical reality = an app that works in production.

Read
Meytal Dahan

About

Making complicated into easy for users.

Senior product designer with a decade of work across complex systems - financial risk platforms, legal operations, healthcare apps, manufacturing tooling and insurance portals. The common thread is depth: products where the data is rich, the users are expert, and the interface has to disappear into the work.