---
###### tags: `UX Research`
---

# V3 Baal UX Outline

### Overview:
- Attend designer + dev walkthrough on Thursday
- Prepare user flows/stories to capture data from Friday designer walkthrough
- Purpose of this UX research is twofold:
- to supplement the understanding of the designers and support their work.
- educate general users on the DH platform, quickly understand what is possible and what they can look forward to. Hype momentum for composable community building by inflecting upon the users imagination of what a DAO could be.
- [Baal UX Session Feedback Doc](https://github.com/Moloch-Mystics/Baal/issues/34)

### User Stories:
- Includes the articulation of user personas? To understand our community in a more personal level?
- Create a list for Rangers (or others) to contribute to.
- Standardize the format:
- "As a ____ user I want to ____ so that I can ____."
- We can form these stories into epics in narrative form.
- The narrative can be **dictated** to craft a first-person user POV for a text. Not a splainer, but *a narrative walkthrough* that focuses on **why**.

#### Examples:
- I as a non-technical user want to summon a DAO so I can form an NFT community.

### A/B/C Comparison:
- Demonstration of how a flow happens on DH v2.
- Compared to how the flow will be improved on DH v3.
- Supplemented by a third section that elaborates how it *could* work with new Baal functionality.
- A 3.5 section that speculates flows for *new Baal features* that are currently not represented on DH v2 or Moloch v2.5. > Amounts to a user-level understanding of how Baal is a game-changer without getting into the weeds on the technical explanation.

### Supplemental Questions for Baal Devs 1-19-22
- How are the decisions made?
- Does the logic inform the flow, or vice verse?
- Is the goal an elegant code? A minimal code? How is security measured or evaluated?
- How to consider a limit placed upon possibilities in these open jam developments?
- Is there a user in mind during building? Or is the user more universal?
- Is there a UI being visualized? Or are the contracts developed autonomously from the front end?
- How is code efficiency put in relation to gas costs, for example? Aspects of storage and computation...
- How is flexibility put in relation to the core features?
- How is consensus arrived at among the core devs? Based on experience?

- Different UIs will facillitate different kinds of decision spaces.
- Devs ask themselves: How *might* a UI be interacting with these contracts?
- How are UI interactions different from block explorer?
- Does Baal represent DAO metadata differently from v2(.5) contracts?

- [Simulation button!](https://docs.blocknative.com/simulation-platform/transaction-preview-api)
- Preview the unsigned txn and return data to confirm there are no technical errors... or
- Preview how a proposal would effect shares, governance, etc.

### Design/Dev Share Session 1-20-22
- How are DAOs connected? Leading to definitions of DAO relations and how to pull metadata...
- Parent-child connections of sub-DAOs: relation is defined on-chain
- DAO-of-DAOs: can be defined by membership itself?
- Membership = shares/loot/transactional relations to other DAOs via minions, ie: 2 safe minions from 2 different DAOs controlling 1 safe
- Txns are another kind of relationship.
- Token ownership is another.
- For social relations:
- DAO DID allows a DAO to store it's own metadata on Ceramic
- DAO URI: points to canonical metadata of a DAO that could be associated to the subgraph
- Demonstrate DAO relations with War Camp
- Signal proposals between DAOs showing disagreement
- Later: visualizations for how DAOs are connected
- Philosophical (ethical?) problem: code in the contract that is not represented in the UI
- Not wanting to reveal potential/future functionality
- Related to transferrable token: will be a toggle on Baal
- Post-deployment security challenges: proposal looks garbled on front end but is actually malicious. If the front end can't recognize what a proposal is doing, but it might be a change to the Baal contract, there should be a warning.
- Uberhaus Integration:
- Designers: trying to make a feature that every DAO would have access to.
- DAO-of-DAOs would be a networked feature for every DAO on the platform.
- UH needs a rework: remove Uberhaus membership submission forms, figure out an alternative membership submission process.
- Begin with an ideal design flow and work backwards from there.
- Mechanical problems are a bottleneck to increasing membership/participation.
- How will delegate proposals work?

### Parking Lot
- Boost ideas:
- Permissioned document changes via proposals
- Hard and soft DAO relations visualizer