Object-Oriented UX (OOUX) with Sophia Prater

Introduction to Object-Oriented UX (OOUX)

• Object-Oriented UX (OOUX) is a framework that helps digital product designers create naturally intuitive user experiences by identifying the entities that components house, rather than just the components themselves (2m22s).
• The concept of OOUX started with modular design and responsive design, and the goal is to create designs that use the least effective dose of moving parts to minimize the likelihood of breaking (1m41s).
• Sophia Prater, the chief evangelist for OOUX, allegedly coined the term by combining object-oriented and UX, and her work on OOUX began with her experience designing for CNN's election results (1m20s).
• Prater's approach to OOUX involves identifying the entities within a system, such as races, states, and candidates, and keeping them consistent across different devices and platforms to simplify design and QA (2m36s).
• The psychology behind OOUX is based on how people think and identify objects in their environment, and it benefits from understanding how the brain identifies objects in a given space, even for individuals with visual disabilities (3m30s).
• Prater's background and experience in design, combined with her understanding of the psychology behind OOUX, have led to the development of the OOUX framework, which aims to improve communication among designers, product owners, engineers, and architects (1m8s).
• The OOUX framework can help improve communication by providing a common language and understanding of the entities and components within a system, allowing teams to work more effectively together (1m10s).
• The realization that developers think in data, databases, and how data is passed between them led to the understanding that showing static screens and flows may not be the most efficient way to work, and that working together on a data model from a user-centered perspective could be more effective (3m54s).
• Traditional user experience (UX) design is often focused on flows and verbs, whereas object-oriented UX (OOUX) is focused on nouns and objects, which is more aligned with how developers think (4m45s).
• The difference between OOUX and traditional UX design lies in their approach, with OOUX being noun-focused and traditional UX being verb-focused (5m21s).
• The reason traditional UX design is verb-focused is due to its origins in the e-commerce revolution, where the goal was to get users from point A to point B and complete a transaction, with metrics focused on conversions (5m29s).
• Traditional UX design evolved from information architecture, which was about organizing information, but this was often taxonomy-based and focused on organizing pages rather than different types of content objects (6m1s).

OOUX Framework and Communication

• OOUX involves defining the nouns or objects in a system first, and then figuring out the verbs or actions that users want to perform on those objects, making it easier to design the system (6m39s).
• The key to OOUX is figuring out the things that users care about and expect to be in the system, and then building databases and APIs around those objects and their structure (6m51s).
• OOUX involves iterating back and forth between defining the nouns and figuring out the verbs, rather than just focusing on flows and verbs (7m8s).
• Object-Oriented UX (OOUX) is a design approach that incorporates principles from object-oriented design, where classes have properties and behaviors, into the design aspect of user experience, not just architecture design (7m13s).
• In OOUX, the focus is on user-facing objects, attributes, and relationships, and how users navigate through them, with the goal of creating a shared understanding between designers and developers (8m14s).
• The terminology used in OOUX includes "objects" (similar to classes), "instances" (actual lines in a database), and "attributes" (user-facing properties) (8m26s).
• OOUX is similar to domain-driven design and involves working with developers to identify objects, relationships, calls to actions, and attributes (ORCA) to create solid requirements from a user perspective (8m38s).
• The ORCA process involves four rounds to create scalable artifacts, including an object map, which is more readable and maintainable than traditional entity-relationship diagrams, especially for systems with triple-digit objects (9m15s).
• The object map is a scalable artifact that can handle complex systems with many objects and attributes, making it a useful tool for designers and developers working on large-scale projects (10m38s).
• OOUX is applicable to various systems, including those with non-user-facing objects, and can be used in conjunction with other design approaches, such as domain-driven design (10m19s).

Addressing Challenges in Mapping Relationships

