Object-Oriented UX

Notes I took while reading this article on A List Apart by Sophia V. Prater:

• Much like the book Published/Conceptual Models, Object-Oriented UX claims that we shouldn't start designing from actions, main flows, or screens.
• Instead, we should start designing from objects and their relationships.
  • Objects better mimic the mental model of users, because people think in objects.
  • Objects are how engineers structure code, os it helps cross-functional alignment.
  • Objects make your system easier to cut, prioritize, and build.

Process

The OOUX process aims to help us map and uncover the objects in a system, their content, how they relate to each other, and how users can act on them.

1. Extract objects from goals
   • Highlight the nouns on sentences that describe your product's capabilities and goals.
   • Keep only the objects that users will be exposed to; discard objects that are vague.
   • Discard words that are actually just ways of implementing a lists, eg. Feed, Map, Catalog, etc.

• Separate each object into a post-it:

2. Define core content of objects
   • Separate in two categories: core content and metadata.

3. Explore nesting objects inside each other
   • Nesting objects helps us question what relationships they should have, and often surface ideas that we hadn't explored before.
   • What happens when you get a user and put it inside a "recipe"? What relationships could they have?

4. Forced ranking

   • Often the most difficult step. Rank post-its based on importance.
   • Remember: Priority order does not mean how elements will show up on design. This is the designer's job later, to figure out how to reflect priority in the UI.

5. For every object, brainstorm what actions a user may want to perform on them.

   • Eg. for an ingredient, a user may want to mark as favorite, add to a list, check availability, follow, mark as a allergy.
   • On a first pass, you can simply add post-its with all CTAs next to the object diagram.

6. On a higher-fidelity pass, you'll want to move to a spreadsheet that can capture:
   • The object
   • The CTA to act on the object
   • Why does the CTA exist
   • Who will trigger the CTA
   • Where will the CTA live?
   • How much complexity is inherent in the flow that starts with this CTA?
   • Priority of implementing this CTA?
   • Open questions and discussions about this CTA?

7. You can test your conceptual model before any UI design. Let users navigate through the boxes and see if the relationships and "doorways" make sense to them.

8. Finally, now you're ready to start designing the Interaction.

   • Now, you can design with more confidence that the team is aligned, and that users will understand the end result.