How UI Designers Use iPhone Notes to Document Decisions, Patterns, and Accessibility Rationale

The UI Designer's Documentation Problem

UI design produces visible artifacts — screens, components, prototypes. It rarely produces equally visible decision artifacts. Why a particular interaction pattern was chosen. What the accessibility rationale was for a color combination. Why the spacing system uses this specific scale. What was tried before the current approach and why it was rejected.

That reasoning lives in design files, review comments, meeting notes, Slack threads, and memory — scattered and typically unretrievable when it matters most. When a new engineer joins and asks why the modal works this way. When a stakeholder questions a decision made eight months ago. When you're designing a new component and need to understand what constraints the existing system has.

The decisions themselves are in Figma. The reasoning behind them is almost nowhere.

What UI Designers Track Across Projects

Design decision rationale: Why a specific component was designed the way it was. What user need it serves. What alternatives were considered. What the trade-offs are. This documentation is what makes a design system defensible and evolvable.

Accessibility decisions: WCAG compliance notes for specific decisions. Color contrast rationale. Keyboard navigation patterns. Screen reader behavior. These decisions require explicit documentation to maintain compliance through future iterations.

Design token and system decisions: Why specific values were chosen for the spacing, type, and color scales. What principles the system expresses. What the constraints are on extending it.

Component pattern observations: Interactions that consistently work well or fail across user testing. Patterns that feel native to specific platforms. Anti-patterns worth avoiding.

Feedback integration: Design critique notes — what was challenged, what changed as a result, what the reasoning was for defending certain decisions.

Cross-team coordination: Engineering constraints that shaped design decisions. Product requirements that constrained the solution space. Business context that informed the direction.

Nemos as Your Design Reasoning Layer

Decision documentation in real time: The moment a significant design decision is made — in a review, in a workshop, during a problem-solving session — it gets captured in Nemos with the reasoning. Not a full write-up; a note with enough context to reconstruct the thinking.

Accessibility reference library: Notes on WCAG guidelines interpreted for your specific design system. What the compliance standard means in practice for your component library. Searchable during design rather than requiring re-research.

Cross-platform pattern notes: Observations about how interaction patterns differ across iOS, Android, and web — and what that means for your multi-platform design system. Pattern decisions with their platform rationale.

User feedback synthesis: Usability test observations tagged by component type. Patterns across multiple test sessions that reveal genuine usability problems. This evidence base makes design decisions defensible.

What UI Designers Capture in Nemos

• Design decision notes with rationale and alternatives considered
• Accessibility compliance notes per component or pattern
• Design token rationale — why these specific values
• Component pattern observations from usability testing
• Design critique notes — what changed and why
• Engineering constraint notes that shaped design decisions
• Cross-platform pattern differences and their implications
• Design system evolution decisions — what changed and what drove the change
• Competitive and reference app observations
• Research synthesis from user interviews and tests
• Handoff notes for engineering implementation
• Conference and workshop insights worth applying

The iPhone Advantage for Design Thinking

Design thinking happens during design reviews, user testing sessions, stakeholder presentations, and commutes — not only during screen work.

A usability test session generates observations that need capturing immediately. A design review comment that points at something important needs noting before the meeting ends. A pattern noticed in a competitor app during a casual browse needs capturing in the moment.

iPhone enables capture across all these contexts. The observation during a user test, the insight during transit — all preserved for the design decision they'll eventually inform.

Setting Up Nemos for UI Design

Core tags: - `#decision` — design decision rationale - `#accessibility` — compliance notes and patterns - `#system` — design token and system decisions - `#pattern` — component and interaction patterns - `#feedback` — critique and review notes - `#research` — user testing and interview observations - `#reference` — competitor and inspiration analysis

Workflow: Capture design decisions immediately as they're made. Note accessibility rationale alongside design decisions. Synthesis usability test observations same day. Update system notes when the design system evolves.

FAQ

How do UI designers use Nemos differently from Figma's built-in comment system? Figma comments are attached to specific designs. Nemos holds the cross-project reasoning, the design principles, the accessibility reference library, and the pattern observations that apply across multiple products and projects.

Can Nemos help with design system documentation? As a drafting and reasoning layer. Decision notes in Nemos become the input for formal design system documentation. The reasoning is captured in real time; the documentation is written from those notes.

How do I use Nemos to document accessibility decisions? Create per-component accessibility notes: what WCAG criterion applies, what the design decision was, what the rationale is, what was tested. Over time, this builds a component-level accessibility record.

What's the best way to capture usability test observations? During or immediately after a session: what the participant did, where they struggled, what surprised you, what confirmed your hypothesis. Tag by component or flow being tested. Pattern recognition across multiple sessions reveals genuine usability issues.

How do UI designers use design critique notes? After reviews: what was challenged, what changed and why, what you defended and the reasoning. This creates a decision history that makes future design work more coherent. When someone asks "why does it work this way" six months later, the critique note has the answer.

Can Nemos help with cross-functional design work involving engineering and product? Engineering constraint notes and product requirement notes alongside design rationale make the cross-functional context visible. When an engineer asks why a pattern works a particular way, the engineering constraint that shaped it is in the note.

How do senior designers use Nemos to develop junior designers on their teams? Notes on design principles, explained-by-example pattern observations, critique feedback with reasoning. These can be shared as reference material that communicates the reasoning behind design standards.

Related Reading

• /blog/ux-researcher-notes-iphone — user research workflow
• /blog/graphic-designer-notes-iphone — visual design workflow
• /blog/brand-designer-notes-iphone — brand system development
• /blog/product-designer-notes-iphone — product design workflow

Sources

• UI design workflow and decision documentation research
• WCAG accessibility guidelines and compliance documentation
• Design system governance best practices