Essential models for a UX project

2024-05-01 Wednesday (Updated on 2024-12-08 Sunday)

Introduction

Modeling in a UX context is about creating a structured understanding of the system, its users, and their interactions. The purpose is to approach system by identifying key parts and their dynamics, including different forms of interactions. Good UX demands understanding of individuals motivations and ambitions. At the same time it requires understanding of business goals and objectives. The purpose is to transform and map abstract ideas into concrete workable items. This enables teams (of any size) to structure the work so that it addresses user needs while meeting business objectives.

Which models to use?

There are many options for modeling. For example:

• Affinity Diagrams
• Customer/User Journey Maps
• Empathy Maps
• Functional requirements
• Information Architecture (IA) models
• Personas
• Prototypes
• Service Blueprints
• System Flow Diagrams
• Task flows
• Use Cases
• Value Proposition Canvases
• Wireframes
• Low/High fidelity mockups
• ...and many more

The question is: which models should one use when working on a UX project? First, it is crucial to understand the motivation of the project itself: what is needed, who needs it, and why it is needed. The need then drives which modeling approaches is to be pursued. Second, the model should provide value in proportion to the investment size. Far too often certain modeling approach is selected without considering the long-term impact. For instance, high-fidelity mock-ups are not necessarily the cost effective approach, but it is often pursued regardless. Reasons vary, but what is common in these cases is the lack of focus on the project needs and context.

The information provided by different models might overlap. In some cases one model can sufficiently answer to questions from different problem area.

Next chapters lists the needs I have found out to be the most common ones. For each need, the suggested modeling approach is listed.

Create shared understanding

In order to bridge the gap between designers, developers, and stakeholders focus on these:

• Who are the users? Personas
• What they need? Contextual Use Scenarios, User Stories
• How the system supports them? Use Cases
• How could it work? Prototypes

Manage complexity

In large projects with diverse teams and stakeholders, complexity is inevitable. Models break down complexity into manageable parts:

• Journeys provide a high-level flow.
• Contextual Use Scenarios describe user motivations and actions in context.
• Business Processes connect user needs to operational workflows and business needs.

Aim for user-centered solution

Aim to anchor design in user needs and real-world contexts. By understanding motivations, environments, and challenges, teams can design solutions that solve actual problems.

• Who are the users? Personas
• What they need? Contextual Use Scenarios, User Stories
• Prototypes helps to understand how the solution would work in practice.

Align design with business goals

• Business Goals guide priorities.
• Business Processes connect user needs to operational workflows and business needs. Metrics can become part of the measured part of the design.

Facilitate communication and collaboration

Make abstract concepts accessible to all team members, including non-designers.

• Journey Maps and Personas help stakeholders empathize with users.
• Contextual Use Scenarios and Use Cases provide actionable clarity for developers.
• Prototypes helps to understand how the solution would work in practice.

Facilitate low-level consistency and ensure progress

• Prototypes
• Use cases
• Interface designs
• Development tasks

Suggested models

These are the models I believe provide best value for the effort. Remember that each abstraction does not necessarily require extensive deliverables. The modeling itself is not bound to any pre-determined document format. This gives the designer a freedom to choose the right approach. The fundamental philosophy in thinking is that the outcome, i.e. the actualised product or solution, is the primary intent. Everything else is just a description of the intent and should be treated so.

Journey

• The overarching, end-to-end flow of activities and decisions users navigate – often unpredictably – while working toward a specific goal. It captures the context, emotions, and stages users experience.
• A journey spans multiple contextual use scenarios and may align with business processes and goals.
• Example: "Resolving Equipment Downtime" journey includes stages like detecting an issue, diagnosing the problem, executing repairs, and validating the solution.

Business Goal

• The overarching objective the organization aims to achieve, such as reducing costs, increasing efficiency, or improving user satisfaction.
• Guides the design of journeys by defining what success looks like.
• Example: "Minimize Mean Time to Repair"

Business Process

• A structured series of activities undertaken to achieve a business goal. It often maps closely to the stages of a journey.
• Journeys that align with business processes increases the likelyhood that designed solutions contribute to organizational success.
• Example: "Equipment Maintenance Process" includes steps like issue reporting, assigning tasks, and validating repairs.

Contextual Use Scenario

• Provide detailed context including user motivations, actions, and interaction flow.
• Does not define how to solve a problem.
• Aims to understand user’s journey and real-world context and environment.
• Help empathize with users and understand their needs.

Use Case

• Detailed, technical descriptions of system behavior.
• Describes primary actor, goal, preconditions, defines success and post-conditions.
• Helps to understand complex system behaviors and interactions.

Prototypes

• Tangible representations of the design concepts used to validate and refine solutions.
• Can vary from low-fidelity sketches or wireframes to high-fidelity interactive simulations.
• Aid in quickly testing ideas, gathering feedback, and iterating on solutions before full development.
• Helps visualize and explore potential solutions, ensuring alignment with user needs and business goals.

