How UI Design Codification Bridges Designers and Developers with the Unflow DSL

UI design codification converts UI designs and interactions into a domain‑specific language (DSL) that can be version‑controlled and processed programmatically. The DSL enables automatic generation of UI code from requirements and provides a feedback loop between design and implementation.

Motivation for UI Design Codification

User interaction documentation : Record every UI interaction in a structured, searchable format.

Tool‑agnostic specifications : Describe UI independently of Sketch, Figma, or other design tools.

Bidirectional feedback : Detect mismatches between design and code and surface them instantly for correction.

Glue between requirements and code : Use the DSL as a bridge that translates high‑level requirements into concrete UI specifications and then into executable code.

Key Constraints

Effective codification requires vector‑programmable assets (e.g., SVG, Sketch files) and UI elements that can be parsed, validated, and matched against generated code. The DSL must also abstract user actions, map them to requirements, and link them to implementation code.

Core Elements of a Codification Workflow

Code‑feedback design

Select a design tool and a parser that can emit the DSL.

Parse the generated DSL and compare it with the existing UI code to find discrepancies.

Bind design and code so that inconsistencies are highlighted and can be automatically resolved.

Support for incremental changes

Design artifacts are stored alongside source code in a version‑control system, enabling history tracking.

Artifacts are programmable: requirements can generate design fragments, and code can validate existing designs.

Interaction abstraction

Describe user actions (e.g., clicks, input).

Associate each action with a requirement identifier.

Map actions to concrete implementation code (functions, API calls, UI updates).

Unflow DSL Overview

Unflow is an experimental DSL written in Rust that implements three operational modes:

SEE‑DO‑REACT : a three‑stage interaction model analogous to BDD’s Given‑When‑Then.

Atomic design decomposition : library → component → organism → template → page.

Flex‑based layout system combined with concepts from Apple Auto Layout.

Mode 1 – SEE‑DO‑REACT

This pattern separates what the user sees, what the user does, and the system’s reaction. An example login flow:

flow 登录 {
  SEE 首页
  DO 输入密码
  DO "登录".Button
  REACT 成功: 展示 "Login Success".Toast with ANIMATE(bounce)
  REACT 失败: 展示 "Login Failure".Dialog
}

In the success branch a toast is shown and execution continues; in the failure branch a dialog is displayed, allowing further handling.

Mode 2 – Atomic Design & Element Definition

Following Brad Frost’s methodology, Unflow classifies UI elements as:

Library : primitive UI building blocks.

Component : molecules and organisms.

Template : page‑level layout skeletons.

Page : final screens.

Example color library definition:

library Color {
  Primary   { label = "Primary";   value = "#E53935" }
  Secondary { label = "Blue";      value = "#1E88E5" }
  Third     { label = "Third";     value = "#000000" }
}

These definitions can be transformed into Sketch specifications and SCSS variables via a Node.js Sketch constructor.

Mode 3 – Flex Layout System

Unflow adopts a Flex‑style layout inspired by Flutter, Druid, web Flexbox, and Android FlexboxLayout, enriched with Auto Layout visual‑format syntax:

H:|[view1(==view2)]-10-[view2]|
V:|[view1,view2]|

The syntax is table‑like, making it easy for developers to maintain while supporting parameter passing on components.

Repository

The early source code and documentation are available at:

https://github.com/inherd/unflow

References

Basecamp article “A shorthand for designing UI flows”.

https://github.com/IjzerenHein/autolayout.js

https://github.com/dorostanian/sushi

Understanding Auto Layout (various public resources).