Essential models for a UX project

2024-05-01 Wednesday (Updated on 2026-04-24 Friday)

Modeling in UX creates a structured understanding of the system, its users, and their interactions. The goal is to transform abstract ideas into concrete, workable items — enabling teams to address user needs while meeting business objectives.

Models and attributes

Affinity Diagrams

Organize qualitative research data — observations, quotes, notes — into themed clusters. The clustering process itself surfaces patterns and insights that structured methods might miss.

Business Goal

The overarching objective the organization aims to achieve. Guides design priorities and defines what success looks like.

Business Process

A structured series of activities undertaken to achieve a business goal. Aligns user journeys with operational workflows.

Contextual Use Scenario

Provide detailed context including user motivations, actions, and interaction flow. Focus on understanding the user's real-world context — not on how to solve the problem.

Customer/User Journey Maps

The overarching, end-to-end flow of activities and decisions users navigate while working toward a goal. Captures context, emotions, and stages — including where things go wrong.

Empathy Maps

A structured view of what a specific user says, thinks, does, and feels. Useful for building shared team understanding of user motivations before or alongside persona creation.

Functional Requirements

Explicit descriptions of what the system must do. Derived from use cases and scenarios — not invented in isolation.

Information Architecture (IA) Models

Defines the structure, organization, and navigation of content within a system. The blueprint for how users find and access information.

Personas

Represent key actors in the system — their roles, motivations, and challenges. Keep design decisions grounded in real user needs rather than assumptions.

Prototypes

Tangible representations of design concepts used to validate ideas before development. Fidelity should match the question being tested — not the effort available.

Proof of Concept

A minimal implementation to validate that a technical or design approach is feasible. Focuses on one critical risk or assumption — not on completeness or polish.

Service Blueprints

Extend journey maps by exposing the backstage processes, systems, and people that support the user-facing experience. Useful for identifying operational gaps and dependencies.

System Flow Diagrams

Visual representations of how a system transitions between states or processes in response to inputs and decisions. Useful for understanding complex logic and edge cases.

Task Flows

Step-by-step sequences of actions a user performs to complete a specific task. More granular than journey maps — focused on a single goal within a specific UI context.

Use Cases

Detailed, technical descriptions of how a system behaves in response to user interactions. Define preconditions, steps, and expected outcomes — actionable for developers.

User Story

A concise, user-focused description of a specific feature or functionality. Bridges the gap between high-level scenarios and technical use cases.

User Story Map

A 2D visualization that organizes user stories across the product flow (horizontal axis) and priority or release (vertical axis). Helps teams see the full product scope and plan incremental delivery.

Value Proposition Canvases

Maps what the product offers against what users actually need. Identifies fit between features and user jobs, pains, and gains.

Wireframes

Low-fidelity layouts that define the structure and placement of UI elements without visual design. Focus on layout, hierarchy, and functionality — not aesthetics.

Low/High Fidelity Mockups

Visual representations of the final design. Low-fidelity focuses on layout and flow; high-fidelity includes visual design, typography, and interaction states.

Process

Steps can be followed in any order, though it makes sense to go from high abstraction level to lowest. Steps can also be omitted. Each of the activity provides value even if other activities cannot be executed for reason or another. The idea is to outline an activity space that would, if completed, provide solid foundation for succesful project.

Step 1: Create Personas

• Purpose:
  • Personas capture essential actors affected by the solution and provide a human-centered foundation for the design process.
• Tips:
  • Create 1–5 personas that represent the primary users or stakeholders.
  • Personas should reflect motivations and roles, not generic "users of a system."

Step 2: Define Business Goals and Processes

• Business Goal:
  • What is the primary organizational objective?
    Example: Minimize equipment downtime.
• Business Process:
  • What structured activities support the goal?
    Example: Reporting → Assignment → Diagnosis → Repair → Validation.

Step 3: Identify the Journey

• Name:
  • Example: Resolving Equipment Downtime.
• Stages:
  • Break the journey into high-level stages.
    Example: Detection → Reporting → Diagnostics → Execution → Validation.
• Randomness and Variability:
  • Identify where the journey might deviate.
    Example: Technician pauses diagnostics to contact an expert.

Step 4: Define Contextual Use Scenarios

• Purpose
  • Use scenarios contextualize user activities in relation to system interactions and their surrounding environment. They answer Who, What, Why, and How regarding the system's usage.
• Key Components
  • Id: Assign a unique number for reference.
  • Group: Categorize scenarios once patterns emerge.
  • Persona: Link the scenario to a specific persona.
  • Description: Provide a narrative summary of the scenario.
  • User Goal: Define what the user seeks to achieve.
  • Scenario Statement: Use the format: "{Persona} does {what} {where} in order to {why}. As a result, {something happens}."
  • Design Hypothesis: Early thoughts on UI or interaction design. Stay high-level and avoid detailed specifics.
• Additional Considerations
  • Scenarios aim to balance scope—neither too broad nor too fragmented.
  • Identify the core problem, user needs, and business relevance for each scenario.

Step 5: Outline Use Cases

• Name the Use Case
  • Example: Retrieve diagnostic error codes.
• Objective
  • What is the task or interaction?
    Example: Query IoT sensors for error codes.
• Preconditions
  • What needs to be true or available before the use case?
    Example: Equipment must be powered on, and sensors must be functional.
• Steps
  • Sequential actions required to complete the task.
    Example: 1. Open diagnostic tool; 2. Query sensor logs.
• Outcome
  • Expected result of the interaction.
    Example: Error codes retrieved and logged.
• Dependencies
  • Systems, tools, or data needed for the task.

Step 6: Functionalities and Modeling

• Entity Identification
  • Use contextual use scenarios to identify key entities, such as "customer," "product," or "order." These entities represent user-centric abstractions, not necessarily technical database models. Tip: see https://www.ooux.com/what-is-ooux for more help on this.
• Group Functionalities
  • Organize functionalities by entity. For instance:
    • Entity: "Product"
    • Functionality: "Add to cart," "Update inventory," etc.
• Describe Interaction
  • Provide written descriptions or visual diagrams of functionalities and interactions.

Step 7: User Interface Metadata

• Gather Design Deliverables
  • Include or link to the following:
    • Sitemap
    • Component libraries or design systems
    • Accessibility guidelines

Step 8: Work Breakdown Structure

• Structure by Scenario
  • Split functionalities into manageable chunks tied to contextual use scenarios.
• Map to Development Activities
  • Align features or functionalities with work-tracking systems, such as tickets or tasks.
• Estimate Time and Budget
  • Use this structure for project planning and resource allocation.

Step 9: Prototyping and information architecture

• Select the initial approach (can be adjusted later on)
  • Low-Fidelity: Sketches or wireframes used to convey broad concepts.
  • High-Fidelity: Interactive models that closely resemble the final product, used to validate user experience and detailed interactions.
• Design and iterate:
  • High-level information hierarchy
  • Use prototypes to quickly iterate and refine based on user and stakeholder feedback.