Update issue templates - Added template for Design and UI Layout Fixes

Implementation of https://app.zenhub.com/workspaces/strr-65b2a7146835aa0cdf315b79/issues/gh/bcgov/entity/23256

.github/ISSUE_TEMPLATE/strr---design-and-ui-layout-fixes.md

@@ -0,0 +1,95 @@
+---
+name: STRR - Design and UI Layout Fixes
+about: Design and UI Layout Fixes
+title: "[Epic Title]: Design and UI Layout Fixes"
+labels: ''
+assignees: ''
+
+---
+
+# [Epic Title]: Design and UI Layout Fixes
+
+## **Context**
+Provide a brief overview of the current design or UI layout issues. Outline the pain points affecting the user experience and how fixing these will align with the product or business goals.
+
+> **Note:** This epic focuses on general UI design and layout concerns. **Accessibility issues** should be tracked separately to ensure compliance with accessibility standards.
+
+<details>
+<summary><strong>MoSCoW Prioritization Definitions</strong></summary>
+
+The MoSCoW method helps prioritize fixes based on their urgency and impact on the user experience. Below are instructions for how to classify each type of fix:
+
+### **Must Have**
+"Must Have" fixes are **critical** for the user to successfully complete an application. These issues should only be categorized as "Must Have" if they **block** users or cause significant confusion, potentially leading to **application abandonment**. A fix is "Must Have" if it meets any of the following criteria:
+- Prevents the user from completing a key task, such as submitting a form.
+- Causes the user to experience confusion, leading them to abandon the application process.
+- Results in functionality that doesn’t work as expected or creates a misleading experience.
+- Introduces a significant UX issue that negatively impacts the user’s understanding of the application.
+
+**Example**: A misaligned "Submit" button on a payment form that makes it difficult for the user to know how to complete the application.
+
+### **Should Have**
+"Should Have" fixes are **important** but do not block the user from completing an application. They may cause **minor confusion or frustration**, but users can still proceed with the process. These fixes should improve the overall experience, but are not urgent enough to halt progress if not resolved in the current sprint.
+
+- Enhances the user experience but does not completely hinder the user's ability to complete tasks.
+- Fixes design elements that cause slight frustration or reduce the clarity of the interface but are not deal-breakers.
+- Improves usability, but the issue doesn't result in abandonment.
+
+**Example**: The font size of a heading is inconsistent with the design specifications, but does not impede the user from completing a form.
+
+### **Could Have**
+"Could Have" fixes are **nice-to-have** improvements that enhance the overall look and feel of the design but have minimal impact on user functionality or completion rates. These issues can be deprioritized if time is constrained, and their absence will not disrupt the user’s journey.
+
+- Minor design adjustments that would refine the visual experience.
+- Issues that are unlikely to confuse users or cause them to abandon their application.
+- Improvements that can wait for a future sprint if more critical tasks take precedence.
+
+**Example**: Adding more whitespace between sections to make the interface look cleaner, but the current layout is still functional.
+
+### **Won't Have**
+"Won't Have" fixes are explicitly excluded from the current sprint or release cycle. These are low-priority fixes or design changes that either don’t contribute significantly to the overall user experience or are being deprioritized for now to focus on critical and high-impact tasks.
+
+- Not necessary for this sprint or release and will not impact the user's ability to complete tasks.
+- Deemed unnecessary at this stage due to time constraints or alignment with business goals.
+- Fixes that may be revisited later, depending on available resources and future iterations.
+
+**Example**: Redesigning a minor UI element that is not causing any functional issues or confusion.
+
+</details>
+
+## **MoSCoW Prioritization Fixes**
+
+### **Must Have**
+- [ ] Critical fix 1  
+  - [ ] QA Tested
+- [ ] Critical fix 2  
+  - [ ] QA Tested
+- [ ] Critical fix 3  
+  - [ ] QA Tested
+
+### **Should Have**
+- [ ] Important fix 1  
+  - [ ] QA Tested
+- [ ] Important fix 2  
+  - [ ] QA Tested
+
+### **Could Have**
+- [ ] Optional fix 1  
+  - [ ] QA Tested
+- [ ] Optional fix 2  
+  - [ ] QA Tested
+
+### **Won't Have**
+- [ ] Not included fix 1  
+- [ ] Not included fix 2  
+
+## **Impact Assessment**
+Summarize the potential impact these changes will have on the product and user experience. Include any risks or dependencies (e.g., other teams, systems, or epics) that need to be considered.
+
+## **Design Assets**
+- **Figma Designs**: [Insert link to relevant Figma files]  
+- **Miro Board**: [Insert link to Miro board for wireframes or brainstorming]  
+
+## **Acceptance Criteria**
+- [ ] All critical "Must Have" issues are resolved before this story is closed.  
+- [ ] Design aligns with UX/UI guidelines and meets functional expectations.

.github/ISSUE_TEMPLATE/strr-spike.md → .github/ISSUE_TEMPLATE/strr---spike.md

@@ -1,5 +1,5 @@
 ---
-name: STRR Spike
+name: STRR - Spike
 about: A template for Spikes on the Short Term Rental Registry team
 title: 'SPIKE - '
 labels: ''