Table of contents

• Introduction
• List of UI considerations
• Final words

est 9 min read

Introduction At Sitecore and Templafy, my work covered user interface, user experience and accessibility design. Most of my time spent was striking balance between all these 3 areas.

This is why my work is inclined towards to design systems and cross-platform usability. Below I am going to share a list of considerations that I learned while working in these two organisations interfaces.

List of UI considerations

→ UI Localization Software localization is a project. Along with accurate translations, a software localization project involves dozens of other processes that adapt the user interface for a global audience. A localized UI means an improved user experience and accesible for everyone.

While accurate translation management is first step when ****localizing software, I also need to consider overall design and changes to the user interface. My goal is always to create accessible software that looks and feels as though it’s been specifically designed for the end-user, regardless of where they’re based or what language they are using.

Many companies cut corners when it comes to UI localization, instead focusing on rudimentary software translation. Neglecting elements like icon placement, typography changes, and sizing is a recipe for any localization project to failure.

My considerations:

• date formats when adapting a UI for new territories (MM/DD/YY, DD/MM/YY, YY/MM/DD)
• differences between left-to-right and right-to-left languages and button icon placement
• truncating text after user switches to another language can lead to poor user engagement
• thinking in dynamic layouts
• if you start your UI without localisation from the beginning then prepare to for a very long tedious process in the future
• localization is something you decide if you're doing at the start of the project
• non-latin alphabets, Japanese glyphs, German…
• using a Figma translation plugin to translate UI screens early in the design process

→ Font sizes and other browser settings: px vs rems Designers and developers often discuss whether to use px or rems. While designers typically use px because it's familiar, thinking in rems is mandatory for creating accessible and scalable UI designs.

Using px can cause accessibility issues by overriding users font size preferences in CSS. Each browser has a default root font size, usually 16px, which users can adjust. If our UI is built with pixels then it will get funky if users use a different root font size.

In the future, all SaaS product designs will likely need to use rems for scalability. Some designers may not be familiar with this approach, so for me it's important to educate team members. Building the design system components with rems can help address this issue partially.

Sometimes developers convert from px to rems during handover, but this adds extra work. Figma introduced support for designing with rems in 2023, making the transition easier.

My considerations:

• i use px when I want the size to be fixed but using rems/em when I want it to be adaptive to the scale of the system
• fonts using px wont re-scale if you change font size of the system
• if I use rems or em their size will change which adds accessibility for people that have harder to read
• rems is best for sizes and spacing, em is best for media queries ****- designers can keep doing mock-ups in px and the conversation to rems is something I could do with the code components in the design system

→ Dealing with responsiveness When working on a large UI with many components, handling responsiveness can be complex. For me it's important to streamline this process to avoid constant reinvention. Designers should be involved in discussions about responsive design and educate themselves on the topic.

Having a shared solution for responsiveness benefits both engineers and designers. In one of our projects, we used Every Layout, which offers patterns and techniques for building responsive layouts, including grids, flexbox, and responsive design principles. It provides examples and code snippets to help both developers and designers implement these techniques.

For a UX designer, I understand that this approach may be new. As we are used to create new Figma screens of “how will look on mobile?”. Add extra time for a designer and doing so is not scalable when working on complex UIs. In my previous experiences I assisted my design team by visually demonstrating how to create responsive interfaces and facilitating communication with the development team by helping designers thinking like a developer.

My considerations:

• the layout techniques should be scalable, meaning they can adapt to different screen sizes and devices
• by following layout patterns you can maintain consistency throughout your UI design
• have ready-to-use solutions and code snippets for common layout challenges
• dev should provide visual support to UX designers who are not familiar how CSS works