As part of the redesign of the LegalySpace SaaS tool, the challenge is to provide an optimal experience for premium users (agencies, businesses, etc.) on desktop while ensuring smooth navigation for freemium users (temporary workers, employees, etc.), who mainly use mobile devices. This article outlines the key steps and concrete examples implemented with front-end developers (Vue3 / Tailwind) to address these challenges in the context of a responsive website.
1. Understanding Users and Their Needs
Before diving into any responsive design work, it’s crucial to understand:
- Who are the users? (Paid vs. Freemium)
- What devices do they primarily use?
- What are their primary needs?
In our case, premium users on desktop often use large screens for long periods to complete complex tasks, such as managing contracts or tracking hours worked. Freemium users, on the other hand, access more limited but essential functionalities on mobile, such as viewing and signing files. Their sessions are shorter, and their attention span is lower.
Certain functionalities are nearly identical for both user groups, such as time entry or document signing. However, some options are only available to premium users. Using tools like Google Analytics and Hotjar, I delved deeper into the screen resolutions of our users, which ranged from 1366x768 to 1920x1080 for desktop users and 360x800 to 414x896 for mobile users. Tablets accounted for only 1% of tool usage.
Interestingly, while mobile usage represents the majority of our users (68%), desktop usage involves our most important users—our clients—making desktop just as important, if not more so, than mobile. Thus, we have two very different use cases, both crucial to the LegalySpace tool.
2. Representation in Figma for Responsiveness
Defining Critical Breakpoints
One of the key principles to follow is defining critical breakpoints—those moments when the design must adjust to meet the user’s specific needs. For instance, as mentioned earlier, many users still work with HD screens (1366x768px minimum). As a result, Tailwind’s “xl” breakpoint, used for screens over 1280px, became our most critical guide for desktop interfaces.
A specific challenge I encountered during a project in healthcare was the widespread use of screens at 125% zoom, which drastically changed the interface’s appearance. To tackle this, I created a Google Sheets table to map out most use cases and their associated breakpoints.
You can copy and get this Google Sheet file if you need.
Using Breakpoints in Figma
Tailwind CSS provides default breakpoints for five common screen sizes:
- sm: Small screens (min-width: 640px)
- md: Medium screens (min-width: 768px)
- lg: Large screens (min-width: 1024px)
- xl: Very large screens (min-width: 1280px)
- 2xl: Ultra-wide screens (min-width: 1536px)
These breakpoints are based on minimum widths, meaning styles set for a breakpoint will apply to all larger screens. Translating this into Figma involves setting up responsive grids for each width, ensuring perfect alignment between design and development. Here’s how I did it:
Creating Screen Sizes
After defining each screen size (sm, md, lg, xl, 2xl) as variables, I created frames in Figma for each size. Based on the analysis of user devices (from Google Analytics and Hotjar), I defined three critical breakpoints—none, sm, and xl—and focused on them.
Creating grids
Grids are a solution for applying responsive behavior to Figma screens. For this project (Design System for a LegalTech Company), I defined column numbers for each breakpoint: 12 columns for desktop, 8 for tablets, and 4 for mobile. I also set consistent margins (24px for tablet/desktop, 12px for mobile) and defined the type as “stretch” with auto-width.
3. Leveraging a Design System
The design system created as part of the redesign has been essential for adopting responsive design rules and ensuring consistency between designs and their implementation.
Responsive components
The components created in Storybook have a defined baseline behavior. For example, input fields take up the entire available width, which aids in mobile input. Toast notifications have different animations for mobile and desktop, and the stepper is more minimalist on mobile to save space. With these behaviors documented and integrated into the components, part of the work is no longer repeated with every project.
Layout Models
After breaking down our standard pages, layout models were defined and implemented as components. These layouts handle the positioning and display rules for the main UI elements.
For instance, the “StepperModel” integrates a two-column layout on desktop with the “full” version of the stepper component on the left and the main content on the right (Title + Main). On tablets and mobile, the stepper switches to a single-column version, along with the main content. Another example is the “ListModel,” our primary table view. Powered by the “Table” component, the number of columns varies depending on the screen. On mobile, freemium users simply click on the row to access their document; on desktop, paying users need to track additional indicators and information. Additionally, main actions are always placed in the top-right corner on desktop, whereas on mobile and tablet, they are moved to a “footerActions” component, making input much easier. Once all page models are defined and created as components, the main responsive display rules are automatically applied.
4. Best Practices to Keep in Mind
Prototyping and Testing
Testing is crucial to ensure the interface works across all devices, especially mobile where tactile interaction is key. Figma allows you to preview designs in different breakpoints and validate layouts in real-time. Using Figma’s prototype mode, I could test flows directly on my phone, simulating touch interactions and some scrolls. Storybook also enabled testing of interactions (modals, toasts, actions) without business context, ensuring a more realistic test.
For example, during the design of a mobile form, testing the Figma mobile prototype through the app revealed that some interactive elements were too small. A revision of the clickable areas was therefore necessary.
Considering Touch Surfaces
Without action, interfaces lose their utility. Buttons and clickable areas must be large enough to be used comfortably on mobile. A tiny “minuscule” button can frustrate users, leading to rage-clicks, and potentially derailing the entire design. It’s crucial to respect accessibility guidelines and ensure clickable areas are appropriately sized.
According to a 2007 study, the ideal size for touch interaction buttons lies between 42px and 72px. Based on this, we set the minimum size for interactive elements in our interface to 42px. Here are examples of affected components:
| Component | Height |
|---|---|
| Input | 42px |
| Button | 42px |
| Chip | 42px |
Prioritize Content
As the design system and SaaS overhaul progressed, new processes about content began to emerge. For example, during data-entry screens, determining which fields were essential and which could be omitted in mobile view made navigation more user-friendly.
Performance Optimization
Certain screens can contain a large number of filter variables. Reducing the default number of displayed variables and managing the loading of additional variables during scrolling improves usability. (For instance, in “My Documents,” the “Partners” filter can include more than 200 variables in some cases.). Finally, prioritizing HTML elements in the creation of our Design System components also helps minimize code and enhance display performance.
Conclusion : Loss of Control
In the world of design, perfection is overrated. With the increasing variety of screen resolutions, designers must embrace a level of imperfection. The mantra I followed throughout this project was to let go of pixel perfection. Interface elements should be dynamic, adapting to their environment. Trying to maintain too much control is counterproductive and complicates both design and integration. So, let’s embrace the chaos of multiple breakpoints and let our designs adapt—just like the users themselves.