Redesign of PSHSA’s website and eCommerce experience

The Public Services Health & Safety Association (PSHSA) is a government-funded organization that offers training, resources, and consulting on occupational health and safety across the province of Ontario. Primarily, PSHSA offers its services to those in the public sector: healthcare and community services, education and culture, government, and emergency services.

After the success of the Workplace Violence Risk Assessment Tools project, PSHSA once again partnered with Focus21, this time to do a full redesign and rebuild of PSHSA’s public facing website. The existing website had a few key problems that needed to be resolved:

1. It was based on legacy systems, including many WordPress plugins that could result in security issues;
2. The visual look and feel was outdated, and many users complained that the website was too cluttered with information;
3. There was an over-reliance on the customer service team to handle ecommerce requests, such as transferring a customer’s training registration to a different session.

The team at Focus21 took on this challenge to deliver a new website with a streamlined user experience and based on a modern tech stack. I acted as the primary UX designer throughout the life cycle of the project and was involved in the full end-to-end process from design to delivery.

The old version of the PSHSA website.

The redesigned version.

Executive summary

Role: UX Designer at Focus21
Platform: Responsive website (mobile, tablet, and desktop)
Project type: eCommerce website redesign for client
Project team: Client stakeholders, several engineers, QA analyst, visual designer, UX interns, and myself
Duration: 10 months (Sep. 2017 — Jul. 2018) with minor support afterward

• Focus21 partnered with PSHSA to redesign and rebuild their public-facing website. This included a variety of content and eCommerce elements for purchasing of health and safety training and resources.
• The existing website was based on legacy systems and had an outdated look and feel, as well as issues with eCommerce functionality which prevented PSHSA from providing the customer experience they wanted.
• I planned a discovery workshop which the UX lead and I facilitated on client site. The workshop activities helped us learn about the known website issues and better understand PSHSA’s vision for the future state of the website.
• I executed an analytics review and conducted user interviews to gather both quantitative and qualitative data on our target users, and understand what paint points they were encountering.
• I leveraged this research data in my design process and began by creating user flow diagrams for the key user journeys we were looking to support. I sketched early ideas for these flows, and then created low-fidelity wireframes to present these concepts to PSHSA for review.
• I built high-fidelity prototypes as the designs progressed to showcase the functionality of certain features and make sure the PSHSA team and our development team were on the same page for what the deliverables and end-experience would look like.
• Then, I facilitated ten remote usability tests with users and gathered feedback through a survey. This helped ensure we were on the right track and were providing a smooth experience for the key user flows on the website.
• During the development process, I supported the development team by writing user stories for the features in the designs, as well as conducting accessibility testing on the website.
• The new version of the website had a clean, modern, aesthetic with more intuitive workflows and enhanced functionality to ease the pressure on PSHSA’s customer service team.

Discovery process

We began the process with a Discovery Session — a workshop meant to gather requirements and context about the project, and generate ideas on what the future customer experience of the redesigned PSHSA website would look like. We invited about 10 participants from PSHSA, including executives, mid-level staff, and some of their field consultants. The goal was to bring a variety of people into the room, in order to have different perspectives on the organization and hear their thoughts on what is important for the website.

To prepare this Discovery Session, I began by researching workshop activities we could run that would create value for both our team and the client, given the nature of the project and the attendees. I used websites such as Gamestorming to find these activities and assembled a shortlist of ideas. These were vetted by my manager and we put together a plan for how the day would run.

We ran the session at PSHSA’s office in Toronto. I took notes throughout the session and guided some of the discussions with the participants. We ran activities such as “Stop, Start, Continue” and a modified version of the “World Cafe”. As a result, we were able to create a loose journey map of the path to purchase a potential customer may take on the PSHSA website.

Sticky notes on chart paper, forming a rough user journey map for how customers purchase training from the PSHSA website.

The Discovery Session resulted in us having a better understanding of PSHSA’s needs and expectations for the project, as well as a plethora of ideas to explore.

During the early stages of the project, I also conducted an analytics review and a content analysis. For the analytics review, I examined the data from PSHSA’s Google Analytics account over the past year, including which of the various pieces of content were most popular (training products, resources, etc.) and what key search terms people were using on the website’s global search. This quantitative data provided me a better indication of what mattered to end-users: for example, the Joint Health and Safety Committee (JHSC) training courses were by far the most popular. I summarized my findings in the format of an analytics report.

For the content analysis, I did a deep dive into the different types of content and pages available across the PSHSA website. What I discovered was that many pages were buried or only linked from specific areas and not easily accessible through the main navigation. Additionally, there were many pages that were outdated and no longer relevant, which would need to be omitted from the new website. I gathered all the various pieces of content into mind maps (seen below), which then fed into my proposed site map of the website. This site map would go on to be revised a few times throughout the project.

User interviews

