In 2018, I joined Alarm.com to help them build a library of components for the product design team. Alarm.com provides hardware and software products that help people manage their home or business security systems and connected devices.
When I joined, the design team was using Sketch to build mobile interfaces for Android and iOS apps by creating shared designs, synced through Dropbox. As one designer would need to use a component, layout, or styles that were previously used, they would open another Sketch file to grab those assets and drag them into their file.
This process works, but the efficiency of the team could’ve been drastically increased with the use of a design system made of shared Sketch libraries. So I began the process of elaborating off of the great work they had already done, to build this system the design team could use to build mobile interfaces.
The Alarm.com app functions natively on both Android and iOS operating systems. This means I had to create a different library for each platform, which in turn meant understanding the differences between both.
But why not just create one system that could be used for both, with unique styling according to the Alarm.com brand?
We could’ve very well done just that. But we didn’t for a couple reasons:
- Alarm.com didn’t have a strong brand that a tailored and custom typeface and style treatments would have benefited from in a native mobile app.
- Through research and conversation, I felt it was more important to build an app that felt familiar for users.
What does familiarity mean for native mobile apps?
Mobile users are very used to and comfortable using their specific operating system, either Android or iOS, and the interactions that come with it. Even down to the alignment of text in a dialog, and where the primary and secondary action buttons are located, a user typically knows where to look for what they’re trying to accomplish.
Building systems and components that provide familiarity allow users to more easily and comfortability use the product, ensuring product loyalty and usage delight. Everything you need to know about native Android and iOS experiences and design guidelines can be found in the Material Design and Apple Human Interface Guidelines documentation.
Aligning to these guidelines means setting some foundational guidelines for what to follow and what to not. Some rules that we followed were mostly around interaction and legibility, referring to the typeface and type treatments (ie. type casing, text alignment, etc.).
What about more unique experiences?
With most every product, there are going to be experiences like activating a button, or being alerted by a prompt that are easy to refer to the OS documentation to design. But there are also, in most cases, unique reusable components and experiences that aren’t documented in the OS guidelines. For these, it was important to make the style and interaction feel native to the rest of the components in the operating system, but also feel consistent if a user was to change the device they were using to manage their security system.
Okay, let’s get into it.
The first thing I needed to do was audit everything we already had, so I could see where the inconsistencies were and how we could best move forward. The things I audited (per operating system) were:
This resulted in over 400 screenshots of every single page in both Android and iOS apps, of which I labeled and organized in Finder (on Mac) so we could easily search depending on OS, section of the app, and workflow.
Once I had a library of everything that was currently being used in the app, I could start defining some rules per the Material Design and Apple HIG guidelines as to what components would look like and how they would act.
Every week, I met with my design team to walk through decisions so that we could all have our hand in the creation of the Sketch libraries we would all use to build mockups. These were democratic where we would decide together what directions were best for all of us. Through many of these meetings, a complete design system library began to come together.
In the example below, are buttons for both systems. Included are components for buttons that were size-dependent on the contents inside, and buttons that could expand 100% of their container, since that is a very common mobile paradigm. What’s unique here is the typeface and casing, while what stays consistent across OS is the color and border radius of the buttons.
As mentioned above in the dialog or prompt example, text alignment and placement of buttons was very important to keep native to each OS. Since these interactions typically ask the user for a response that is important to how something will happen next, it’s very crucial that a user understands clearly how to best react.
Another quick note, a style that I kept unique, not aligning to either design guideline resource, is the style of the checkbox, since this was a way we could tie the two operating systems together and stay true to the brand Alarm.com is creating for itself.
The example below for title bars, doesn’t differ much between Android and iOS, except for text alignment, casing, bar sizing, and alignment of navigational icons.
Below, you can see an example of how the different Title Bar components were built, to allow for customization of both the left and right sides depending on what step of an action or flow a user was in.
In addition to separate iOS and Android Sketch library files that all designers could now access to build consistent and efficient interfaces, I also created some GIFs that were used to demonstrate how modular the design system was. These were used on the webpage where the documentation of the styles and components lived.