UX Case study: Instagram in a car
How would one port a social media app to an old-fashioned car dashboard screen?
As a UX Designer, it is important to stay versatile, so as a practice for myself, I decided to try transfer a popular social app into a completely new format and challenge my self how interaction on such a format would look like. Our target is the Instagram app, which we will be porting from a mobile phone into a car.
To begin with, it is worth mentioning that Instagram is not an app you would normally adapt to a car for two reasons, at least not in the current version of cars and their displays.
First of all, it seemingly breaks multiple guidelines of car makers such as Ford, as well as Apple’s CarPlay and Google’s Android Auto, which do not allow social media apps and moving images according to my research. Secondly, it does not have any clear user case that would warrant the port, as it is not an app driver would have use for when driving, and it lacks the main feature of the app in the car – the camera.
But, ignoring that, if you were to port Instagram to a car, how would it look? For the sake of the exercise, we have to make two assumptions:
1 - First of all, we are not making an app for top of the line cars with huge vertical touch displays like Tesla. They are still rare, and if they were the target, very little would need to have been changed from the current mobile version, as it could gracefully scale up and retain same touch-based interaction. No, we are making an app for an average car with a small 16:9 display on its dashboard, targeting a 960 x 540 resolution by default. If there’s touch, it’s likely low-precision.
2 - Secondly, we have to support navigation with physical controls, such as knob and touchpad, not only touch, so cars without modern touch displays can still use the app. This is a big assumption about the assignment on my part, but it makes for a far more interesting case. The assumed physical controls are previous/next and button press.
The car display that will be the target for our app, with the volume “knob” seen right below the screen.
Considering that the app has no access to the camera, there is no way to effectively produce the content (photos) through the car’s display. With that in mind, and the fact that we are supporting non-touch displays, the focus of the app should be solely on consumption of the content, meaning others’ photos and videos, as well as being able to receive notifications about replies and new messages.
The most likely user case for the app is people using it to look at photos to pass the time, likely passengers or the driver at red light, not wanting to bother taking out the phone. Because of those circumstances and control limitations, it is not necessary for the app to have any settings, as that is handled on the phone, and a lot of smaller features that don’t focus on content consumption can be removed, such as “share”, “save”, adding friends and so on. The car app will focus solely on content consumption.
With all that in mind, after few different mockups, I have designed the following start screen for the app, seen below.
I opted in for a dark design considering the driving conditions during the night, to avoid blinding the driver and be easy on the eyes. Let’s break the design down.
At the top, we have the four main features of the all, all focused on our primary goal of content consumption according to reasoning above:
- Default screen is the feed with posts from people the user follows.
- “Explore” tab with suggested content based on their interests and location (which is relevant when traveling by car).
- Activity tab with notifications about replies and likes.
- Messages tab, with latest messages send to the user.
In order to navigate the app, other than using touch if the display supports it, the user simply turns the knob to the right or left, and the white selection highlight moves first through the tabs at top, then scrolls through the current tab’s content, as illustrated to the left.
In order to continue scrolling through the feed, the user simply continues turning the knob right (of course, if there’s touch, they can simply swipe right on the screen), with selection going through activity, then messages, then jumping down onto the feed.
If there’s touch, more photos will load automatically as the user swipes to the side. However, if no touch is detected, then only 10 photos are loaded at a time, in order to make exiting the feed in reverse order by turning knob left into a fast action, rather than scrolling back through dozens of loaded photos.
If a user using physical controls wants to load more photos, they simply scroll all the way to the right, coming to a “more” arrow, and select it, and the app will automatically load next 10 photos either as soon as the user pushes the button, or after a second delay of selection being on the arrow. With physical navigation, at any time, only 10 photos are loaded, new ones replacing old ones.
User selecting the “more” button, pressing or waiting on which will prompt new batch of photos to load.
When the selection is on the photo, user can push the button to open it, which gives access to two new features (note the three dots under the glass above, indicating there’s multiple photos there):
- Being able to select the first photo, and scroll through other pictures that are part of the album.
- Being able to read and scroll through the comments on the photo.
To do either of the actions, user has to turn the knob to select either the photo or the comments, and press the knob/touchpad (from now on referred to as press-select), allowing them to scroll through either the photos or the comments. User has to press-select again to exit the current element, and turning the knob left from the photo exits back to the feed of the photos.
This navigation persists through the app, where user has to turn the knob, or push left/right on the touchpad in order to select element they want to interact with, and the press-select to focus on it and perform whatever action is tied to the element.
User highlighted and press-selected a single photo from the feed, entering it.
User scrolled to the comments. Selecting them allows to scroll up/down through comments, exiting back through another press-select.
Throughout the app, it was important to allow users easily exit anything they are currently scrolling, without having to scroll all the way up/back. If they scroll down the comments, they can quickly exit them through press-select again, instead of scrolling back up.
Let’s take a quick look at the rest of the app’s screens.
Explore tab, with trending or locally relevant photos and videos, which can be selected same as above.
Activity tab, which can be scrolled up and down same as comments on a photo.
Following the previously established reasoning, the app does not allow you to reply or open the comments, as it is too cumbersome and complicated navigation for a car app without touch, instead we focus on the essentials which is looking at photos and getting notifications to stay up to date.
The messages tab
Press-selecting a message opens it up in full, with two options.
Choosing reply, will prompt user to record a message back, with voice-to-text technology. It then reads message back to the user, asking whether they want to send it, or try again, still voice-controlled.
That concludes the walkthrough of the app. The exercise was really interesting and more challenging than I expected to, especially considering the self-imposed limitations of supporting physical controls, which better reflect the current technology and probably user cases for the app.
Of course, given larger displays and touch controls, the app could be expanded to full functionality, and maybe in some future even support taking pictures from the car’s rear/front cameras. Once self-driving cars become more common, such apps could be used by both drivers and passengers for entertainment in their full capability, but for this study, I wanted to limit myself to the more realistic scenario from current conditions.