• The approach has been applied to real-world projects, including those with hundreds of objects, such as Autodesk's ecosystem, which has over 300 objects (10m23s).
• When mapping multiple relationships between objects, using traditional methods like entity relationship diagrams can become messy and difficult to read, especially when dealing with simple objects like a person and a post that can have multiple types of relationships, such as created, saved, liked, and drafted posts (10m51s).
• Architects often struggle to communicate their design and relationships effectively, as a single line with a crow's foot can represent multiple different relationships, leading to confusion and misinterpretation (11m31s).
• The nested object Matrix is a systematic approach to documenting relationships between objects, where objects are listed across the x-axis and down the y-axis, and relationships are mapped through the intersections (12m39s).
• This method allows for the description of cardinality and the mapping of multiple relationships between objects, which can be done using sticky notes, Miro, Notion, or other tools (13m11s).
• The nested object Matrix can be used to identify and document all relationships between objects, reducing the risk of missing connections and improving collaboration and understanding among cross-functional groups (12m54s).
• The Matrix can be read in natural language, with the top objects referred to as "host objects," and relationships described in a clear and concise manner, such as "an author has many posts that they've created" (13m48s).
• Object-Oriented UX (OOUX) involves capturing relationships between objects, which can be challenging but scales beautifully when done correctly (14m9s).

Documenting Relationships in OOUX

• In OOUX, relationships are represented as cards, with each card having a two-way street, allowing for documentation of the relationship between two objects (14m58s).
• The OOUX process involves creating a card for each relationship, such as a person having many articles they've created, and another card for an article having one person who created it (15m14s).
• The requirements round of the OOUX process involves looking at the mechanics of each relationship, including how objects connect, whether it's by user action, API, or system recommendation (15m45s).
• The cardinality of each relationship is also examined, including the average and maximum number of connections, which can impact performance (16m11s).
• Understanding the relationships and cardinality can help identify performance issues early on and inform design decisions (16m33s).

Understanding Cardinality and Performance

• Architects are concerned with the quality attributes of the system, including performance, which is related to the data relationships and how they scale (17m3s).
• Establishing requirements for data relationships and scaling can help ensure that the system can handle the expected amount of data and relationships (17m17s).
• For example, determining the expected number of posts a person will create in a year can help inform design decisions and ensure that the system can scale to meet those needs (17m22s).
• Object-Oriented UX (OOUX) involves understanding the objects, relationships, calls to action, and attributes that users care about, and quantifying these elements early in the design process to inform architecture and design decisions (17m33s).
• An object guide is created to outline the characteristics of each object, including the number of instances, to gauge the implications for design and performance (17m54s).
• The object guide considers the mechanics, cardinality, sorting, and filtering of objects, as well as dependencies between objects, to determine the necessary design elements (18m19s).
• Understanding the number of instances of an object is crucial, as it affects the need for sorting and filtering mechanisms, and designers should consider this early in the design process (18m25s).

The ORCA Process and Design Iterations

• Dependency between objects is also important, as it determines what happens to related objects when one object is deleted, and this should be informed by user research (18m51s).
• The ORCA process (Objects, Relationships, Calls to Action, and Attributes) is used to walk people through the design process, and involves iterating through four rounds of discovery, definition, design, and testing (19m37s).
• The ORCA process starts with noun foraging, which involves analyzing data to identify the nouns that users care about, and looking for nouns with structure, instances, and purpose (19m55s).
• The first round of the ORCA process is Discovery, which involves asking good questions to understand the objects, relationships, calls to action, and attributes, and shining a light on the dark corners of the design problem (20m33s).
• The design process can be compared to using a dim flashlight to understand requirements and scope, but Object-Oriented UX (OOUX) is like turning on a floodlight to figure out what is being built and identify unknown unknowns (20m53s).
• The OOUX process starts by identifying objects, creating a nested object Matrix, and then moving on to a call to action Matrix, roles, and permissions (21m27s).
• Roles and permissions are considered early on in the process, thinking about who can see what, and what actions different roles can perform on objects (21m31s).
• The call to action Matrix involves figuring out roles, objects, and verbs, with roles on one axis, objects on the other, and verbs in the middle (22m22s).
• The object map, also known as the "Holy Grail" of the OOUX process, involves adding attributes to the nested object Matrix, separating metadata from core content, and using a color-coded diagram (22m38s).
• Core content includes unique identifiers, titles, names, and images, while metadata is more structured content used for sorting and filtering (22m52s).
• The OOUX process involves a discovery round, where questions are figured out, and a requirements round, where everything is put under a microscope (23m8s).
• The requirements round involves creating an object guide, a glossary on steroids, and going deep with nested objects, inheritance, and object bases (23m23s).
• Inheritance is used to create object bases, where common attributes are pulled out and used as starter kits for objects, such as people objects being either celebrities or fans (23m33s).
• Object-Oriented UX (OOUX) involves a 15-step process that includes understanding objects, relationships, calls to action, and attributes, with the goal of creating a modular design based on objects (24m4s).

