Ensuring accessibility with the workspace responsive design system

WriteWay Writer / 2021

screenshot of the writeway writer. There is a web version and a mobile version

About

Before the official launch of Living Sky Technologies flagship product, WriteWay Writer, it was crucial that the app was responsive for all screen sizes. I designed the Workspace Responsive Design system to outline the breakpoints and new tab system for Writer, to create a more accessible experience.

My Role

  • UX/UI Design

  • Research

The Team

I collaborated with my Supervisor (lead designer), one Front End Developer and two executive Stakeholders. 

WriteWay Writer Was Not Responsive

When this project began, WriteWay Writer did have a few breakpoints and some level of responsiveness. However, there were many inconsistencies and a refined responsive design system was not in place. During an extensive user testing session two colleagues of mine completed, several users commented on the lack of responsiveness - specifically for smaller devices. In fact, 7/12 participants commented on responsiveness issues they were having during the usability test.

But why is responsive design so important?

  • User Experience: It ensures a delightful user experience when people are writing and creating content, at any screen width

  • Accessibility: Not everyone uses a computer and not everyone uses a mobile device - having these options for our users ensures nobody is left out

  • Business Health: By having more options for our users, it drives more business and allows for scalability in the future

screenshot of the current experience of writer. The text box is cut off by buttons

The old breakpoints left little space to write content with ease.

Understanding Technical Requirements

To get a better understanding of the current breakpoints within the app and where there were gaps/issues, I had several discussions with the lead Front End Developer. From these discussions, the core requirements were broken down to:

  • Maintain the percentage-based breakpoint system for each Resize option (Context: In Writer, the user has five layout options where the proportion of the Document Editor and Idea Board is different for each of these options - Large, Sidebar, Split Screen, Fullscreen, Minimized)

    • For example, in the Large view, the Document editor is 67% of the screen width and the Idea Board is 33%

  • Outline the behaviour of the breakpoints for decreasing screen sizes, as well as increasing screen sizes

  • Implement padding adjustments when in smaller screen sizes to allow for more space in the Workspace and ensure the text meets accessibility needs

The Tab Design was not Mobile-Friendly

I began wireframing breakpoints for each of the layout options, but quickly ran into my first issue: The left and right tab system that was being used in the smaller screen sizes was not mobile-friendly and didn’t leave enough room for the workspace. I brainstormed alternate tab systems for smaller screen sizes and eventually landed on two concepts. However, both tab systems had their cons:

the hamburger menu design with a dropdown menu open

Hamburger Menu

Cons: The tabs are less discoverable being within the hamburger menu and may clutter the universal menu more with the icon.

the top bar tabs design with a horizontal menu across the top

Top Bar Tabs

Cons: Adding another menu to the top may overload the user and cause a distraction from the universal menu items.

Advocating for Usability Testing

In order to understand which of these concepts were most accessible to the user, I knew I wanted to conduct a Maze User Test. However, working at a startup company presented a challenge when it came to user research - it was not an integrated part of our design process and stakeholders were very involved in the process. Our stakeholders liked the hamburger menu design but I wanted to validate this concept with an unbiased group.

I presented a case to my manager explaining the value of testing these two designs with external users and we compromised on a lower number of testers. But I was able to successfully go ahead with testing the navigation design!

A/B Testing: Can the User Navigate the Universal Menu?

I conducted two A/B tests, each with 11 participants to test the usability of each tab concept - The Hamburger menu and the Top Bar tabs. The questions to be answered were: ​

  • Can the user successfully navigate to the various sections of Writer (Document Editor, Preview, Idea Board, etc) using the tab system?

  • ​Can the user navigate the universal menu (Resizing, settings, etc) with the new tab system implemented?

  • Does the user experience any frustrations while navigating the tab system?

Each test was set up with a different tab system but had the same two missions: ​

  1. Open the Idea Board (To test the usability of the tabs themselves)

  2. Open the Project Details (To test the usability of the Universal Menu with the implementation of the tabs)

screenshot of the Maze dashboard where I set up my research questions

Results: Top Bar Tabs Are Easier to Access

The data was proven to be quite insightful. It showed that the Top Bar design was easier for participants to access the Idea Board with 72.7% getting a perfect score of 1 click. This was likely due to the tabs being highly visible and not being hidden with a menu. 82% of participants rated the Idea Board mission with the Top Bar tabs to be "Very Easy" while only 55% of participants felt that way with the Hamburger Menu.

Going forward with the design, the Top Bar tabs were implemented to support better navigation for smaller screen sizes.

pie graph outlining the number of clicks needed on the idea board task for the top bar tabs
pie graph outlining the number of clicks taken to complete the idea board task for the hamburger menu

Handing Off Detailed Design Documentation

With the results from the user testing, the design system was refined to incorporate the tab system. The tabs were further refined to implement a horizontal scroll for when in small screen sizes, such as mobile. Padding adjustments were also implemented to allow for more room in the Workspace.

For design handoff to the development team, the extensive design system included visual breakpoints and examples In Figma for screen sizes from 2560px to 375px. Additionally, the written documentation explained behaviour, requirements and edge cases. 

Screenshot of the extensive documentation in Figma

I outlined detailed breakpoints and documentation for every layout option (there were five!)

Reflection: Advocate for User Testing

This project exemplifies the importance of advocating for user testing. Research doesn’t only need to be conducted when designing an entirely new feature or app concept that is completely foreign to the user. It can be as ‘small’ as testing two tab concepts that you need to learn more about. 

At a company where stakeholders are very involved in the design of the product, it was important for me to have user data to back up the decisions of the tab design and use to understand the needs of the user. Initially, the stakeholders favoured the Hamburger Menu concept but with the data from the user tests, I was able to advocate for the more intuitive design.