7 iPhones with different screens of the BGISAssist app

Brookfield Mobile App

An app to allow users to easily make facility service requests.

Background

BGIS was the facilities management arm of Brookfield before they sold the company to a holding company called CCMP.  The company provides facility services to some of the largest companies in Canada, like banks, telcos and the government of Canada.

BGIS was looking to allow for anyone to request facility services online.  Traditionally, users would only be able to call the call centre to request services.

Problem

The facility management system was originally created for the call centre reps to use.  The system was so complicated that the call centre reps needed to be trained 4 to 8 months to be able to use the system alone.  

This custom software was first launched over 20 years ago.  I was the first UX Designer hired at BGIS and I joined at Sprint 8 of 9 for their new mobile app project.  Although the system had many features, most people didn’t know they exist or how to use them.

Old Facility Request Form
Old Facility Request Form

The mobile app was the first application that would be public facing.  It was designed by a graphic designer who didn’t do any user research.  In addition, the designer didn’t know the company’s brand nor understand accessibility standards. 

Accessibility Audit

The first report I did was this Accessibility Audit of the app that the company had been working on.
It revealed many accessibility violations according to WCAG.

If not rectified, the company faced fines of up to $250,000.  To correct these violations, it required a design overhaul and recoding of the app.

Some accessibility issues included:

  • Use of a light-coloured image background that had white text on top (colour contrast violation).
  • Over 10 violations of colour contrast ratios (ie light grey text on top of lighter grey brackground)
  • Over 20 button styles (which makes it confusing to the user if a button is in fact a button).
  • Use of images of text and no alt text (prevents screen readers from working properly).
  • People with learning disabilities (grade 6 education level) would not be able to understand some of the terms used and there were no instructions on any of the pages.
  • Most of the pages had no titles and/or there were inconsistent headings, button text and navigation text (which affects people that are easily disoriented).
  • Some hover effects were using colour alone (a colour-blind person would not be able to distinguish the difference).
Cutoff snapshot of Accessibility Audit in MS Excel

Brand


I was the first IT professional to work with the Marketing department.  That said, none of the applications that were built prior to me joining were on brand.

I spoke to them about the brand guideline and got a thorough understanding of the brand from the person who created the Style Guide.  They emphasized the importance that the logo had enough whitespace around it.  I helped them understand how some colour combinations in their Brand Guideline were not accessible as they did not have enough colour contrast. They agreed that we could tint the colours to make them compliant in the application.

Card with brand logo and colours

The Marketing department was short staffed, so I had to recreate the logo to have a vector version of it. Prior to this, they only had rasterized images of their logo.

Some of the elements in the original design on the mobile app that were off brand include:

  • Lato is the font to be used for web applications, but Roboto was used instead by the Developers and SF Display Pro was used by the previous Graphic Designer.
  • None of the correct colours were not used (which also needed to be tinted to be WCAG compliant).
  • The wrong logo was used and the minimum white space was not around the logo.
  • The wrong type of imagery was used and the iconography was not vetted through Marketing.
  • The copy was not inline with the voice and tone guidelines.

Usability Audit

The mobile app was also not user friendly as no user testing was done on it prior to development.  Exploratory testing was conducted and many usability issues were uncovered.  

It was performed by an external consultant while developers, BAs, QAs and UX team observed.  He spoke thoughout the testing as he went through the sign up flow and request flows.

2 screens of the first 2 steps the original design of the mobile app

Stuck at Step 2

Some users would get stuck at step 2 not knowing how to move to the next screen
No titles to the pages nor any instructions to help the use with cognitive disabilities
Too many buttons (every icon was clickable) on the first page.  

2 screens of the last 2 steps of the original design of the mobile app that look similar

Reduce steps.

The number of pages in the legal documents were shortened.  For example, the agreement to the privacy policy, Jury Trial Waiver and Arbitration Agreement was linked in the Create Account step together with the agreement to the terms of service and electronic communications agreement.  

2 screens with the password creation field and one screen has the error message displayed

More clarity.

More conversational and friendly wording was used throughout the application form.  The pay schedule was particularly confusing for users to fill out. We reworded the options and made the proceeding fields customized based on what period they picked — making the experience faster and more clear.  

