When I joined the Wisephone project as UX Designer, I had very little experience in the Android development space. Not only had I never built an app before, I didn’t fully comprehend the process for passing my designs off to developers. How would they interpret my designs for their builds? I sought out to answer this question first as a foundation for future app development.
The apps were mildly stable at that time, but we were making major improvements as needed in various locations, and it was becoming increasingly difficult for me to build a consistent UI. The previous designer had started in on some concepts of component-driven design but had inconsistently executed. Colors and fonts were defined for reuse, but other shareable points like margins were sporadic at best. I began to question everything. I scrutinized the design from every angle.
The first question I had was how big to build each phone screen. Figma, the design app we were using, has its measurements shown without a label. I often use inches and pixels as my units of measurement within design apps like Photoshop and Illustrator, so I naturally started with that as a conversion point. But Figma doesn’t exactly work that way. When creating a new frame using their Android preset, Figma gives us a 360x640 window. I was baffled because the pixel size for the physical devices we were working with were at minimum 720x1560, nearly double the size of the template, and taller. Was I suppose to build my art to scale or at the template size, and what would be easiest for the developers?
I discovered Figma was setting up the designer to use a device-independent measurement unit called dp or dip, “density independent pixels.” Dp is used within Android development in order to assist with varying degrees of screen pixel density in translation between multiple devices. The 360x640 size is considered baseline size for most Android phone apps. It’s called the MDPI resolution, and is roughly 160 dots per inch. I say roughly because it all depends on the hardware really. An older tablet very likely might have an MDPI screen but the baseline size for that type of device might be 720x1280. Because the hardware is physically larger than the phone, it might be designed with these larger dimensions. But we’re just working with phones here.
All this said, our base model device was an XHDPI device, which ups the resolution of the art 2 times from baseline. We also worked with a 3x model for quite some time. By using Figma’s template, this would properly translate to the app development platform. It’s worth noting that the ambiguous Figma unit also works for Apple development, but in a much more straightforward manner since it uses scaled pixels of 1x, 2x, 3x, and 4x only. And finally, you can use Figma units for print: the unit translates directly to points size.
Second, I studied the space between objects, scale of icons, and font sizes. I couldn’t find a high level of thought put into this from our previous designer. What would be the easiest method to achieve greater consistency here?
Initially I explored margins of 10, 25, 50, and 100. Looking back, I see just how wrong this was. Developers encouraged me to explore using sizes that were divisible by 4. 4, 8, 16, 24, 32, 48, 64, 72, 96, became my new favorite numbers. These translated well to the code. This also put some design restraints that grew my creativity.
After researching our old layout and best practices, I landed on this for the main structure.
Last topic here but certainly not the last part to this project was how to create a repeatable approach to new screens. I pushed for a component-driven-design workflow. This is where every element in a screen is designed separately and brought in for the bigger picture. For me, I find correlations between this approach and web design: on a website, the navigation appears on each page and is likely designed as a component element and placed in dynamically for use on each page of the site. Same might apply for a site map, footer, and image assets. A developer wouldn’t want to manually place in the navigation on each page, otherwise, if a link is changed in the navigation, they have to comb every page of that site to update the link.
Figma allows you to create components out of anything. A component can be placed multiple times throughout a design, and updating the master component will update all the duplicates at the same time.
For the phone redesign, we created components for every element: the status bar, the status bar icons, the lock screen time, the buttons, the forms, the call records, text message threads, the keyboards, literally everything.
For the phone redesign, we created components for every element: the status bar, the status bar icons, the lock screen time, the buttons, the forms, the call records, text message threads, the keyboards, literally everything.
Designing an entire operating system interface such as Wisephone takes an enormous amount of planning, testing, and revising. It takes gathering input from your user and your developers. But understanding the basics on how to present your work in your design platform will set you and your team up for success. I hope you can apply some of these fundamental design techniques in the buildout of your next app or interface, and that you receive positive results. Happy designing.