Business Problem
My Role
Final Outcome
"Saiyam's contribution towards key features and his ability in highlighting the details in designs and setting up the synchronous flow for our smartwatch project has truly helped in developing and finalizing the UI requirements and have been widely appreciated and accepted within the department"
-Client Feedback
Understanding The Mobile Dashboard
The dashboard was the hero section of the application which greets the user. The functionality of the dashboard can be divided into four visual sections.
Basic Indicators
Car Model
Remote Operations
Tab Bar
Shrinking the design to a Smartwatch
All this information on the mobile dashboard had to be shrunk down to a watch screen. There were negotiations to whittle it down to the absolute essentials.
The result was a two screen navigation, where the main screen has the basic vehicle indicators and the second screen had the nav bar options with their own sub menus. The Remote Operations tab was converted into a single button with its own sub menu.
You can do all that with your watch!
There were multiple functions within the app, which can be operated remotely by user with their smartphone or smart watch, these functions are referred to as "REMOTE OPERATIONS" within the app.
There were six major remote operations (as listed below). Out of the 6, my work centred mainly around two functionalities: AC and Charging. For the ease of the case study, I will be primarily focusing on the AC remote operation from here on.
AC
Head Lights
Lock
Hazard
Vehicle Health
Charging
Lets turn the AC on!
The AC user flow had a quite a few variables to accomodate, so my first step to tackle it was to build out the happy path with the client and BA to test it out.
The journey required a lot of inputs from the user like: A/C, Defroster, Rear Defogger and Seat Ventilation. Apart from that there was time and temperature, and since this was on a smartwatch the user had no way to estimate the number of steps.
My task was thus to streamline this as much as possible, although a non negotiable from the client was that the flow shouldn't have major visual distinctions between mobile and watch. This became a point of contention and I did multiple iterations to solve for this issue.
Preparing for every scenario
This is an overview of all the scenarios that were created for AC. This included failed states alternative flows(for eg: defroster) and turning AC off. In total there were around 10 user flows each that were built for WatchOS and WearOS.
Lets find the best way to set you A/C temperature
The one area where I identified a possibility of streamlining was the picker screen. Instead of having two separate screens to choose Temperature and Time, I decided to club them together using native WatchOS and WearOS components.
This required a study of the respective design systems for both the platforms and multiple discussions on feasibility with the developers
The client focus was to optimise WatchOS so thats where all the designs started.
Watch OS
Option 1
Option 2
Option 3
Wear OS
Option 4
Option 5
Option 6
Final Air Conditioning User Flow
This was the final happy path for turning on A/C within WearOS and WatchOS respectively. One of the major challenges was to not deviate from the existing design of mobile as that would result in a significant increase in time and cost for the devs.
I followed the google philosophy of 'One task per page' as much as could while staying true to the design language that exists.
Wear OS
Watch OS
A simplified version of the flow
Just the beginning
My work on the project saw a great boost on the app rating for both the platforms and as more flows I worked on go live, response from the business and the customer is positive!
This was one of my first client facing projects within IBM and it taught me a lot about design systems and responsive design. It also started me on the path of implementing motion design within applications.
Playstore: 4.5
