Skip to content

Object Oriented UI Design

#ui #design

Rough notes on “Object Oriented UI Design”.

See also:

Part 1: The Object-Oriented UX Mindset

Core Principle: Traditional UI design often focuses on tasks (verbs). OO UI focuses on content objects (nouns). Users relate better to “things” they can manipulate rather than abstract processes.

1. The Paradigm Shift * Object-First: Instead of designing a “Checkout Flow” (task), you design the “Cart” and the “Order” (objects). * Consistency: OO principles align UI design with software engineering. If the UI treats a “Customer” as an object with specific attributes, the code likely does too, leading to smoother developer handoff.

2. The Three Levels of Design
You must progress through these levels in order to avoid costly rework:
1. Conceptual: What is the system? (The objects and their relationships).
2. Logical/Interaction: How does it work? (Navigation, state changes).
3. Physical: What does it look like? (Colors, typography, specific widgets).
Junior Tip: Never start at the Physical level. Define the objects first.

Part 2: Gathering & Structuring Requirements

Before drawing, you must define the problem space using specific artifacts that bridge the gap between business goals and user needs.

1. Use Cases vs. User Stories * User Stories (Agile): High-level narratives focusing on value (e.g., “As a user, I want to save a distinct address so I can ship gifts”). Good for scoping. * Use Cases: Detailed, step-by-step narratives describing the interaction between the user and the system. * Application: Use User Stories to define what to build; use Use Cases to analyze how the objects interact during those tasks.

2. Personas as Tools, Not Decorations * Don’t create personas just for demographics. Use them to filter requirements. * Validation: Ask, “Would Persona A actually use this feature in this context?” If the answer is no, the feature is low priority.

3. Managing Scope: Epics & Constraints * Epics: Large user stories that cannot be completed in one sprint. Break these down into smaller, specific stories. * Constraints: Identify these early.
* Business Constraints: Budget, deadline, regulatory compliance.
* Technical Constraints: Legacy database limitations, API speeds, platform restrictions (mobile vs. desktop).

4. The Prioritization Matrix
When deciding what to build first, map features on a 2x2 matrix: * X-Axis: User Value (Low to High) * Y-Axis: Effort/Complexity (Low to High) * Result: Start with High Value/Low Effort (Quick Wins). Avoid Low Value/High Effort.

Part 3: Building the Conceptual Model

This is the most critical step in OO UI. It bridges user stories and the visual interface.

1. Noun Extraction (The “Stories of Use” Technique)
Analyze your User Stories and Use Cases. Highlight the nouns. These are likely your UI Objects. * Example Story: “A Manager approves the Invoice for the Client.” * Identified Objects: Manager (User Role), Invoice, Client.

2. Defining the Objects (The Conceptual Model)
For every object identified, define: * Attributes (Data): What does the user need to know about this object? (e.g., Invoice Object $\rightarrow$ Date, Amount, Status). * Actions (Operations): What can the user do to this object? (e.g., Invoice Object $\rightarrow$ Create, Edit, Send, Delete). * Relationships: How do objects relate? (e.g., A Client has many Invoices).

3. View Derivation
Once objects are defined, the UI views define themselves. You need a “List View” (collection of objects) and a “Detail View” (single object with attributes and actions).

Part 4: Visualization & Execution

Moving from abstract models to tangible screens.

1. Sketching & Prototyping * Sketching: Use pen and paper to explore ideas rapidly. Do not focus on aesthetics. * Wireframing: Low-fidelity digital structures. Focus on placement of the “Objects” and “Actions” defined in the previous phase. * Prototyping: Adding interactivity to validate the logical flow.

2. Design Maps: The Handoff Artifact
A “Design Map” is the translation layer between UX and Engineering. It ensures your design is implemented correctly. It documents the “Who, What, and How”: * Who: The Object involved (e.g., “Product Card”). * What: The data elements required (e.g., Image URL, Price INT, Title String). * How: The methods/functions required (e.g., addToCart(), openDetailView()).

3. Development-Ready Guidance
Instead of just handing over a Figma file, hand over the Design Map. * Benefit: Developers don’t have to guess how the UI functions. They see a direct mapping between the UI element and their code classes/databases.

Summary Checklist for Junior Designers

  1. Listen: Gather requirements via User Stories and Constraints.
  2. Extract: Identify the Nouns (Objects) from the stories.
  3. Model: Define what data (Attributes) and capabilities (Actions) each Object has.
  4. Prioritize: Use a Matrix to decide which Objects/Features are built first.
  5. Map: Create a Design Map to explain the Objects to developers.
  6. Sketch: Finally, draw the UI based on the defined structure.

Page last modified: 2025-11-26 13:50:23