1. Zero in on the context
When we start to work with a client on an app designed to support smartwatches, our first thing to keep in mind is that the context of using a watch and a phone is completely different and our goal isn’t at any point to port the phone app with all its functionality to a small (at most 2”) screen. Ok, so now we know what not to do, but how you should think of use cases for your smartwatch app? The answer is simple: the user opens the app with a very particular goal in mind and we need to allow him to achieve it as quickly and easily as possible. We do this by creating an action driven app. Further, the user needs to be able to continue at any time to their phone and back without starting over each time. Our goal is to create continuity between those two devices. It is also good to remember that the watch can delegate some functions to the phone, e.g. showing article titles and lead can be done on the watch, but reading the whole article should be done on a “normal size screen” – whatever that means for that user. “Design for the corner of the eye” – this is really important Android guidelines advice. Users won’t be, and shouldn’t be, immersed into a smartwatch app. They will use it to keep abreast with updates like emails or friends’ social statuses or maybe taxi position. Additionally, users will complete singular actions like pausing music. It’s a more passive interaction than performing multi-step actions on mobile; the interaction is low. Users may be annoyed with too frequent vibrations as they have the device on their hand constantly. Be sensitive about that.
2. Choose a platform. Wisely.
Before you move to drawing mockups of your app, it is crucial to choose the platform that you will aim for. For any mobile-related person it shouldn’t come as a surprise but design on both Apple Watch and Android Wear devices are in many places very different, which is why using the same patterns won’t work seamlessly. Also take into account programing possibilities on both platforms on Android you can run background process and for example monitor users heart rate, check location etc. just be sure not to drain battery. Also Android Wear platform allows you to run apps when phone is not connected to watch, be sure to handle that case and for example to disable part of your UI which depends on the phone connection. On the Apple Watch on the other hand app will be in such situation closed because core part is running on your phone and watch is only presenting UI.
Then… cut all the functionality that is not crucial to have on your wrist. Seriously. If your app is a notepad, it will be enough to just keep adding new notes and browsing past notes, without deleting, editing, sharing to friends etc. Just remember what we have mentioned previously - your notes should be synchronized in the background between your devices.
3. Get back to basics with the interface
Once you get to UI, don’t even try to copy mobile phone patterns to smartwatch. The UI structure varies between systems as well. It’s good to be updated with the system guidelines, as users are familiar with native patterns. While designing for Andorid, navigation should be vertical-then-horizontal. On Apple Watch choose one of the two patterns: hierarchical, where users navigate by making one choice per screen or page-based, where users swipe horizontally to navigate. On Android, the rule is doing one thing per screen mostly, while Apple is not that restrictive. When it comes to resolutions, it’s not easy, both for Android and iOS. Keep in mind that some of Android smartwatches are round which makes the content display differently. It is good to consider even creating a separate design for round shaped watches to get most out of it. It’s important to do mockups, because these screens are unintuitively small for designers. Even print out the screen in real size and simulate the interaction with a fake smartwatch on your hand. You’ll probably find you’ll have to double the size of all assets! And what about gestures? Apple watch has built in digital crown that is worth to remember. Using it means the user is not covering lists while scrolling longer pages. Unfortunately, thus far we can’t use it for anything else but scrolling. Another interesting Apple watch gesture you can use is force touch, which activates contextual menus.
4. Be smart with implementation
After this entire process you come to the point where you need to implement that design. This is why it is so important to be aware of all system limitations the during whole process of creating the app. First, you need to take into account some of the limitations of wearables – in Android Wear, for example, we cannot directly access the Internet, but have to use the phone as a proxy. To achieve this you can integrate WearHttp Android library, this brings us to the topic of speeding up development by utilizing some libraries, most useful for us were such as: BusWear (passing objects phone<->watch), ExceptionWear (handling crashes on a smartwatch), ShapeWear created by Michał Tajchert one of our engineers that worked on smartwatches projects.
On Apple Watch there are several limitations due to UI components: we can only used a limited number of them, while on Android we can even use custom Views. Another big difference is that Apple Watch app runs on the phone, while Android Wear runs natively on your wrist and you need to take care of all the data transfer between phone and watch. MWWormhole is library that can help you in such cases.
5. Be fast
In 2014 we have seen dozens of smartwatches and this year is probably not going to be different. As a software creators we should keep pace with continously changing wearables, no matter how fast it is. So launch your design tools and favorite IDE and start being creative in the brand new form factor of a mobile device! Remember that in significant number of features you want to have on your watch, you can reuse your existing mobile application logic. Just make sure to know which functionalities are essential on your wrist as officiousness can ruin whole experience.
- Michał TajchertSoftware Engineer
- Michał MizeraLead Software Engineer
- Karolina ChmielHead of DesignKarolina achieves balance between the needs of the user and the expectations of the client while focusing on creating the best design.