UX Zen Studio Archives

Published Docs

Hey there,

I am publishing the general workflow which has enhanced my working as a UX Lead over the past years and hope it helps your team gain clarity in the chaotic jungle we call UI/UX Design there are more parts to it elaborating on Design Documentation, Training requisites, and CX Analytics which also create your designer’s report card.

Use it to your benefit. This is nothing not already known but and updated consolidation and my personal winners in creating a reliable and sustainable process pipeline and hope it helps you as well.

Cheers!

[Assumption:

1. SaaS B2B industry where we work with reports as deliverables across multiple portfolios. Same can be replaced with phase launches/milestones, seasonal products, etc.
2. Using only Figma’s Pro version capabilities. ]

Technical Documentation:

UX Zen Studio Design Operations & Workflows SOP

Design Standard Operating Procedure, a guide for designers to enable collaboration and fluid work efficiency. Scaling UX Operations with a Systems-Oriented Framework for Design.

By: Utkarsh Saxena | www.uxzen.studio

01. Project Initiation: Research, Conceptualization, and Scope

• [Situation]: Establish a structured approach to design documentation using a templatized FigJam file for all future projects. This includes distinct phases: Discovery Phase (Empathize, Define), Design Phase (Research, Ideate, Prototype), and Deploy Phase (Test).
• [Success Criteria]: The Research and Conceptualization phase is strictly isolated to understanding user context and defining the business problem. Tactical design execution is completely prohibited during this phase. Branding scopes are explicitly limited to collateral enhancements, omitting full identity creation.
• [Importance]: Enforcing strict methodological boundaries guarantees predictable resource allocation and prevents scope creep, ensuring pipeline optimization for client deliverables.
• [Ideal Outcome]: The design team transitions into tactical execution only after securing complete stakeholder alignment on validated user problems and precise deliverable expectations. Clearly articulated design decisions and rationale serve as reference material for future similar projects.
• [Benefit]:
  • Best Result: High process compliance yields accurate project timelines and precise deliverables, supporting designers in achieving greater quality.
  • Without this: Unchecked tactical execution during discovery leads to misaligned architectural decisions, severe delivery delays, and crucial information getting lost in time.

02. File Handling & Organization Structure

• [Situation]: Unstructured file management and chaotic canvas layouts stall delivery, disrupt stakeholder alignment, and increase cognitive load when locating project assets.
• [Success Criteria]:
  • Figma Projects: Used exclusively as the top-level container to designate the overarching Portfolio name.
    • Files: Must be structured strictly using the [Project Name] - [Report Name] format. Set files and folder structuring rules for different repositories (other repositories and Figma).
      • Pages: Utilized for housing specific milestones, including version control (v1.1, v1.2), the "Read Me" block, and dedicated Archive pages.
        • Sections: Deployed exclusively within the canvas for segregating complex user flows and applying semantic color-coding to distinct logic branches.
  • Shared Cloud Repository (Non-Figma Assets): External repositories must mirror this hierarchy (Portfolios 📁 > Projects 📁 > Reporting Units 📁) utilizing deep folder nesting to guarantee digital-to-physical scalability.
• [Importance]: A rigid, universally adopted hierarchy eradicates friction for cross-functional teams, ensuring immediate asset retrieval and optimizing the handoff pipeline.
• [Ideal Outcome]: Stakeholders, core contributors, and cross-functional partners navigate complex project architectures intuitively without requiring navigational guidance, ensuring better file management across projects.
• [Benefit]:
  • Best Result: Faster iterations and highly structured hand-offs.
  • Without this: Critical supplementary assets become orphaned or detached from their core design counterparts, causing severe deployment bottlenecks.

Best Practices: File Handling

• Library Isolation: Maintain a completely separate file for the master style guide and design library. Edit access must be strictly restricted to prevent unauthorized appendages.
• Page Categorization via Separators: Deploy blank, un-clickable separator pages to enforce a strict three-tier page architecture:
  • -- System --- (Contains the Read Me / Summary page, Research page)
  • -- Work Area --- (Contains active execution pages, "Ready for Dev", and variations)
  • -- Archive --- (Contains Playground/graveyard, and past versions)
