Designing to the Pixel Density of a Device - A Learning Experience
This is a version of a presentation I did for my UX Team. It went so well, I decided to convert it into a unique case study.
Today we are going to discuss how to design a native application to the pixel density of a specific device, rather than the physical screen size or resolution.
Agenda
Teach
How to use PPI and Resolution to determine design sizes for specific devices
Do
Learning sinks in best when we apply knowledge in the real world.
Enjoy
Stand in awe of your genius.
Story Time
Once upon a time… a LONG LOOOOOOONG time ago, before high-density displays came out, developers (designers too) were happy…
They were happy because, back then, 1 CSS pixel was equal to 1 hardware pixel.
Meaning (if the same were true today), if I were designing for a specific device, like an iPhone SE that has the physical screen real estate of 640 px wide x 1136 pixels tall, I could (in Figma) design on a 640 x 1136 wireframe pixel for pixel.
Fast Forward to 2023, where the pixel-for-pixel concept no longer always applies.
Let me set the scene for you
It’s not quite 2023, but November of 2022. This application is called ePSI. It is old and outdated. It is used by our Post-Sale inspectors to inspect vehicles and note any issues. I have been asked to take this ePSI tool (pictured here) and design an updated native app version of it to be accessed via TC75 phones and Zebra tablets. I am super excited about this project.
It started out smoothly.
I was stoked to work on a native application because I haven’t had a lot of opportunities to do so. I really wanted to make the app touch-friendly and easy to use for our inspectors. Getting to modernize such an old app was exciting for me!
I went to work on the TC75 screens using a mobile-first approach. It went relatively smoothly until after my designs were approved by the stakeholders.
Until I got to the Tablet Designs
It was time to design for the zebra tablets, specifically the 10.1-inch ET55 and ET56.
It’s important to note that I have a lot more experience designing web-based platforms and responsive web design is a lot different than native app design for multiple devices. In fact, native apps are so uncommon in our department, we only have 1 current native app developer working for my team.
I needed to better understand how the responsiveness of this app would be built.
What was I missing?
I tracked our engineer down, armed with a lot of questions. My most important question was “Did he have to develop 2 different native applications, 1 for the mobile and 1 for the tablet, or is it similar to responsive web design, where he can write 1 application and it will render on any size as long as it is designed to the grid and relevant breakpoints?”
The answer:
They typically reuse the code for mobile, but they have to build new UI screens to account for tablet sizes and rework some logic. Meaning they have to have 2 different apps, 1 for mobile, and 1 for tablet.
Tablet Screen Size Matters
The takeaway for me was… the screen size I use in my designs should be specific to the devices we are using and must be accurate in size in order to ensure my designs render exactly as intended.
Looking up the Specs
Initially, I thought I just needed to find out the screen resolution and design to that. I looked up the spec sheet for both tablets.
The resolutions for the tablets were 1920x1200 and 2560x1600. “That is massive,” I thought to myself. I have never designed a touch screen that large before.
I had this nagging feeling that I wasn’t using the right information
“What could go wrong?”
I asked myself. I decided to give it a try. I decided to try converting the mobile screen you see to the right of this text first to see how it went.
Unsustainable Customization
I started to build this screen in a 1920 x 1200 pixel frame for the ET55. I figured I’d start with the smaller one. You may not be able to tell by the wireframe to the right, but I had to customize/blow up every PRISM (our design library) component to make this touch-screen design even kind of work.
Look at the size difference between a normal button, and my custom built XXL button. It’s insane! I realized I was in for the longest design project of my life if I was going to have to custom-build every component we had just to fit on this giant screen. And I hadn’t even gotten to the 2560x1600 screens yet. What was I going to do?
“Is there a better way?”
— Me
The short answer is YES.
It took a ton of research and digging, reading highly technical articles written by engineers, and talking to mentors and engineers far smarter than I am, but I found it.
Some of you probably already know the answer, but some of you may not. So my goal today is to make this as simple and easy as I can for those who are new to this concept like I was. Bear with me, though. There are math equations.
Remember how we talked about 1 CSS pixel is equal to 1 hardware pixel.
That’s now always true anymore. The advancements in technology over the years have made things better but also more complicated. For example, physical pixels are not digital pixels.
Let's talk Pixel Ratio. Now that high-density displays are a thing, there’s a new parameter to consider — the pixel ratio — used as a multiplier to determine how many hardware pixels map to a single CSS pixel. You can see in the diagram here, 1 physical inch of a screen can have very different amounts of digital (aka logical) pixels, depending on the device.
Why? A higher density of pixels per inch creates a much clearer visual image. The more pixels per inch, the more detail and depth.