Case Studies
Note: my current workplace has very strict security standards, so I’m not permitted to show any work in a public space. All of these examples have been completed on my own time outside of work hours. What I can tell you are the names of some of the clients I’ve done work for at my current position:
- RBC Bank
- TD Bank
- Bank of Nova Scotia
- Canada Life Insurance
- Canadian Tire Financial Services
Beaches Wellness Centre: Research
2021
Beaches Wellness Centre is a well-established chiropractic and registered massage therapy clinic in Toronto’s Beaches neighbourhood. As one of their patients, I went to leave a voicemail for them one day, but first wanted to double-check their hours to make sure I wouldn’t be bothering them right at the end of the day... and discovered they didn’t have a web site.
Since I needed portfolio work I could show in public without violating my employer’s security regulations, I asked if I could make a web site for them, and they agreed.
Overarching constraint: COVID caused a lot of restrictions on physical space and time. The clinic’s waiting room was shut down; patients had to wait outside the building before their appointments. The clinic’s volumes also went up, so time to meet with the stakeholders was minimal. It wasn’t unusual for the clinic owner and I to talk about next steps during my appointment, simply because it was the only time we had to discuss anything with each other.
The Problem
After some discussions, the proposed site’s goals were determined:
- Feasible: the site must be low-cost to create and maintain.
- Accessible: although the business does not fall under AODA regulations, it made sense to implement WCAG 2.1 AA accessibility for a brand-new site.
- Ease of content management: After initial implementation, the clinic wanted to be able to update the site themselves.
- Responsive: The design had to be mobile-first, but also support tablet and larger-screen visits.
A brief was created which listed the project goals, constraints, major deliverables, and other major details.
Research
Research focused on three topics:
- Competition: what do the websites of the other clinics in the neighbourhood look like? what content do they have?
- Existing patients: what do the existing patients want in a website? What would they find useful? (Note that nearly all clinic patients are referred by word of mouth, so existing patients are considered the primary audience for a site.)
- Information architecture: in what order should the website provide the content? How should information be grouped? What are the major content topics?
Competition: I created a competitive analysis of 13 different clinics, mostly from the neighbourhood, a few in adjacent communities. The analysis noted the purpose of the site, the colour scheme, the main menu items, the core content, what services are offered, and whether or not the site had been updated recently.
Chiropractors are not allowed to compete against each other directly (ie: they can’t say anything like, “Best in Toronto!”), so it was important to find out how to stand out in a way that complied with professional standards.
The analysis revealed that there were two major ways to both stand out as a website and to comply with the standards:
- Choose a colour scheme which wasn’t the same as the other sites, which tended to draw from a limited set of pallettes
- Order the information in a way that appealed to patients
Existing patients: I decided to take advantage of the restrictions COVID had placed on patient access, and use the time waiting outside for appointments to talk to other patients informally and learn what they expected from a website. Sometimes we would look at competition websites together as well.
Information architecture: I used Optimal Workshop (external link) to create a card sorting exercise, based on the most popular menu items revealed in the competitive analysis and topics patients had mentioned. Patients were invited to complete it, and to share the link if they wanted. This gave me enough data to determine the major content for the website, and in how it should be organized.
The User’s Needs & Pain Points
The patient interviews and card sorting revealed the following pain points and needs:
- They didn’t like having to scroll through multiple screens’ worth of therapy descriptions just to find out a clinic’s office hours or contact information.
- It was too difficult to find out the clinic address. Many existing patients only visit once every several months and so don’t have the location memorized.
- Patients weren’t confident they would understand therapy descriptions from a website, and were more comfortable simply discussing them with someone at the clinic on the phone or during an appointment.
Key Design Decisions
The research led to the following major design decisions:
- It confirmed that mobile-first was the best way to go — many patients just assumed they would be using their phone to access the site, and that they would be using the site en route to an appointment, or when they were otherwise not at home.
- Patients strongly preferred a one-page layout, so they could thumb-scroll over using links or another navigation method. If they clicked to another page on a sample site, they would try to scroll back to home rather than clicking on the Home link in the menu.
- Each screen’s worth of information should be tightly-focused and kept to a minimum. Patients didn’t like a lot of content on a screen at once.
Reflections
- The conventional wisdom is to sell a small business by showing the products and services available, and then list the contact information/book an appointment as a call to action. The patients I interviewed preferred to find out the contact information and location first, and then contact the clinic to determine if the services fit their needs.
- It was noted in the brief that minimal content was preferred by the stakeholders, but the patient interviews indicated content and layout should be even more minimal than previously supposed. Rather than read about the available services on a website, patients reported they would rather have a discussion about it in the context of their personal state of health.
Beaches Wellness Centre: Wireframes & Testing
2021
Research
Having established a creative brief and conducted user research in the first phase of the project, I still needed to research UI elements before I started sketching mock-ups.
Colour scheme: the competitive analysis from the Research phase showed that most competing local sites used blues, greens, oranges, or greys as their major colours. The stakeholders and I both searched independently for inspirational sites to get ideas for a colour scheme, and both of us brought forward different sites with a black & slightly off-white colour scheme with dark gold accents.
Navigation elements: the two menu options for mobile were a hamburger menu, or a button bar at the bottom of the screen. The stakeholders and I agreed to conduct A/B testing to determine which was best.
The User’s Needs & Pain Points
By focusing on the data and the research results, very little elements were left up for discussion. Most choices can be traced back to the user research, competitive analysis, and the original brief from the stakeholders.
- Key information for the home page was identified during the interviews.
- The results of the card sorting exercise are used to drive the content organization.
Design with Constraints
In addition to the constraints already identified in the brief, the research phase identified additional constraints:
- Create the mobile wireframes first, then the tablet and large-screen views.
- Since design had to accommodate content updates, structure was created first, then content.
- To ensure that the design fit on all screens, smaller/narrower options for each screen type were selected in Figma. For example, I used an iPhone 11 as the sample phone size because it was the narrowest mobile screen available.
Ideation & Wireframing
Organizing information: before any design occurred, the content (or its placeholder) was organized into groups according to the card sort results.
Mini design system: a very basic design system was created with Rangle.io’s Radius (external link) Figma template. The Figma template let me ensure the colours, text styles, and other elements were accessible and usable before creating the wireframes. It also let me apply already-created styles in the wireframe project without having to work through them as the wireframes were created.
Collect assets, create responsive grid: I based the grids on samples I have collected in Figma. The icons came from a library from the Figma community. I couldn't find an image placeholder icon that could easily integrate the site colour scheme, so I created my own in dark and light versions. That way they wouldn't distract the stakeholders or test users when they were reviewing the designs.
And with that, it was time to iterate, review, and validate.
Key Design Decisions
Gold text is tricky to implement because it’s in the medium range for hex values and it can be challenging to find sufficient contrast to meet WCAG 2.1 AA standards. This was mitigated by using slightly different shades of gold against the black and white backgrounds to ensure each background had sufficient contrast.
The About section has three subsections, which makes it the longest section. Research indicated it would also be the least-visited part of the site. Therefore, to keep the menu short and simple, the subsections were removed from the main menu. Links at the top of each About subsection allow vistors to navigate quickly within the main section.
Test & Review Solution
After a few initial review rounds with the stakeholders, two versions of the interactive wireframes were tested with patients:
- Hamburger menu: the traditional hamburger menu was shown at the top of the mobile view, with a menu drawer which appeared when the visitor tapped the hamburger icon.
- Button bar: a button bar was added to the bottom of the mobile screen, with only the major sections (Home, News, About) shown as buttons.
I made a temporary “secret” link on each version of the home page so that testers could switch between the hamburger menu and button bar solutions easily, showed the vistors how to switch between the two solutions, and asked them to find different sections. The testers also read through the wireframes while chatting with me informally (essentially guerilla testing).
Reflections
There were never really any major showstoppers in the process because the business owner and other business stakeholders were kept informed throughout the process. The only time I did an experiment on my own was when I redesigned the home page, and even then the feedback loop was strong enough that they were able to choose from the samples I made quickly so we could move on to evaluating the update with guerilla testing.
Using the Radius mini-design system let the stakeholders and I build up a set of design conventions which complied with accessibility standards very quickly and easily.
The interactive wireframes are available on Figma in three screen widths:- mobile (external link), the size most likely to be visited
- tablet (external link)
- desktop/laptop (external link)
This Site: Semantic HTML & CSS
2021
I consume a lot of media about design commentary. Every week I receive nnGroup’s AlertBox newsletter, listen to a couple of podcasts, and read some articles, not to mention attending webinars. Before the pandemic, I was a regular attendee of the local Design System Meetup, and still attend online.
One recurring theme I noticed was warnings about not using overly themed, overly “off the shelf” portfolio designs. Usually the author would state it was all right to start from a template, but if you didn’t personalize it... well, what were you showing people about what you could do?
Not only did I completely agree with that, but I also have the challenge that the strict security I work under means I can’t show anything that I have actually worked on from work unless it has been made public (and since we are overwhelmingly B:B in our focus, none of it has been).
It was also important to me to write everything from scratch. Don’t get me wrong, I’ve used a lot of Bootstrap (often with React) at work, but it seemed to me that a Bootstrap site just proved I knew Bootstrap. I wanted to show how a site looked if I wrote it from scratch.
Besides, it sounded like fun.
Research
The first thing I did was look at a lot of people’s design portfolios, and at a lot of portfolio templates. I didn’t want to use any of the templates directly, just get ideas for how to organize and present the information. I also conducted a self-branding exercise with some trusted colleagues. We all did our own profiles and then critqued each other’s work.
I then outlined how I wanted the portfolio to look and how I wanted to approach the work.
The User’s Needs & Pain Points
In the past twelve months, I’ve been involved with hiring two additional UX designers, reviewing resumes and portfolios, and conducting first-round interviews with another team member. I was grateful to see so many different approaches to constructing a portfolio, and to gather data points for what I wanted to show in my own portfolio:
- accessibility as part of the foundation, not an afterthought
- minimal shortcuts & other people’s work: style kits like Bootstrap and template platforms like Wix are great for speeding up projects, but not for showing what you know
- product attitude: this is a product like any other I’ve worked on, and has gone through iterations like anything else I’ve done in a team setting
- process and impact: ensure the process was both clearly stated, and clearly demonstrated
- include a team: since on a real project I would be working with a team and receiving/incorporating feedback, I created a team of “stakeholders” from a group of peers — we critique and help each other regularly.
Design with Constraints
For my portfolio, I wanted:
- HTML with a clear structure, both to make it easy to meet WCAG standards and to make it easy to update and maintain
- CSS that was easy to maintain and apply (with no surprises)
- reasonably fast performance, because I’ve noticed that a lot of portfolios are so graphics-heavy they perform poorly
Ideation
The site you’re looking at now was inspired by three different portfolio templates. Instead of just blindly copying & pasting code, I wrote all the semantic HTML myself, using the templates as visual guides.
Key Design Decisions
Structure
- The CSS started with a copy of the classless mvp.css (external link) template, which was then expanded and updated to suit the content and theme. The advantage of using mvp.css as a foundation is that it strongly encourages the use of semantic HTML, that is, HTML whose tags largely indicate the purpose of each tag set (as opposed to, say, just using <div> tags for each content block.
- Semantic HTML also makes it easier to meet WCAG accessibility standards, since that’s that WCAG includes in its standards.
- I decided to keep all the content in one long page, rather than having users flip back and forth between the main page and each case study. It does make for a long page, but the navigation lets users skip from section to section, and people who want to read all the content can simply scroll.
Look & feel
- The section, button, and link colours are all based on the entry page conceptual image (a photo I took at a Winter Stations festival).
- Margins, spacing, and letter/word spacing added whitespace without sacrificing readability.
Validate Solution
- reviewed each iteration with my “stakeholder” team
- checked on multiple devices for responsiveness
- tested all interactive parts on multiple devices
- checked against accessibility checkers
Reflections
Now that the main structure has been set up, I can focus on more (and more interactive) case studies. There are already two in the works.