Summary

• Journey: High-level, end-to-end flow capturing user activities, goals, and unpredictability, often aligning with business processes.
• Business Goal: Organizational objective guiding design and success metrics.
• Business Process: Structured activities supporting business goals, closely linked to journeys.
• Contextual Use Scenario: Rich, context-driven user interactions focusing on motivations and needs without prescribing solutions.
• User Story: Simple, user-centric descriptions of desired features or functionality.
• Use Case: Detailed, technical descriptions of system behavior, focusing on interactions and success criteria.
• Prototypes: Tangible representations of design concepts to visualize, test, and refine ideas, ranging from low to high fidelity, supporting iterative user feedback and validation.

For comprehensive understanding, use journeys to map the overarching flow of user activities and decisions, align them with business goals and business processes, leverage contextual use scenarios to capture user needs and real-world context, employ user stories to describe features from the user's perspective, utilize use cases to define how the system should behave to fulfill those needs, and create prototypes to visualize, test, and iterate on potential solutions.

Step-by-step guide

Steps in this guide 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.

Reference: Models and attributes

This chapter gives an idea of what each object holds. For cross-reference and inspirational purposes the chapter includes models that are not in the "suggested models" chapter.

Journey

Business Goal

Business Process

Persona

Contextual Use Scenario

User Story

Use Case

How These Elements Work Together

• Journey

  • Maps the overarching, end-to-end flow of activities and decisions users take to achieve a goal. It aligns user needs with business processes, providing a high-level view of interactions and variability.

• Business Goal

  • Defines the organizational objective driving the project. It ensures that all design and development efforts contribute to measurable outcomes like efficiency, cost reduction, or user satisfaction.

• Business Process

  • Represents structured workflows that align with business goals. It breaks down operational steps, providing a clear connection between user journeys and organizational priorities.

• Persona

  • Represents the actors within the system, capturing their motivations, goals, and challenges. Personas ensure the design stays human-centered and relatable.

• Contextual Use Scenario

  • Provides detailed, context-rich narratives about how users interact with the system. It focuses on real-world settings, user needs, and problems without prescribing solutions.

• User Story

  • Offers a concise, user-focused description of a specific feature or functionality. It bridges the gap between high-level scenarios and technical use cases.

• Use Case

  • Details the technical tasks or system behaviors required to fulfill user goals. It includes preconditions, steps, dependencies, and expected outcomes, making it actionable for developers.

• Functionalities

  • Breaks down system capabilities tied to user stories, use cases, and scenarios. Functionalities define the specific features and tools the system must provide, grouped by higher-level entities or categories.

All-in-one example

• Journey Stage
  • Diagnostics, part of the broader journey "Resolving Equipment Downtime."
• Business Goal
  • Minimize equipment downtime, aiming to reduce Mean Time to Repair (MTTR) by 20%.
• Business Process
  • Includes stages like Issue Reporting, Task Assignment, Diagnostics, Repair, and Validation, aligning with the diagnostic journey.
• Persona
  • John Smith, a maintenance technician focused on quick and accurate diagnostics.
• Contextual Use Scenario
  • A maintenance technician (John) uses an IoT platform to diagnose and repair a conveyor belt motor. John uses a handheld diagnostic tool in a noisy factory to retrieve sensor data and determine the fault.
• User Story
  • "As a maintenance technician, I want to access real-time error codes from equipment sensors so that I can quickly diagnose and resolve malfunctions."
• Use Case
  • "Retrieve Diagnostic Error Codes" outlines John's task of accessing real-time equipment data.

Conclusion

This document outlines a structured approach to UX design, focusing on creating meaningful deliverables and aligning design efforts with business objectives, particularly in industrial contexts. By leveraging key concepts like Journeys, Business Goals, Processes, Personas, Contextual Use Scenarios, and Use Cases, the methodology ensures clarity, consistency, and practical application throughout the project lifecycle.

By using these models as a basis for structuring design it is possible to align and glue design and development activities together to support common goal, which is (or should be) to build usable solutions to real problems. Centering the design activity to Contextual Use Scenarios is not a design or development paradigm, rather it is a modelling technique and deliverable format.

The approach can be adapted in almost any kind of development setting. The only thing needed is to select models and start defining them. The best part is that generating the definitions is always worth it for the designer, even if rest of the development pipeline is following other methodologies and conventions. If the modeling is based on the need the investement is never going to waste.

The approach aims to focus on the all aspects of solution design and development, but only producing relevant artefacts. By minimising unncessary work the final deliverables are made cost-effectively. The results are very likely to be intuitive and financial risks of the project are kept in control. Even in unfortunate cases where the project misses the mark it is unlikely to produce deliverable waste. This is because the idea is to generate only content that is useful in the context.