Research on possible user disabilities and ways to create an accommodating UI and UX have been documented in the following document: https://docs.google.com/document/d/10L6B2yZmxZ-YEC60kwEfVfSLpnfk73y8eHhX407BJhY/edit?tab=t.0

Our UI team constantly keeps evolving our design and leaves all of the progression and design history visible. Due to the free-tier collaborative version of Figma we are using, we are limited to a maximum of 5 pages, which we have divided into features and overall PO feedback (because of this limitation, Features 4 and 5 share the same page). Some elements of the design become deprecated and are marked accordingly, following this is a Refactoring section illustrating the design replacing the deprecated one.
Screenshot showing the Figma page limit and organizations:

Elements marked as deprecated are followed by a Refactored design to better illustrate UI/UX progression.
. The PO feedback page shows the most up-to-date mockups delivered for each sprint. For refactored elements, the user stories are the same as the ones from the original mockups being refactored (marked under the specific feature).

Each mockup has been designed to provide the best Usability Experience UX to our users, including our personas with disabilities. All designs are made accessible such that no matter one's disability, each user has the same UI offered to them. ConUMaps is made accessible by nature. Designs go through a series of tests, namely colorblind tests where the colours used are put to the test for Deuteranopia.

Sprint	Link to Figma + info
Sprint #1	Sprint 1 mockups can be found here. Feature 1 (campus map, toggle between SGW and Loyola campuses, get information about buildings) will be implemented during that sprint. Screenshot illustrating where you can find the Feature 1 work. Deprecated elements are marked visibly. The refactored design can be seen under PO Feedback: Modified mockups have been named "PO FEEDBACK SPRINT 1" in order to keep a trace of the UI progression
Sprint #2	Sprint 2 mockups can be found here. Feature 2 involved a user selecting a start and destination building, the start building being determined automatically by user location, and directions being displayed on the campus map. This feature focuses on outdoor navigation, yet if the user selects a class as their destination, they will view a modal once they have arrived to the destination building and be prompted to resume their navigation indoors. This sprint has also involved refactoring the display icon for when a user is inside a building. Pop-up prompting the user to resume their navigation The delivered refactored Sprint#2 design can be found under PO Feedback:
Sprint #3	Sprint 3 mockups can be found here. In this sprint, PO comments have been addressed to refactor the building-to-building navigation feature and its design guidelines. Namely, current building icon overlays (indicating the building the user is currently in) have been produced and tested for accessibility. The latter can be found under the page "Feature 2", under the Refactored header. Moreover, the home screen design has been refactored to now have a search bar. This modification ensures a smoother search of buildings and seamless transition to the building navigation. Lastly, accessibility research have been implemented into the design layouts of the navigation (use of textures for the navigation routes) and navigation options were made horizontal to reduce user scrolling and save time (having it visible without scrolling helps users with reduced articulations mobility use the app and makes our product overall cleaner). Screenshot illustrating the refactoring of the building-to-building navigation search: An overlay from last sprint has been decided upon to be our final design to signal the user's current building. Introducing a new highlight colour would've been too confusing to the user, hence why an overlay that looks intuitive (person design) was the choice made here: Refactored navigation search: Use of textures in navigation, following research: The remodeled design guidelines support both light mode and dark mode as well as the autofill search feature implemented by the Devs. Refactored vertical layout for navigation and horizontal layout for travel options (bus, shuttle, etc)
Sprint #4	Mockups can be found here. In this sprint mockups for the schedule viewer and 'view next class' feature were implemented and a little brainstorming for the indoor navigation UI has been made. Epic 3: Calendar view We started by taking inspiration from Google Calendar and the existing Concordia App Schedule View. We liked the clean look of Google Calendar but preferred the more student-oriented functionality of the Concordia App. We then produced low-fidelity wireframes of the design to decide on positioning for key buttons, layout proportions, and text. Annotations were used on the Figma page to sketch out what some features would look like (e.g. the vertical timeline on the left, or the size of class blocks). The first design had a single theme that combined the light and dark themes, using the colour palette shared by the rest of the app. We also decided on an eight-colour palette for the class blocks, so that it would be easier for students to identify their courses at a glance based on colour. The first implemented version can be seen here, with two sample courses hard-coded for visualization purposes: The settings button was dropped since we could not find a good use for it. Separate dark and light themes were implemented to cover the requirements, and this involved some color changes to match the theme of the rest of the app and to produce more harmonious colour combination. The eight-colour class block palette was kept for both light and dark themes. This produced the following final designs: The "Open Directions in Map" button in the class details popup (changed more recently to read "View in Map") currently navigates the user to the map tab and sets the location of that class as the destination in the navigation component. The "Next Class" button (visible in the coloured mockups above) will have the same functionality, but implementing it has been pushed to the next sprint. involved extensive usability testing, and more refactoring is planned for future sprints. Lastly for this sprint, two alternative UI designs have been produced for indoor navigation (being non-final). The second is a refactored version, having more potential to be further improved next sprint. For now, this the latest low-fidelity mockup of our product that will be polish during Sprint 5.
Sprint#5	This sprint focused on design refactoring, yet at the very start (end of sprint4 as well) some designs have been added due to logic changes. Namely, following PO suggestions, a POI radius selector has been added for users to select the range at which they wish to see POIs. To view the list of design refactored changes following observed usability issues, please refer to the following Document: https://docs.google.com/document/d/1vK3lP-W4dGi659AWoX4kTGoRxSnlMk_XsBdcSyc9utU/edit?tab=t.iic0m1129ujz A few notable changes have been the transformation of the Indoor floor selector slider to Prev/Next buttons with the inclusion of an indoor navigation panel: Marker font size has been increased, and POIs now have a highlight enhancer feature: Other design refactorings mentioned in the report can also be found here: https://www.figma.com/design/24fKAa5jlr8pdVGD0JwhMM/Sprint-mockups?node-id=128-2&p=f&m=draw . Specifically, the mockups on page 'Feature 4 + 5' detailing the designs for a slider vs. a page of floor numbers to select the desired floor.
UI progression can be found under "PO FEEDBACK"	Each refactored element is highlighted under its specific sprint. To see more information and UI evolution for a specific feature, navigate to the feature's assigned page.