In addition to the quantitative data, we also gathered qualitative data by conducting user interviews. The client was able to put us in touch with two of their customers, one in the education sector and one in the emergency services sector. Additionally, we conducted two more interviews with PSHSA’s field consultants. While they were not customers themselves, they interacted with customers on a daily basis as part of their consulting role and were end-users of the website in their own right.

I set up a list of key questions before each interview, which I then asked during the sessions and recorded notes. These interviews provided us further insight into the motivations of end users — the analytics told us what people were looking at, but the interviews told us why they were looking into those pieces of content. They also provided us further context into how customers engage with PSHSA. For example, one of the customers stated that they never paid for regional training through PSHSA’s ecommerce system, because they would always have a consultant deliver the training at their workplace. There was no option on the website for customers to engage in this kind of request, however. This lead to the creation of an onsite request workflow later on in the project.

Based on the information and insights gathered throughout the discovery phase of the project, I put together the diagram below to illustrate the different types of end-users this project would need to accommodate, both internal and external.

A diagram outlining the internal users (PSHSA content editors and customer service team) and the external users (consultants, clients, and learners) of the PSHSA website.

Design process

Based on the findings from the discovery phase and user interviews, I dove into outlining user flow diagrams to illustrate the ways in which users would interact with the new website, and how the website would fit into the goals they were trying to accomplish. I started by first outlining on paper all the steps that the user would take and what options would be available to them, then transferred those into a digital format to share with the team and with the client.

I then drew out sketches to illustrate what each of those key steps would look like for the user. Since this was a fully responsive website, I had to consider how the user engagements would work on both desktop and mobile screen sizes.

I recreated those sketches in digital format as wireframes. The reason for this was to provide the client with a low-fidelity idea of what the features and workflows would look like, in order to get their feedback on what they experience was like instead of the visual look and feel. My manager and I determined early on that presenting wireframes would be more acceptable than sending the client rough sketches.

At this stage, Alexandru Vilciu came on board the project to render my wireframes into high fidelity mockups for the client to review. PSHSA wanted a modern look and feel to the website while maintaining consistency with their existing branding. Alex was able to pull this off quite well by creating a new visual style based on the structure of the features I outlined.

We also had another designer, Seul Lee, who created mobile versions of each mockup we created. This was done to better illustrate to both the client and developers how the layouts and features would translate across different screen sizes. In cases where mobile elements were very different from the desktop version, such as the main navigation elements, I provided Seul with mobile wireframes to work from.

We created two separate but parallel InVision prototypes (desktop and mobile) which allowed us to easily present our concepts of how the features of the new website would look and work.

While working on the designs of each workflow and the various pages, I also had to consider how we might design a component library for the website. The website was meant to be built with a CMS (content management system) so that the client could easily update the pages as needed in the future. The developers chose an open source CMS called Apostrophe, which allows for custom widgets and in-line page editing.

I had to dissect my design concepts into individual components, which would become the repeatable widgets in Apostrophe for use across the website. I created a list based on the designs I had made so far and other examples I had found during my content analysis of the existing website. I used a spreadsheet to keep track of each component throughout the phases of sketching, wireframing, and high fidelity desktop and mobile mockups for developer handoff.

Additionally, Alex and I determined a responsive grid system for how the components would fit together on the page, and how they would translate across different screen sizes.

Some of the components required prototypes of a higher fidelity than InVision to communicate our design vision properly. For example, the search bar in the main navigation had a finer interaction that what InVision was able to convey through the use of static mockups. I looked into other tools and decided to try Proto.io, since it had prototyping features without requiring coding. See the video below for how I was able to demonstrate my vision of how the global search functionality would work:

Video recording of the prototype in action.

Thanks to this prototype, the developers were able to build out the feature exactly the way I intended, and I was able to provide them specifications such as the timing of the transitions in the animation.

Usability testing

Once we had made significant progress on the design, I had some concerns due to the lack of user research in the design phase of the project. My manager had left the company and I was now responsible for UX on this project. I proposed conducting a usability study with end users of the PSHSA website in order to verify whether our new workflows were indeed an improvement over the old ones and ensure that users were able to complete core tasks effectively.

The client again helped us recruit participants for the study. Over the period of about one month, I conducted usability tests with ten participants. Two of them were past customers of PSHSA (one from the healthcare sector and one from the fire sector). Other participants included three customer service representatives, four field consultants, and one internal user from within the organization. Having a diverse set of participants proved beneficial as they were able to bring up different perspectives on the website that I would not have had insight into otherwise.

Before beginning the study, I wrote a script outlining how each session would run. I used task-based usability testing to assess the usability of a few common workflows. I prepared three tasks in our InVision prototype:

1. Finding a specific course on the website and filling out the participant registration form;
2. Locating a specific resource (PDF of a poster) on the website and downloading it;
3. Rescheduling the previously purchased registration to a different available session.