• Progressive Canvas Layout: When organizing frames, anchor the main screens at the far left of the canvas. Progressively move to the right for variations, sub-screens, and prototype flows. Begin the subsequent user flow directly below the first, restarting alignment from the left axis.
• In-Canvas Milestone Tracking: Construct high-level Gantt charts or timeline views directly within the canvas to ensure stakeholder alignment on project phases without external documentation switching.
• WIP Markers: Deploy clear visual status indicators (e.g., color-coded file thumbnails or label components) to instantly communicate the Work In Progress status at the browser level.

03. Nomenclature Conventions

• [Situation]: Abstract file names, default layer outputs (e.g., "Frame 1"), and mixing visual structures with raw CSS syntax inevitably lead to workflow bottlenecks, rendering assets unsearchable and causing costly deployment errors. The goal is to maintain a highly readable design environment for designers while ensuring a seamless, automated, one-to-one code mapping for engineers.
• [Success Criteria]:
  • Tree Structures & Asset Organization (The Forward Slash /) The forward slash (/) is strictly a navigational sorting tool, not a CSS naming convention. It is used exclusively to build intuitive folder trees within Figma’s Asset Panel, Variable Collections, and Style Pickers.
    • Primary Use Cases: Grouping Components (e.g., Button / Primary), Variables (e.g., Color / Background / Base), and Text Styles (e.g., Heading / H1 / Bold).
    • Internal Flags: Prefix structural, temporary, or non-exportable frames with an underscore (_) to explicitly instruct compilers, linters, and developers to ignore them (e.g., _SlotArea, _Spacer).
    • Avoid Deep Specificity: Keep Auto-Layout container names simple. Over-naming every nested wrapper creates layers panel clutter and cognitive overload.
    • Standardize Grammar and Abbreviations: Use standardized abbreviations (e.g., btn for button). Ensure text is error-free, utilizes the Oxford comma, and uses active verbs for UI actions.
    • Systemic Token Taxonomies (CTI Implementation): When building variable collections, mandate the Category/Variant structure. Define color scales via token mapping (e.g., Color / Primary / 500) and text styles utilizing a structured Type, Size, and Weight format (e.g., Heading / H1 / Bold). This taxonomy acts as the foundation for multi-mode theming.
  • Dynamic Code Syntax (The Developer Bridge) Instead of forcing designers to name visible layers with rigid CSS conventions (which breaks readability), teams must utilize Code Syntax within Figma's variable and component properties.
    • What it is: Code Syntax allows a designer to attach hidden, platform-specific metadata (e.g., var(--bg-primary) for Web, or bgPrimary for iOS) to a human-readable Figma variable (e.g., Background / Primary).
    • Why use it: It entirely abstracts the "kebab-case vs. camelCase" debate. Developers inspecting the file via Dev Mode see the exact code string required for their environment, while designers maintain a clean visual workspace.
    • Autonomous Configuration via Plugins: Designers should not manually type these syntaxes one by one. Mandate the use of design token plugins (like Token Studio) or custom linting scripts to autonomously generate and attach Code Syntax across the entire library based on predefined rulesets.
  • Layer & Frame Naming Practices (The Canvas) Canvas nomenclature is purely about visual hierarchy, debugging, and auto-layout management. These names do not typically translate to final CSS, but they must remain impeccably organized.
    • Prohibit Default Names: "Frame 1", "Rectangle 42", and "Group 7" are strictly forbidden. Use lightweight, semantic descriptors (e.g., Container, List, Hero Image).
    • Internal Flags: Prefix structural, temporary, or non-exportable frames with an underscore (_) to explicitly instruct compilers, linters, and developers to ignore them (e.g., _SlotArea, _Spacer).
    • Avoid Deep Specificity: Keep Auto-Layout container names simple. Over-naming every nested wrapper creates layers panel clutter and cognitive overload.
  • Standardized File & Page Architecture Structure macro-level files to prevent version control chaos and guide consumers through the file's lifecycle.
    • Architectural File Formatting: Implement a strict delimited string format for file titles: [Project/Feature]_[Version]_[Date] (e.g., Checkout_Revamp_v1_2024-04-03).
    • Mandatory Page Sequence: Every project file must contain:
      1. Cover: Visual thumbnail and status.
      2. Research: Flows and wireframes.
      3. Final Designs: Active visual sandbox.
      4. Dev Handoff: Locked, annotated screens.
      5. Archive: Deprecated explorations.
    • Artifact Security: Password-protect interactive mockups and ensure all exported support files (SVGs, MP4s) share the parent file's exact naming convention.
  • Content Grammar & Data Formatting
    • UI Copywriting: Ensure all interface text is error-free, utilizes the Oxford comma for lists, and uses active, leading verbs for UI actions (e.g., "Save Changes" instead of "Changes Saving").
    • Data Integrity: Format dates in mockups accurately (e.g., August 29, 2026) avoiding ordinal numbers (1st, 2nd). Use commas for numerical values over 1,000 to ensure realistic data representation.
  • Static Assets & Iconography: Icons and static images represent a massive source of digital clutter and import errors.
    • Size Suffixing: Name icons categorically with their bounding box size appended as a numerical suffix (e.g., icon/Search_20). Images must follow a [Type]/[Description]_[Size] format.
    • Resolution Switching: When configuring images for responsive layouts, asset nomenclature must support resolution switching techniques, accommodating different compositions based on screen sizes (e.g., naming to leverage srcset logic).
