Final Banner Design
Overview
Fairstone is a Canadian non-bank lender of personal loans and mortgages. They aim to help customers get the money they need at affordable payments that meet their needs and budget.
Role
UX & UI Designer | May - August '21
User Research, User Interface Design, Design System, Prototyping, UX Strategy, and Design Quality Assurance
Tools
Sketch
Abstract
Zeplin
InVision

What are we trying to solve?
Slalom Build brought on a team of UX Designers and Engineers to design and build Faisrstone's new Online Account Management (OAM) web application. Initially, the project was scoped for one Principal Designer; Slalom Build was able to extend the design work with Fairstone by pitching to build out a consistent design system that would be used across multiple products.
Scope & Constraints
Scope
Slalom Build project duration - 1 year
Constraints
There were a few constraints while building Fairstone's OAM web application, including the following:
New Market
Slalom Build recently opened a new market in Canada. The team was made up of a majority of Builders from this market, except myself and one engineer. With a new market, it takes time to learn Build's methodology and build camaraderie, especially during a global pandemic.
Fairstone's Marketing Team
The marketing team at Fairstone was heavily involved in the final decisions for UX and UI for OAM. This created some barriers for our team, especially when creating new components for the design system. For example, we were told we could not use green, even on components showing validation.
Consistency Is Key!
When onboarding, I noticed a lot of design inconsistencies in the MVP design files and design system for OAM. I knew if we did not address these inconsistencies, it would later cause problems and further inconsistencies in component and layout designs. Also, I wanted to address this, so designers could quickly jump into old and new design files without feeling confused.
The following inconsistencies I found during my audit:
Component Documentation - Most components did not have documentation on how and when to use features.
Spacing & Sizing - The existing components were not using atomic design, so the font size and margin spacing in components and the layouts were different from screen to screen, making an inconsistent design experience. The designers working on the layouts were trying to cram everything on the screen size of an iPhone 8, making sure the screens did not pass 667px.
Responsive Components - Most of the components created in the design system were not responsive, resulting in designers having to unlink and edit details. When designing, it is not a good idea to do this because it can cause components to be inconsistent in styling from screen to screen. Also, when component updates are made to the master design system file, the unlinked components will not take on the latest updates.
Breakpoints & Grids - The design system only used two breakpoints, tablet, and mobile. Since we were designing a web application, I suggested we use the following breakpoint; large desktop, small desktop, tablet, and mobile. When handing off designs to engineers, it will eliminate any confusion on the structure of the design for each breakpoint. Also, we were not using any grids, just ensuring everything was centered and aligned. I knew we should introduce grids, so it could save designers and engineers time and eliminate confusion.
MVP Screen Updates
After completing the design audit, I made some screen spacing and sizing updates. More updates to the design system were made after MVP.
Post MVP Focus Areas
Improving team communication
Recommendations on how Design and Developers can better communicate during sprintsMarketing Banners
Design explorationMy Account Screen Additions
Additional My Account screens were created to enhance the user’s experienceDesign System Updates
Clean up components and make them responsive in Sketch

Best Practices for Designer & Developer Communication
While working on this project, I noticed our designers and developers were not communicating much. Typically, the two teams only shared after engineers built out the screens. This was a red flag because both teams should be in communication with each other well before building screens. My recommendations are listed below.
Communication Channels
Establish how both teams will communicate with each other throughout sprints.Reoccurring Check-Ins
Weekly check-ins to eliminate confusion and address concerns.Documenting the Process
Utilize confluence more and make the design system accessible to developers.

Marketing Banner Exploration
Fairstone's marketing approaches me to create a marketing banner to promote getting a loan quote. This banner would appear on My Account Screens and eStatement pages. Below are exploration examples.
OAM V1 UI Design
After the banner exploration, I was responsible for updating and creating the user interface design for Fairstone OAM's account screens, including plan and transaction details pages.
To view screens, click through the clickable prototype to the right.
Impacts & Lessons Learned
Fairstone’s in-house designer appreciation. The in-house designers appreciated the UI work done for OAM, including the design system updates, layout design, and design strategy work. This work helped the designers prep for work on other Fairstone products.
We have established healthy communication across teams. By establishing regular check-ins with developers, we could communicate a lot more with each other to help solve problems we both encountered much sooner in the process. We were no longer working in our silos.
Keep being curious. While on this project, I learned to trust my gut and to question things so there can be healthy communication and to raise flags that may appear later in the downline.