| DS Design Solution/Category | Overview | Details |
|---|---|---|
| Color & Color Contrast | We conducted a comprehensive audit over color and its usage in both existing designs and the design system. As a result, we updated the design system to a consolidated color palette and a created a usage guide. All new designs created during Phase 3 adhered to the new color guidelines. | 1. The first step of this process was to audit the existing designs for accessibility issues related to color and color contrast. This meant making sure that a) color was not used as a primary means of communication and that b) color contrast ratios were at least at least 4.5:1 for text, 3:1 for large text (14pt bold or 18pt and above), and 3:1 for actionable icons or graphics. This resulted in a comprehensive list of problem areas that we needed to address. |
a) Colors used in existing designs: This part of the process revealed a) that there were many different colors used, b) that there was not a consistent usage of color throughout the designs, and c) most of the colors were not a part of the new ANT design system. Using so many different colors without consistent usage could result in cognitive overload for the user as well as a lack of perceived cohesion throughout the designs. Using colors outside of the ANT design system could result in creating more work than necessary for the development team.
b) Colors used in the ANT design system: This part of the process revealed a) that there also many different colors within the ANT design system and b) that the ANT design system relied heavily upon transparencies for color styles. While we wanted to switch our color palette to the ANT design system, we needed to pair it down and remove the use of transparencies (at least for text and actionable icons or graphics). (Transparencies are problematic because accessibility checkers will input the color at full opacity and may miss potential problem areas).
We created a new color palette using a paired down version of the ANT design system’s colors. We kept several colors specific to the brand, such as “raspberry-yogurt.” The client approved these changes, as long as the new palette still conveyed the “inviting, inclusive, and fun” Sean’s Legacy branding.
Using the new color palette, we devised solutions to the problem areas that we had identified in the accessibility audit. We also overhauled larger pieces of the design system, such as typography and visuals. From there, we created a usage guide for elements and common design patterns.
Moving forward, we recommend the following as it relates to color and its usage:
a) Update original existing designs to use the new color palette and follow the new color usage guidelines. b) Review designs created during Phase 3 to ensure that they use the new color palette and follow the new color usage guidelines. c) Determine and create usage guides for several more complicated elements and design patterns (such as focus and hover states, dropdown menus, etc.). | | Typography | An audit over existing screens as well as Typography guidelines in the Design System was audited. As a result, the DS guidelines were revised to be more specific with type use, as well as informative guidelines to clarify usage. | 1. The audit showed there was a lack of standardization with type usage amongst the screens.
DS guidelines didn’t clarify or label the types other than “Headings” and “Text” regular/semibold/bold/etc. We concluded the lack of clarity may be contributing to the confusion and inconsistent use of type.
Revised guidelines include labeling specific types as “Label,” “Button Large/Regular,” “Body text,” and “Subtitle” to reduce cognitive load for designers when applying local styles to the Figma file.
More in-depth, informative guidelines explaining type use are also available to serve as further examples.
Important to note that the guidelines may continue to be iterated/added upon as more screens are designed and various use cases are considered. | | Input Box & Labeling | We audited the existing designs' input fields and compared them to WCAG accessibility standards.
We identified several input field areas that did not meet WCAG standards for proper labeling.
Then we updated the design system with new properly labeled input fields.
Several proposals were also made to the team for improving input field consistency and coherency across all designs. | 1. The audit showed that many of the screens' input boxes lacked the label context required for accessible text inputs.
A notable example of accessibility issues was the search input present when a Mentee chooses preferred Mentor skills. The original search input wasn't sufficiently labeled, and appeared disconnected from the profile creation process. There wasn't enough context on how to use the new search input which could confuse new users.
Another example of accessibility shortcomings was in returning user log-in. In the original log-in screen, entering an incorrect password and/or email left thin red outlines around incorrect input boxes. However there was no other visual indication about which input boxes required change. The user would've needed to closely scan each input box for the outline to see which one they need to fix. This could be a time-consuming and visually challenging process especially for screens with multiple required input boxes.
We designed new search input boxes with proper instructional labels attached. These text labels can be changed depending on the context. Figma link
We created new input boxes for error-filled inputs. A red error message label and error icon is attached to each input. These visual indicators offer improved visual accessibility for informing users on which text fields need to be changed. Figma link
Lastly several additional proposals were made to the team for improving input box practices across designs.
a) Include text explanations for red asterisks, to inform users that these symbols indicate required text fields they cannot leave empty.
b) Add and/or remove asterisk labels for existing input boxes with respect to the different user flows, so that users can provide all the necessary info.
c) Include a password requirement Tooltip next to the input fields for account sign-up to help remind users of input requirements. Figma link | | Buttons (including links and icons) & Pagination | Conducted an audit of existing buttons, links, interactive icons, and pagination to ensure compliance with WCAG level AA standards. Updated the buttons and pagination to align with improved color guidelines, applied spacing tokens, and tailored variants for specific use cases. | Buttons
Recognized the need to tailor button components to specific use cases in order to maintain a concise library, particularly by eliminating the 'Dangerous' and 'Ghost' button categories.
Noticed discrepancies in icon sizing across buttons used in the design. Additionally, all icons needed to be sourced from 'Phosphorus Icons (community).' We also identified the need for a button variant that includes both an icon and text.
Reviewed the designs and found that the buttons in use were primary, secondary, and text buttons, each with various states (active, hover/selected, disabled, or with text).
Updated the color, spacing, and font size to align with the revised design system.
Designed buttons for 'links' without incorporating interactive elements. The only distinction was made between internal and external links, which were indicated by distinct colors.
Created buttons specifically for icons, offering three size options: 40px, 32px, and 24px, in compliance with WCAG recommendations that stipulate interactive targets should not be smaller than 24px.
Recommendations
Pagination
Figma Link | | Spacing | Utilized variables to create spacing tokens taking inspiration from Carbon’s Design System. | Depending on future needs, other spacing sizes/tokens may need to be accounted for, such as perhaps 56px. For mobile/tablet responsiveness, sizing has not yet been tested.
Guidelines for page spacing in the design system are suggestions. Once there is more alignment with all designs, it may be necessary to adjust spacing guidelines. | | Mentee’s Page Header | | Recommendations
| Feature | Recommendation | Details |
|---|---|---|
| Refer a Mentor/Mentee | ||
| Scheduling - Mentee | 1. Placement of calender month arrow |
Need to design a drop down menu for ‘Time zone’
Design how overflowing content will appear as (time slots)
Last item spacing to the bottom of the box throughout all screens should be consistent | 1. The left and right caret icons are currently positioned on the right-hand side. Would it be more intuitive to have arrows at both ends?
Recommend incorporating one of the dropdown menu components from the design system (DS).
Please design how the list of available times for selection would appear if the content overflows (scrollable?)
The spacing from the last element to the bottom of the box varies throughout the screens and lacks consistency. This inconsistency may affect the overall uniformity. Recommending to align the spacing to achieve a more cohesive look. | | Scheduling - Mentor | @Anonymous | | | Video Conferencing - Mentee | 1. A new left-aligned grid layout has been created
Data for upcoming bookings is still TBD as SL must come to a decision next phase on which video conferencing they will move forward with
Confirm technical feasibility with Dev
Keyword tags need to be provided/approved by UXW
Feedback Modal needs a scroll bar
Align mentee and mentor dashboards-they don’t need to be same as mentors will have more data/information but mentor dashboard can also use a side navigation
The same icons should be used throughout the website (i.e. home, messaging, alerts, etc.) | 1. The left-aligned grid layout needs to be instated into the design system for use in other areas with side navigation. It is currently 32 margins but depending on future use case, a 56px is another option. The side navigation is fixed width at 272px with 24px gutters.
Design may need to be revised depending on whether SL chooses calendly or ucanbookme as well between video conferencing options like zoom, etc. by product and SL
Data from the booking flow is used for upcoming bookings container, technically feasibility needs to be discussed after all the relevant information from #2 is confirmed
There is currently null copy for the keywords from which mentees can choose from for mentors
Once content provides list of keyword tags, modal height can be determined and a scroll bar can be added | | Video Conferencing - Mentor | 1. Finalize Designs: Designs for almost every element on the dashboard and its subpages will need to be re-reviewed for feasibility once video conferencing and scheduling tools are decided.
2. Icons: Review (and if necessary change) icons used on the mentor dashboard for consistency with icons used across SL
3. Dashboard - Mentees Page: Create expanded states
4. Calendar/Scheduling Cards: Create expanded states
5. Post-Session Review Modals: Will need to re-review designs and make sure they are consistent with the overall dashboard design and similar to the mentee-side designs | 1. Finalize Designs: Video Conferencing features were based off of a combination of popular platforms —final designs will most likely need to change based on what platforms/tools Sean’s Legacy decides to go with. For example, the calendar feature on the mentor dashboard may need to be scrapped and replaced with something else if we’re not able to get live calendar API data.
2. Icons: Will need to confirm that icons used on the mentor dashboard are consistent with icons used across SL (ex: messaging quick link icon, create booking icon, etc)
3. Dashboard - Mentees Page: Expanded states for the various mentee sections (current, waitlist, past) were not created in Phase 3 and will need to be created for Phase 4
4. Calendar/Scheduling Cards: Expanded states for the final, fully-expanded, variant were not created in Phase 3 and will need to be created for Phase 4 if whatever calendar tool we integrate with does not already include designs
5. Post-Session Review Modals: Designs for the mentor and mentee post-session review cards were finalized but not unified with one another. These will also be dependent on the video and scheduling tools decided by the team. Could be good to consult with product and research on these as to the full purpose of this section and what we want to track here (as well as how we will measure this) | | Messaging - Mentee | 1. Text input box for chat conversation screen: update grid spacing, Phosphor icons, and positioning of send button.
2. Mentee Messages Empty State: assess informational text content below illustration.
3. Contacts List: examine and update column alignment, and improve auto-layout spacing between name and notification
4: “Send to” modal: explore designs for scrolling search results.
5. Messaging date dividers: evaluate visual accessibility. | 1. Text input box for chat conversation screen: The left and right side spacing needs to be updated for the 4px spacing guidelines. A new column grid could be applied to the rightside Messaging area with these spacing guidelines in mind.
All icons for this section should be reviewed and confirmed to be Phosphor. Especially the icon for changing text color, which may not have a counterpart in the Phosphor set. Also confirm that all icons have the same grey color.
Visual separation between the Send button and the primary text area could be explored. Recommend creating a variant with a filled text box.
2. Mentee Messages Empty State: Work with the Content team to review the copy for the empty state. The text is meant to inform Mentees of the benefits of contacting Mentors and using the Message features.
3. Contacts List: The overall layout is solid but grid column alignment could be reviewed for more refinement.
Currently there is no set spacings between contact names/titles and the new message notification. Auto-layout will need to be reviewed so that internal text will get pushed down if too long.
4: “Send to” modal: For a modal of this size, the length of the results list should be considered and how the user should browse the list. Continuous vertical scrolling, arrows or number pagination, etc.
5. Messaging date dividers: Review the dotted line divider for visual accessibility, but still keep the divider distinct from other lines on the screen. The date divider should probably look different from the line that separates the chat message area from the mentor’s name. | | Messaging - Mentor | 1. Text input box for messaging: Update icons and refine auto-layout and spacing. 2. Pending messages: If approved from client, mentee’s will request to connect with mentors. Any messages from pending mentee will go into pending messages. This future overall needs to be iterated on, if approved. 3. Scrolling messages from mentees on side bar: Either a continuous scroll, broken up by page numbers, or clicking a left and right arrow. 4. Searching contacts: When a mentor is searching a mentee’s name in the search bar on the side bar, what will that look like? | 1. Text input box for messaging: Update underlined A to match the rest of the Phosphor icons. Auto layout could use some refining. Double check spacing and spacing guidelines. 2. Pending messages: Pending messages alert will remain shown at all times, whether the mentor is in the ‘All’ section of their inbox, ‘unread,’ or ‘archive’- it will never be hidden. A pop up modal will need to be developed for what reading a pending message will look like alongside approving or declining it. This would also involve working with content team. 3. Scrolling messages from mentees on side bar: For mentors that receive or save a lot of their contacts’ messages, it will be important to decide on how viewing all these messages will occur. Will the mentor have a continuous scroll bar available to them? Will it be broken up my numbered pages from newest to oldest? Or should a left and right arrow be implemented as a way to go to a new page? All of this will have to be explored in the next phase. 4. Searching contacts: This aspect will need to be iterated on further. Will typing a name give suggestions for contacts already in the list that have similar letters? Or will it show all contacts with the same first letter that is typed? This will have to be discussed and explored in the next phase. | | Reporting - Mentee | 1. Expanding button for reporting options: Need to iterate on components as there were issues with substituting the icons to be phosphor icons instead (such as with the drop down asset). **-**need to make the drop down more distinguishable from the background, but when trying to apply an outline, I couldn’t unionize the triangle + rectangle so the outline was not ideal. Maybe consider creating a new component or iterating on the DS.
2. Modal for Filing a Report: Need to conduct audit on components in the Design System to ensure flexible customizability. **-**Also for some reason, when applying the background blur to the mentor profile, it completely covers the screen instead of having partial opacity.
3. Next Actions to be taken after submitting report: Collaborate with UXW and/or SL team to decide on what content should fill the modal
4. Action taken success modal: Review all component variants and ensure that you can customize what needs to be customized, without having to detach instance. -Also unable to change the states with the button group component. | 1. Expanding button for reporting options: Unable to make edits to the dropdown menu component
2. Modal for Filing a Report: Had to use basic modal, rather than profile modal. Lacked some components and cannot edit the modal directly, so had to get creative with certain fields (such as making a vertical upload form, since there isn’t already a vertical upload form component. As a result, there lacks help text—which may be necessary for advising on what types of files can be uploaded and maximum size.
3. Next Actions to be taken after submitting report: the modal screen informs user of what to expect after submitting their report. Options to block, mute, or complete are offered but it’s unclear what will exactly happen on the back end and whether the content is best fitting.
4. Action taken success modal: The existing “success” modal variant is a different size than the basic AND profile modal. Team feedback highlighted the design discrepancy. | | Reporting - Mentor | 1. Mentor Dashboard: Need to adjust spacing (use spacing tokens), apply auto layout, determine the proper profile image size; iterate on gamification badges and cards
2. Notifications Drop-down/Popover: Determine if this is the correct component to use (if so, needs to be adapted to include nested components), determine if there needs to be a page built out for notifications (when user selects “view all”), confirm the correct usage of spacing/auto layout, text styles, and color as defined in the design system stem.
3. Mentees Kebab Menu Drop-down/Popover: Determine if this is the correct component to use, confirm the correct usage of spacing/auto layout, text styles, and color as defined in the design system, determine if it is technically feasible to include the “connect on LinkedIn” feature
4. Report Filed: Confirm the correct usage of spacing/auto layout, text styles, and color as defined in the design system, determine where this page “lives” (i.e. where do mentors find this report if not under notifications?)
5. Mentor Resources (iterated upon from the Mentor POV flow): Need to audit for text styles and spacing; collapsed component needs to be adapted in the design system to include the proper icon
6. Modals: These modals were created in collaboration with the Mentee POV (see above for a detailed breakdown of issues). The issues that varied from the above-mentioned include: Need to audit for text styles and spacing; determining if the preview mode can be done with development team, if so, trash can icon should be removed from the upload component in preview mode | 1. Mentor Dashboard: Need to adjust spacing (use spacing tokens), apply auto layout, determine the proper profile image size; iterate on gamification badges and cards • The top frame is not a component, just a frame. Need to be added to the design system. • Need to add spacing tokens/adjust the space between elements/padding. • Need to apply auto layout. • There was a discussion around the proper profile image size. We did not come to conclusion, but reduced the size a bit from the original iteration. Need to ensure that the resulting size works within the spacing guidelines. • Gamification was out of scope for this phase but was added to the mentor dashboard (top frame) because the main call to action for the mentor dashboard is to continue engaging with the platform as a ment**or.
3. Mentees Kebab Menu Drop-down/Popover: Determine if this is the correct component to use, confirm the correct usage of spacing/auto layout, text styles, and color as defined in the design system, determine if it is technically feasible to include the “connect on LinkedIn” feature
• This may be better as a dropdown (not a popover), so the correct component needs to be selected.
• Need to confirm that this component is using spacing/auto layout, text styles, and color as defined in the design system.
• Determine with development team if it is technically feasible to include the “connect on LinkedIn” feature. If so, determine if there should be an alternative for mentees who do not have a LinkedIn profile.
4. Report Filed: Confirm the correct usage of spacing/auto layout, text styles, and color as defined in the design system, determine where this page “lives” (i.e. where do mentors find this report if not under notifications?) • Need to confirm that this component is using spacing/auto layout, text styles, and color as defined in the design system. • Determine where in the user flow this page “lives” (aside from notifications)
5. Mentor Resources (iterated upon from the Mentor POV flow): Need to audit for text styles and spacing; collapsed component needs to be adapted in the design system to include the proper icon • Need to confirm that this component is using spacing/auto layout, text styles, and color as defined in the design system. • The icon that was used in the collapsible component in the design system is not form the Phosphor library (what is currently seen in the design is from Phosphor but the component had to be detached in order to create it).
6. Modals: These modals were created in collaboration with the Mentee POV (see above for a detailed breakdown of issues). The issues that varied from the above-mentioned include: Need to audit for text styles and spacing; determining if the preview mode can be done with development team, if so, trash can icon should be removed from the upload component in preview mode • Need to confirm that this component is using spacing/auto layout, text styles, and color as defined in the design system. • Is preview mode doable from the dev team standpoint? • If preview mode is a go, can we please remove the trash cans from the upload component in this mode. |
| Feature/Category | Summary | Added Notes/Link to Video Walkthrough |
|---|---|---|
| Landing page | The landing page has access points to the About Page and Onboarding/Registration. |
These access points can be activated via clicking “Sign Up” buttons or the “about page” tab in the header | | | About page | The about page is accessed via the top nav bar or the bottom footer on the homepage.
It has brief background information on Sean’s Legacy. It also features a contact form at the bottom of the page, please note some of the buttons are interactive in this form but do not do anything or go anywhere. | | | Sign up/log in modal | The sign up/log in modal can be initiated via the sign up CTA buttons at the top of the page the middle of the page (homepage only) or at the bottom of the page in the footer
| Please note: the email, password and age verification checkbox all need to be clicked for the sign up CTA button to become active. | | Email verification | Email verification is a continuation of the onboarding flow that consists of static screens move forward with a click
Pls note: for clarity, in reality these screens would be encountered in a separate window when the user verifies their account via their email inbox of choice | These screens contain no buttons and can be progressed via clicking anywhere within the prototype | | Onboarding | These next few screens contain basic information input. Input fields and CTA buttons are all interactive | - it is not possible to leave this flow unless you reset the whole prototype.
| Feature | Recommendation | Details |
|---|---|---|
| Notifications | Adding a notifications link or icon with a drop-down in the nav bar. | Adding notifications will allow users to keep track of certain activities such as a mentor approving them to view their calendar of availability. etc |
| Date of upcoming session | Design a way for users to see their upcoming session dates | Collaborate with dev, how can this be achieved using the Calendly API? |
| Save a mentor feature | Users should be able to save mentors of interest to a list. | Users will search for mentors and might not necessarily be ready or want to book a session with those mentors yet. They need an area to refer back to that has their mentors of interest saved. |
| Badges & gamification | ||
| Prompts to answer before a session to help structure the meeting | ||
| Resources | 1. FAQ page |