Creating the Object Map and Object Guide

• The process starts with identifying objects and their relationships, and then moves on to creating object-oriented user stories that include the who, what, why, and when of each action (24m24s).
• The user stories are then used to identify the attributes of each object, and to prioritize the objects, relationships, calls to action, and attributes from both a user and business perspective (24m57s).
• The prioritization process helps to eliminate unnecessary objects, relationships, calls to action, and attributes, and ensures that the most important elements are included in the design (25m8s).
• The OOUX process also involves sketching and designing screens based on the objects and their relationships, with the goal of creating a consistent and modular design (25m46s).
• The process is iterative, with multiple rounds of refinement and prioritization to ensure that the design meets the requirements and is consistent throughout the experience (25m40s).
• One of the benefits of OOUX is that it helps to avoid common problems in software development, such as missing requirements and half-developed software, by including all the necessary details and context in the design process (26m22s).
• The OOUX process is based on a more nuanced approach to design, one that considers the objects and their relationships, rather than just the flow of the user's actions (26m5s).
• This approach helps to ensure that the design is consistent and modular, and that all the necessary elements are included, rather than just focusing on the user's workflow (26m10s).

Adaptability and Benefits of the OOUX Process

• The Object-Oriented UX (OOUX) process is not rigid and can be adapted to different situations, timelines, and products, and it can be thought of as a bag of tricks that can be mixed up and used in different orders (27m23s).
• The process can be shortened by mixing up the prioritization and requirements rounds, such as going through Discovery, then prioritizing, and then writing requirements based on what's been prioritized (28m6s).
• The purest approach would involve taking the time to get a good idea of what the system is before prioritizing, which can take days or weeks, depending on the complexity of the system (28m16s).
• The OOUX process involves understanding concepts that don't change, such as the Pace layers, which are the bottom layers that don't change even if certain things change (28m49s).
• Working with companies to understand these concepts can pay dividends for years or even decades, and getting clarity and a shared language can be worth taking the time to figure out (29m35s).
• Building a glossary of concepts can help ensure that everyone is speaking the same language and using the same words for the same things (29m54s).
• Domain-driven design is a core part of OOUX, which involves having bounding contexts with ubiquitous language, and ensuring that language is consistent within that context (30m13s).
• Using the same word for different things can cause confusion, such as using the term "invoice" in different departments, and it's essential to use specific language to avoid confusion (30m31s).
• The goal is to get everyone speaking the same language and using the same words for the same things, which can help build complicated software (30m6s).
• Using the correct language in design and software is crucial for effective communication and can help remove problems with communication by embedding the language of the business into the design and software (31m5s).
• While using the language of the end-user is important, professionals need to be more precise with their language than how things are talked about colloquially (31m24s).

Understanding Tree Systems and Data Taxonomy

