Homepage Link
Michelle Lana Visual Designer

Cupcakes for Everyone Cupcakes for Everyone Cupcakes for Everyone

What's the story

As part of the mentorship program at our organization, we had the option to choose a topic or specialized field and partner with a mentor. I teamed up with three of my other colleagues and combined our learnings from our accessibility specialist/mentor to build a website using inclusive design principles.

The Challenge

Our challenge was to create an accessible one-page website built with inclusion in mind to ensure that everyone can access, navigate and order online.

Our high level goals were to:

  1. Coordinate meetings with different teams in the organization and gather feedback from staff.
  2. Use our studies and data to help move people from awareness to action around accessibility and share across different teams in the organization.
  3. Create a product that would serve as a learning tool for different teams in the organization.

Process

  1. Define product vision

    Understanding what problems we are solving for users

  2. Design

    Expand ideas on visual, interaction, motion design, writing

  3. Testing

    Talk to users and get feedback, including people with disabilities

  4. Development

    Decisions on the design stage pull through final product

  5. Verify: After development

    Check for common issues, get feedback from users with disabilities

My Role

My Role

Visual Designer and Project Lead

Tools Used

Adobe XD, Adobe Illustrator

The Team

2 UX Designers, 2 UI Designers

Duration

One month

My Key Contributions

Concept Ideation, Strategy and Vision, Research, Presentation, Accessibility Annotations, Screen Reader testing for Mac Desktop and iOS Mobile

Stage 1: Define Product Vision

Users and Audience

Thinking about our users and who they could be is essential for our project. We had access to team members in the office, but we also wanted to bring different perspectives to the table.

I thought about my friend, Savan, who has been blind since birth. He loves to sing and play the piano. He would often go to these random sites to order gear for his musical gigs. I always wondered how he felt when websites didn't have the proper semantic markup whenever he ordered something online. What can we do to make our products accessible for disabled users like Savan?

“What can we do to make our products accessible for disabled users like my friend, Savan?”

Research

We Are Not Our Users

Our goal was to talk to diverse users, including users with disabilities, and include that into the process right from the very start. To evaluate our user needs and pain points when ordering online, we talked to a friend who uses a screen reader. For example, based on our research with users using screen readers, many blind or visually impaired users can type fast on the on-screen keyboard, but not all blind users can.

Here are the three options for typing:

  1. Direct touch typing: similar to how sighted people type
  2. Touch typing: press a key and release to activate
  3. Standard typing: doublt-tap each key or character to activate

Questions we asked:

  1. Direct touch typing: similar to how sighted people type
  2. Touch typing: press a key and release to activate
  3. Standard typing: doublt-tap each key or character to activate
“We used the persona spectrum to describe a user going through specific lenses of constraint.”

Personas

Inclusive Personas

We used inclusive personas to guide our design decisions and leveraged the Inclusive: A Microsoft Design Toolkit. We used the persona spectrum to describe a user going through specific lenses of constraint. This was an essential step in understanding how a constraint might affect designs for a digital solution. We also talked to several team members with glasses and asked the same questions when ordering online.

A few notes on what we did:

  1. We used 4 different personas to facilitate discussions about our users' needs.
  2. We identified variables and focused on our users' constraints to develop a clear picture of who the site's design would target for our initial launch.
  3. Since we only had one disabled user to test our site, the persona spectrum was a great way to illustrate necessary additions and look at our challenge in a new light.

Designing for Everybody

The Approach

To truly design for everybody, we must think more broadly, reveal bias, and uncover potential areas of exclusion. We needed to consider how a user will interact with a feature and what assumptions and learnings will contribute to the final output. With this in mind, we scheduled discussions with other teammates, managers, and staff, especially those not like us, to bring a different perspective to the table.

We used a mapping exercise to help spot bottlenecks and identify areas of pain points throughout our customer journey. Even if we only had a one-page site to test, we wanted to fully understand our user's needs when ordering online using screen readers. Mapping out our user's emotions and pain points was instrumental to our efforts.

Stage 2: Design

Visual Process

Designing with Accessibility in Mind

Before I even start opening up my favorite design tool (Adobe XD), I always make sure that I design with accessibility in mind. I worked with our UX team member and I started making a numbered list with pen and paper and wrote out the page structure.

Numbered list page structure:

  1. section headings
  2. content and function of each image
  3. text of each link
  4. text of each button
  5. name of each form element

Our site leverages the principles of universal design which helped me conduct a text-only design exercise to help clarify the content and order of the page. This was an essential step as it will help me explain the page goals to our team member, Sarah, who will be handling the development in HTML/CSS.

Visual Thinking On Paper: Who Else?

