At Anele, we leverage a framework called "Object-Oriented UX" (OOUX) that sits neatly between user investigation and actual design part of the process.
This is where we collect requirements. By "collect requirements", I mean... "hire-a-private-investigator-to-find-your-long-lost-twin" type of collect.
We define 4 areas:
1. What are the OBJECTS (entities, nouns) that live in your system?
2. What DATA makes each occurance unique?
3. What ACTIONS can users take on the objects?
4. How do all the objects all relate together - what are the RELATIONSHIPS?
This is the key step that other UX designers and agencies miss.
The best products and experiences SHOULD BE CONNECTED and not siloed.
This gives you more accurate scoping and requirements from the start, and let's all your stakeholders have a voice that connects priorities instead of competing against each other.
We bring all your stakeholders into a few interactive workshop to define and prioritize these requirements.
Investing this time at the start will save you hours and hours of rework, miscommunciations, and changes in requirements - and overall decreasing risks of burnout from a chaotic project.
Object-oriented UX leans into the fact that humans think in objects.
Our interactions, goals, and daily lives are centered around objects. When people visit a supermarket, their thoughts revolve around specific items like "Eggs" and "Milk," not abstract processes like "Check-out" or "Compare prices."
In contrast, traditional UX design often involves separate teams tackling different aspects, such as designing the stocking process and creating the check-out, without sufficient discussion of potential overlaps. This approach can lead to disjointed user experiences.
OOUX engages the left side of the brain, systematically breaking down data.
Unlike the common practice of software engineers reverse engineering designs, OOUX involves collaboration between designers, developers, and non-technical stakeholders. This collaborative effort aims to define the necessary data for the back-end and content management system (CRM). By working together, we determine what information must be collected, stored, and represented.
The attached functional requirements document is a proactive step. It serves as a guide for developers before the design phase begins, preventing potential roadblocks and saving valuable time.
Why do non-technical people need to think about data-models?
Imagine you had customers signing up for your video platform.
Those are all different requirements that each department needs.