I ran each session in the form of a remote moderated usability test. Conducting the sessions remotely allowed me to be more flexible in terms of scheduling (both for myself and the participant), and it was a faster option as I would be able to run them from the office instead of trying to meet the customers and consultants all across Ontario. I used a tool called Lookback to connect with each participant, beginning by speaking with them via video call and then switching to screen share for the duration of the test. By moderating the tests myself, I was able to ask follow-up questions when I wanted to know more about the reasons behind a participant’s behaviour on the site and have interesting discussions to glean further insights.

After completing each test, I sent the participant a link to a survey where they were able to anonymously provide further feedback on their experience.

I captured all my notes from each session in an ongoing Google Doc, and later segmented those notes and transferred them over to a spreadsheet. By reorganizing the notes into a matrix of general categories (tasks/questions) per participant, I was able to more easily analyze the results and determine key areas for improvement on each workflow/section of the website.

I was able to integrate many of the usability fixes into the design on an ongoing basis, in collaboration with Alex. I collected each of the usability issues discovered throughout the test into a report, which outlined the issue (along with a screenshot or video), an indication of the severity of the issue, and a proposed solution. Some of the fixes did not fit within the scope of the project, but I included them in the report for the client to have for future reference. The report also included the results of the survey and a list of frequent comments.

Development

As more developers came on board to the project, I maintained regular communication with them to clarify the design concepts and work together on determining the finer details of some components.

One of the big steps I took early on was to capture all of the features we had designed in the form of user stories. I stored each user story as a separate ticket in our project management tool (GitLab), including links to the InVision mockups for each feature and details on the implementation. This gave the developers an easy way to see all the features to be built out and provided them a baseline from which to break the user stories down into smaller pieces of work.

Once the production environment was up and running with the Apostrophe CMS, I also began migrating pieces of content from the old website over to the new one. While certain elements of the website were automatically migrated from WordPress, others had to be manually transferred over. I conducted an in-depth review of the old website’s site map to identify what needed to be migrated, which was then handled by one of our UX interns, Krisika Suthan, along with myself.

Later on in the development process, the developers began to identify some gaps in the workflows from the original designs and new edge cases that Alex and I hadn’t considered previously. Another UX intern, Ryan Tabula, created new designs to fill in the gaps (as covered in his case study) and I provided him regular design feedback as he worked on each feature.

There were two other key ways I helped developers throughout the project. The first was in the form of design QA (quality assurance). While we did have a QA analyst on the team who tested all of the features the developers worked on, I regularly conducted additional testing to make sure that the developers were executive on the designs the way the designers (Alex, the interns, and myself) intended. I logged the issues I found as new GitLab tickets and in some cases provided further specifications or even CSS rules to the developers.

The other key action I took during this time was accessibility testing. The new PSHSA website would have to meet the standards of the Accessibility for Ontarians with Disabilities Act (AODA), which includes a subset of the Web Content Accessibility Guidelines (WCAG). As the developers launched new pages and features, I tested them to ensure:

1. All features are accessible using only a keyboard;
2. Focus is visible at all times when navigating with a keyboard and there are no issues with the focus order;
3. UI icons and imagery have alt text.

I logged these issues as GitLab tickets, the same way that I did with the design flaws. In some cases I even pushed code to make sure that it would happen — for example, I used some basic HTML and CSS to add a “Skip to Content” component to the navigation that would only appear if the user was using a keyboard, and would allow them to skip all of the navigation menus. Since we used mega menus to allow users to navigate the large amount of content on the website, users would be forced to tab through each of those links if that feature was not present, which would not only take a long time, but would cause physical strain on users’ hands.

Lessons learned

There were many things I learned from project, especially around defending my designs to stakeholders and collaborating with developers to come up with solutions that meet user needs while being technically feasible within the constraints of the project. Some of the top lessons for me include the following:

Scope control

As designers, we have a responsibility to make sure that the solutions we design are feasible and realistic within project scope. There were many ideas that came up early on in the Discovery Session that unfortunately did not make it into the final product, and I had to learn to manage my own ideation within what was within the realm of possibility.

Managing different voices, opinions, and needs

Throughout the project, I had to balance three key factors: the needs of PSHSA’s end users, the business needs of the client, and the capabilities of the developers within the timeline and budget of the project. The key thing I learned here was when I could compromise on the requests of stakeholders and developers, and when I needed to push back to defend the usability of the website.

Accessibility needs to be built-in from the beginning

One mistake we made was that there were no accessibility considerations in the project planning. I learned a lot about the AODA and WCAG rules on my own and tried to work them into the project as much as possible, but it would sometimes cause rework for developers which led to frustration from all sides.

These lessons stayed with me throughout my time with Focus21, and on other projects I continued to find ways to involve developers earlier on in the design process and streamline design and developer collaboration.

The redesigned PSHSA website launched in Q2 of 2019, and it was great to see my team’s hard work go live to the public.