• The concept of a "tree system" refers to going from a general to a specific thing, not objects and instances, general to specific objects (31m36s).
• An example of a tree system is a movie, with the general object being the movie itself (e.g., The Little Mermaid), the specific object being the movie at a theater (e.g., The Little Mermaid at Mountain Cinemas), and the instance being the showtime (e.g., The Little Mermaid at Mountain Cinemas at 8:00 pm on Friday) (31m45s).
• Each of these objects has different information associated with it, such as the movie poster, runtime, and release date for the movie object, and the showtime, theater, and accessibility information for the showtime object (32m26s).
• The relationships between these objects are important, and permissions should be set so that only authorized individuals can edit specific objects (32m47s).
• Understanding these relationships and objects can help designers and developers create clearer and more navigable systems for end-users (33m27s).
• The hierarchy of general to specific objects is an aspect of data taxonomy and how data is structured and relationships are stored (33m47s).
• Creating separate tables in a database for each object, rather than putting all information into a single table, can help to avoid data structure problems (34m2s).
• When designing a system, engineers often focus on structuring data, but this is different from how users talk about it and what the design looks like, requiring different user interfaces and workflows for different users (34m12s).
• For example, a person editing show times at a theater needs a different user interface and workflow than a user booking a showtime, and may need to see additional data such as the number of seats in the theater (34m21s).
• This also involves considering rollup data, such as gross sales across all theaters, which can be seen by admins but not regular users (34m55s).
• From a user experience perspective, designers need to consider who gets to see what on different objects, how users navigate, and what permissions are in place for visibility and actions (35m20s).
• This also involves content editing questions, such as where information like handicap accessibility belongs, and how to ensure that changes to this information are reflected in all relevant places (35m36s).

User Interface, Workflows, and Permissions

• It's essential to establish core concepts like these early on, as they can be difficult to change later, and prioritization can help determine what to focus on first (36m23s).
• When revising the design, it's essential to consider how to make changes and what that process looks like, which may involve going back to the design board and re-evaluating priorities (37m4s).
• The goal is to create a simple system that can evolve over time, as quoted by John G, and this requires careful consideration of user needs and system design (37m29s).
• A simple system that works should be created before developing a complex system, as it's impossible to create a complex system that works without first having a simple one that functions (37m32s).
• Companies should think about their simple system that works and also sketch out their complex system, using tools like sticky notes, Airtable, Notion, and Miro, which are relatively inexpensive (37m43s).
• Building an 18-month plan is encouraged, but not a huge design upfront, as the goal is to think things through and avoid tech and UX debt (37m59s).
• Using the architecture metaphor, it's essential to plan for future features, like a porch or a third bathroom, even if they won't be built immediately, to make future development easier (38m15s).
• Having a good idea of where the project is going helps avoid tech debt, even if things change later on (38m40s).

Planning for Future Development and Avoiding Tech Debt

• The object map can be a source of truth for documenting requirements, and it's scalable, allowing every little bit and piece of the design to have its own page with structure and attributes (39m7s).
• With a documented object map, the technical side can start building out technical architecture, APIs, and other complex components without needing screens (39m39s).
• Designing screens can happen concurrently with working out technical architecture, making the screen design process more intuitive and less surprising (40m3s).
• Object-Oriented UX (OOUX) aims to reflect the truth of how the world works and how businesses operate, making it a naturally intuitive approach (40m29s).
• Changing the way systems work, such as in Hollywood movie distribution, can be achieved by understanding the underlying information architecture and reflecting it in the best way possible, resulting in fewer changes after launch (40m45s).
• By doing so, major issues that require rewriting, rethinking, and reworking can be minimized, following the 80/20 rule, and changes can be made with minimal disruption (41m7s).
• When changes do occur, deciding how to implement them can be a challenge, and it's up to the team to determine what becomes the source of truth, whether it's a sticky note, mirror board, Confluence, Jira, or another system (41m24s).
• The Object-Oriented UX (OOUX) process aims to minimize change management issues, and its custom software is being considered to facilitate this process (41m53s).

Collaboration, Resources, and Community

• The OOUX process involves collaboration between designers and developers, and there are many free resources available at o.com, including the O Forum, where people can connect and learn more about OOUX (42m15s).
• The O Forum is a free space for designers and developers to discuss OOUX, and it's a valuable tool for software architects to document their work in a methodical and color-coded way (42m37s).
• The OOUX process can help reduce stress in documentation and ensure that decisions are clearly documented, making it a valuable tool for software development (43m6s).
• People can connect with Sophia Prater on LinkedIn and learn more about OOUX at o.com, and the O Forum is available for those who want to join the discussion (42m25s).