Add initial files

Adding the UI-UX guidelines and UX pattern documents

UI-UX for O3DE.md

@@ -0,0 +1,73 @@
+# UI/UX for Open 3D Engine
+
+Welcome O3DE contributors! If you are reading this document,it's likely because of one of two reasons: 
+
+1. You are building or modifying a front end feature of O3DE that has some kind of UI 
+2. You are contributing to our UX/UI patterns and libraries that you want globalized 
+
+If it’s the latter, please note you will have some additional steps needed for your contributions to be accepted and moved into our global patterns. Please review the [UX Patterns for O3DE]() document to learn more. Our hope is that by globalizing all of our UX foundational work, we can keep O3DE from becoming a hodgepodge of tooling. It also provides rules for all of us to follow and includes a set of pre built input types that allow developers to work quickly without needing to get UX sign off.  
+
+We want to provide developers with a simple and easy path to develop new tools and services that look like they are a part of a cohesive O3DE experience.  This will allow for tool builders to do what they do best, and focus on the tools they are creating, rather than establishing new UI designs for each new feature.
+
+## About this document
+
+This document is a living document and its contents will change from time to time as issues are evaluated by the UI/UX SIG in accordance with our charter. If something is not outlined in this document that you are looking for,reach out to us. We are always looking to improve the clarity of our guidelines. 
+
+
+## What is the UI/UX approval process all about?
+The UI/UX approval process helps us keep an eye on new feature work going into O3DE to provide a consistent, delightful, and easy-to-use experience for creators in the engine. When submitting a new feature with a user interface, the UI/UX SIG will be using the following guidelines to approve work.
+
+* Did you follow the UX pattern library and UI 2.0 framework?
+* For major changes or new pattern additions, did you get approval from the UI/UX SIG?
+* Did you include any additional research in how decisions were made with regards to the design or implementation of your feature?
+* Does your feature interact with other gems or editor tools without error?
+
+Following the provided guidelines is your best opportunity to get your content live quickly.  
+
+## Tell me more about the UI/UX SIG?
+
+* The UI/UX SIG meets on a regular basis and reviews any emails, tickets, patterns, or updates being requested. Assigned delegated members will have time to review tickets activities with the group.  
+* Members of the SIG are expected to follow the same rules of engagement to add in new content.
+* During our meetings, an owner will be assigned to follow up on all activities for a given submission. Their job will be to identify any problems with the current design system in conjunction with QA an the submitter (if needed)
+* At the end of the meeting a determination will be made about the submissions and reply to the email with the given determination. In some circumstance the submitter might not get feedback from our team. It is on a case by case bases
+
+### What does the UI/UX SIG review?
+
+We focus on the use cases and example that fall outside our foundational rules / patterns and or changes to the existing rules/patterns. 
+
+*Who is doing the implementation work?*
+
+You are. As work is submitted to O3DE.  If your feature contains user-facing features, please include screenshots and the information below in your PR:  
+1. Does your new content include ANY UX related interfaces? 
+2. Did you follow the UX Pattern and tool libraries?
+3. Did you have any conditions in which you implemented any new patterns, or tools that were not an existing part of the UX libraries?  
+       
+
+*Who should be using this system?*
+Anyone who plans on delivering any experience that has a customer facing interfaces. 
+
+## Recommendations for creating new user interfaces
+
+* Start by installing O3ED and gaining access to [`QtControlGallery.exe`](https://alpha-docs-aws.amazon.com/lumberyard/latest/userguide/ui20.html#ui20-best-practices)
+* Create a “process flow diagram” and or “user flow examples“
+    * Attaching these to your final submission helps us review quickly, especially if the feature is large.
+* Take a look at the [UI Component library](https://alpha-docs-aws.amazon.com/lumberyard/latest/ui/uidev-component-intro.html) and plan your UI tooling based on the tools and controls you currently have access to. 
+    *  If library is lacking a specific input type, component, pattern, or tool you’ll need to submit your new changes through the [UX Patterns for O3DE]() process.
+* Avoid writing custom input field types. This causes misalignment and inconsistency in look and feel.  
+
+
+## Can I make additions and or changes to the UX framework?
+Yes! We welcome participation in the UI/UX SIG. You can choose a contribution amount of time that works for you. You can help shape the future of our UX in a couple different ways:
+* Help review RFCs PRs, and issues that have a UI/UX component and provide feedback 
+* If you are interested in just contributing patterns or tool, see [the O3DE Patterns for O3DE] documentation
+* If you would like to contribute as a UI/UX SIG member, join the mailing list and introduce yourself there or in our Discord channel.
+
+## Future Additions to this guide
+
+* What things can I do on my own?
+* Whats falls outside of this plan?
+* Approval process for content to go live
+* What do I do if I don't have an answer to my question?
+* Where are the resources located?
+* What happens if I choose to ignore this 
+

UX Patterns for O3DE.md

@@ -0,0 +1,45 @@
+# UX Charter - UX patterns for O3DE
+
+This document outlines the process for submitting changes to the Open 3D Engine UX patterns or adding new features that are not fully covered in the existing pattern library. 
+
+## What is required for a submission to be accepted?
+
+* A new pattern can only be introduced when a new feature or an existing feature requires this feature work. Meaning it is not the responsibility of the SIG to keep track of patterns that are not being used inside O3DE.  
+* It is required that all new patterns be validated against at least 3 game teams.  Minimum of 5 individuals. 
+    * The details collected should be. Teams you validated against, type of research study, date, Questions asked, and % or number of candidates who agreed and disagreed with  your design,
+    * These details should be submitted to the UX Sig along with your designs for approval (See form below).
+* All new patterns must validate their design against the existing build. Verify these new patterns do not overlap with  existing patterns. 
+    * If this new pattern does overlap with an existing pattern, you must relay this information during the review of your new design pattern.
+    * It will be the responsibility of the UX sig to decide if these two patterns can work harmoniously, if the two patterns need to merge, or if they are incompatible with one another. 
+        * If it’s decided that two patterns are incompatible with one another, the pattern is rejected.
+        * If the pattern can merge or work harmoniously than the pattern can proceed to the next step. 
+* If a new pattern is identified and should move forward, it must receive a up vote from the creator, the chairman and 51% of the contributors. 
+    * If at any point the Sig cannot come to an agreement on their own. It is requested that the global arbitrator come in and help make a final decision.  The Chairman will help make the determination of the arbitration 
+    * If the pattern is excepted. They must continue to the next step.
+* A ticket needs to be created that will track all the activity, approvals and research and work being requested.
+    * It is the responsibility of  the creator to identify all location in which this new pattern should be used and request this specific detail in the ticket.
+* Documentation for the website: The number one detail needed is all of the specific use case(s) in which you would like for your patter to be implemented. Please note that you may not include any new pattern and or additional content that was not approved by the UX Sig.
+
+## Enforcement and Review
+
+* It is up to all of us to help enforce the standards of the UX Sig. If you identify a location where the UX pattern seems to be inconsistent with our pattern rules. Please report it to the [UX Sig mailing list](https://lists.o3de.org/g/sig-UI-UX), who will review this issue and make a determination on how to move forward. 
+* During the submission of any new Gems or services back to O3DE we will be working closely with our QA team to confirm pattern accuracy. If a pattern conflicts with existing pattern or a new/modified pattern is uncovered during the review process, the code submission will be put on hold until the UX charter can review and sign off on this process.
+
+## How do I request a UX pattern review? 
+
+Please submit the below form to the [UX Sig mailing list](https://lists.o3de.org/g/sig-UI-UX) or file an issue in [o3de/sig-ui-ux](https://github.com/o3de/sig-ui-ux/issues) and we will put this item as an agenda item on our next meeting or resolve it through the issue comments. Depending on the complexity of the feature we may or may not request you to attend a meeting to go over the details of your request.
+
+### What should be on the form I submit?
+
+* Your name or GitHub username
+* Your company (if applicable) 
+* Description of your new pattern
+* A written description of your use case(s).
+* The problem you are trying to solve.
+* Visual examples of the use cases.
+* Identify all location in which this new pattern should be used.
+* Does this pattern conflict with any other patterns (Yes; where?)
+* Research details (see above)
+* Implementation details involving the change 
+  
+