Information Architecture

Using OptimalSort, I ran a card sort for the input labels of the existing Request Form.

It revealed that the vocabulary that was used was confusing and so some words were replaced.

Some of the fields were found to be unneccesary and removed.

New groupings were formed and the groupings were ordered in such a way that made sense and produced progressive tracks for the user to have to fill in less information based on their answers.

Agile UX Process

Working with the Scrum Master and Product Owners, we created the UX prototype a sprint ahead of the Development team.

This allowed the prototype to be demoed to stakeholders and iterated upon any feedback before the design was added to the User Stories.

Sprint Planning and Sprint Grooming could then be done with the development team when the design was added to these stories.

Feedback from the developers was balanced with feedback from the Business and we met regularly and worked collaboratively to assure agreement.

Crossing Silos

It was revealed that the hidden password parameters was because the Infrastructure team did not want to have them up front due security policies.

There seemed to be a lack of communication between the IT team and the Infrastructure team. I developed a relationship with the heads of the Infrastructure team and arranged a meeting to address some the user experience issues that came up due to policies mandated by Security.

After explaining the findings from user testing and how it was producing a bad user experience, the Security team agreed to allow us to show the password parameters up front.  They also explained that it was a misinterpretation of what they meant. If this meeting never happened the experience of the application could have been affected by a misunderstanding.

Design

It took many iterations to come up with the final design.  Over 15 InVision prototypes were created over a span of 5 months.  

Rapid Prototype - Web Application

A rapid prototype was coded in basic HTML and CSS.  It was done quickly in 2 days.  It was pixel perfect to the design.

It showcased the responsive properties (first mobile first web application for the company) and how the same code would look and function slightly differently on desktop vs mobile devices.

It also allowed for me to explain how the code adhered to the accessibility standards and thus reason why certain changes were made to the web application. 

For the developers, this gave them a starting point for their styling.  It also helped me show to them what I meant by semantic coding.  
To the QAs I was able to show them what to for in their accessibility testing.

See Responsive Prototype

Successful Launch of Web App

The web application was one of the few at the company that was launched on time and on budget.  

More importantly, it was the only project that was on brand and fully compliant to Accessibility standards set forth by the AODA.

We had positive feedback on the application’s visual design and usability.

A Year Later

Due to budget constraints, I did not immediately correct these issues in the mobile app but did so in the only to the web application.  

A year later and after a visually impaired client gave feedback that the mobile app was not WCAG compliant, we were able to secure funding to make the mobile match the web application (which was compliant).

Because the design for the responsive web application was produced from a mobile first approach, the designs for the mobile application were presented and approved in less than a week.

We finished this project in 11 sprints, again on time and on budget.

Design Improvements

Many design improvements were done to improve not only the accessibility but also overall usability of the app.

Concluding Thoughts

This was the largest project I had ever done (over half a million dollars). It was an amazing feat to come in on time and on budget for both the Web Application and then the Mobile App Accessibility/Usability project.

That said, I faced some obstacles during this project. 

I had to create from scratch a UX department in a company that was an infant in terms of UX maturity. Couple this with the fact that my Director was trying to implement an Agile methodology at the same time. This was a legacy company in a very old industry (real estate) with many bureaucratic practices.

For example, due to the political nature of the company, the heads of IT wanted my accessibility audit buried and to make sure that the Business didn’t know about it.  It was my first month on the job, and I joined the company during sprint 8 of 9 of the mobile app project.  I diverted my attention away from the mobile app and used the details found in the audit to redesign a fully accessible web application instead (which was the next project starting in a week's time).  I was fortunate that funding was approved a year later to get the mobile app compliant to the AODA standards (mainly to avoid the potential financial penalties for not abiding to accessibility guidelines).  

I had to also deal with push back from .Net developers (who were learning Angular) on certain UI features that they didn’t know how to code.  Sometimes I compromised (ie like leaving country flags in the country code field) and sometimes I provided the UI solution for them.  For example, the new design had a vertical progress bar on the right side of the form.  We handled this by providing the HTML/CSS to make their horizontal progress bar rotate vertical and styled like the design.  They didn’t need to change their Javascript code, so they were happy.  I got the design implemented, so the users got a better experience.