If we continue to ask ourselves, who else? We expand the possibilities of our ideas. I always start with paper and pencil to bring my designs to life. Since we were focused on a one-page site, this gave me plenty of room to illustrate sketches for the cupcake site.

Hi-Fidelity Mockups

I started creating the branding elements and illustration pieces in Adobe Illustrator to move forward with the design. After I had a look and feel down, I moved over to Adobe XD and created a quick style guide to capture styling elements such as color, typography, buttons, links, icons, and, most importantly, accessibility annotations. Providing a style guide and additional accessibility notes is essential during design-to-dev handoffs.

“It is always essential to identify the assumptions that we have built into any product we design.”
Stark, I love you!

Before handing off my visual mocks and style guide for development, I always make sure that I fire up Stark. Never assume that your color combination is good enough. It is always essential to identify the assumptions we have built into any product we design. If someone is color-blind, they should still differentiate between distinct elements of your design. I used Stark to test the page to simulate colorblindness to see what the site would look like for folks who are colorblind.

Interaction Design

Ensure that related content and controls are grouped together. This will make it easier to understand and easier to reach people with motor disabilities.

UX Writing

Guide all users with accessible on-screen text. Write accessory labels and be a champion for screen reader users.

Motion Design

Try to ensure that alerts like snack bars are present on the screen long enough so that everyone can see them and have an option to easily dismiss them.

Stage 3: Talk to Users

Testing and More Testing

Ideate With Lens of Inclusitivity

We did not want to forget about getting some feedback from our users to check and see if we are on the right track with our designs.

Questions We Asked

  1. Are the buttons clear for low vision users?
  2. Are the controls easy to press and navigate?
  3. How's the content? Is it readable, legible , and easy to understand?
VoiceOver

I tested the cupcakes site using VoiceOver on the desktop using just my keyboard and the basic VoiceOver commands. I quickly went through the site using keyboard shortcuts. Next, I did the same VoiceOver test on my iPhone, which I believe is easier to do than testing it on the desktop.

“In hindsight, we should've done an empathy immersion exercise while testing using Voiceover. I should've put myself in the shoes of the people for whom we are designing.”
Who Are We Designing For?

As a sighted user, testing the layout of the one-page site was simple enough to understand. But, we wanted to challenge our assumptions, and this is why it was essential to test our product with disabled users to recognize ways that users with disabilities may wish to navigate the web. In hindsight, we should've done an empathy immersion exercise while testing the site using Voiceover. I should've put myself in the shoes of the people with and for whom we are designing, for example: (testing the site on my phone blindfolded or without glasses). This exercise would've opened up more opportunities to understand what goes on under the surface and articulate the needs of what the users we are interviewing are experiencing.

Stage 4: Development

Semantic HTML

Discuss Constraints and Possibilities

I worked closely with our teammate, Sarah, who will be developing the site. Communicating requirements and discussing constraints and possibilities was an effective way of solving the overall design layout.

Stage 5: Verify/After Development

Testing Again

Cupcakes For Everyone

Our UX teammate who led the interview had a set of tasks for the participant to perform during the call. Unfortunately, we encountered issues getting ZOOM to work using Voiceover due to all the pop-ups and ensuring that our participant already had the ZOOM app on his phone.

Testing Disabled Users

Our participant revealed that he had difficulty locating the navigation menu on his iPhone. Unfortunately, we did not provide the correct mark-up for the responsive navigation menu, and thus Voiceover did not capture those links during the interview.

Call-to-Action Links

We also observed that the participant repeatedly asked for links and the call-to-action buttons on the page. He could locate the “submit” button, but he also wished there were other means to order besides clicking on submit.

“We should've properly labeled our button text to describe its purpose and destination (i.e., Submit Your Order vs. Submit).”
Location of Error Messaging

Our participant revealed that he had difficulty identifying the error message when he did not select a cupcake when he submitted his order.

Outcome and Impact

Reflections and What I Learned

We realized that we still missed a few crucial steps to make our product accessible, even for a simple one-pager site with limited features. We were confident that we had everything figured out, but we, unfortunately, failed to challenge our assumptions and recognize our biases and preferences. It is a great lesson to remember that we are not our users. Therefore, it is vital to include different perspectives and prioritize inclusion at critical points in the design and development process.

Key Takeaways:

  1. This case study now serves as a learning tool about accessibility and inclusion in our organization.

  2. The presentation we held for our UX team was a success and other teams requested to hear our presentation again.

  3. Four other UX team members expressed interest in doing more case studies around accessibility to help advocate for inclusion.

  4. We presented to two teams at our organization totaling 350 participants and growing. Our case study deck is now distributed within our company as a reference guide for creating accessible websites.

Making inclusive products is critical and we all have the power and responsibility to remove barriers and empower all users to be productive and connected.

Next Case Study

NFO Redesign