• [Importance]: Abstracting code conventions into Code Syntax while keeping layer and tree nomenclature human-readable eliminates translation friction and prevents token drift. It empowers automated CI/CD pipelines without severely taxing the design team's cognitive load.
• [Ideal Outcome]: Absolute operational transparency. Designers navigate beautiful, human-readable libraries, while developer tools extract flawless, environment-specific code strings natively from the file's metadata.
• [Benefit]:

04. Grid & Spacing Systems

• [Situation]: Haphazard spacing logic fractures visual consistency and exponentially increases development complexity and CSS authoring time.
• [Success Criteria]: Layout foundations must utilize one of three authorized systems consistently per project:
• [Importance]: Mandating mathematical layout foundations guarantees systemic visual harmony and predictable component scaling across all active environments.
• [Ideal Outcome]: Accelerated turnaround time for engineering teams receiving perfectly standardized, scalable UI builds.
• [Benefit]:

05. Design Systems & Tiered Governance

• [Situation]: Hardcoding values introduces technical debt, while requiring unanimous external approval for every master component update creates severe administrative bottlenecks that stall turnaround time.
• [Success Criteria]:
• [Importance]: Centralizing foundational design control while allowing controlled flexibility at the component level ensures rigorous process compliance without sacrificing pipeline velocity.
• [Ideal Outcome]: A mature Center of Excellence that elevates product quality through robust, self-correcting component libraries.
• [Benefit]:

06. Versions & Iteration Control

• [Situation]: Unchecked, continuous canvases destroy historical project records. Dragging outdated concepts back into active files breaks current token architectures.
• [Success Criteria]:
• [Importance]: Establishing explicit milestones secures against accidental overwrites and ensures clean architectural rollbacks.
• [Ideal Outcome]: Predictable file states enabling rapid resurrection of previously discarded concepts without introducing technical debt.
• [Benefit]:

07. Access Governance & Automated Dev Handoff

• [Situation]: Unstructured handoffs, missing component states, and unrestricted file access create a chaotic transition environment. This forces engineers to guess design intent, leading to endless revision loops and vulnerable master files.
• [Success Criteria]:
• [Importance]: Fusing strict access governance with a designer-centric QA ritual ensures that files are structurally perfect and logically clear before they reach engineering, optimizing the handoff pipeline without turning designers into developers.
• [Ideal Outcome]: A secure, frictionless deployment pipeline where designers confidently hand off files that are easily ingested by development, completely independent of synchronous meetings.