Background
Car Throttle is one of the largest automotive community platforms on the internet, with almost 6 million users per month. We were building a next-generation media platform with the backing of the minds and investors behind Facebook, Skype and AOL.
After starting life as a car blog in 2009, we quickly evolved into a popular site covering car news, reviews, humour and video content. Extremely active on social media, we had popular pages on Facebook (3 million+ fans), a thriving YouTube channel (1 million+ subs) and a growing fanbase.Problem
Our users were constantly asking for an app in the website comments and creating posts about it on the website. Also, we had conducted multiple surveys that always showed a heavy weighting towards an app being the next feature users wanted. We were slightly confused as to why our users needed an app when we had such a well developed mobile website.
Survey results from the community showing the desire for an app
We discovered through testing and interviews that the difference between our website and an app is convenience. Users wanted the following conveniences, which we made our primary goals to work towards:
1. An app on their home screen so they can access the feed quickly and easily.
2. To receive native notifications on their phone (likes, comments, follows etc)
3. To share content / media / links natively to Car Throttle.
4. A better, native content consumption experience on mobile.
Solution and outcome
The Android app was launched in November 2015, with the iOS app following shortly after in April 2016.
Over 200,000 downloads
Over 25,000 app reviews
4.9/5.0 Play Store rating
Hundreds of user posts per day
The Car Throttle Android and iOS app
Discovery
We had some key questions we needed to answer, which we did through surveys and talking to stakeholders and our community:
1. What benefits are there to an app vs the web?
2. What problem exists on the platform that justifies the time and resources to developing an app?
3. If there isn’t a problem, then would an app add functionality to the website and improve the UX for the user?
4. Would an app be based on specific website features, or an experience to replace the website on mobile devices?
As I mentioned earlier, it boiled down to users wanting the same great Car Throttle experience and features, but with more conveniences, native integration and less friction to entry.
Brainstorming communities and the features of the platform
An app should aim to replicate the experience and features of a website as a minimum, meaning the user/app needed to be able to:
- Browse a feed of posts and display individual posts
- Up-vote and comment on individual posts
- Create a new post (content editor)
- Use push notifications
- Create and manage an account
- Serve our cross-platform “native in-feed” advertising product
- Integrate with our existing analytics providers
- Search posts, users and communities
Google Analytics mobile usage overview
iOS and Android were clearly the most popular platforms based on traffic to the mobile website, so I decided to create apps for both. Launching an app on only one platform could alienate and anger a lot of users. I was very familiar with iOS as I've always owned Apple devices, but Android was a new and exciting territory for me and I decided to learn Google's 'Material Design' language to make the app as native as possible.
In terms of experience, the design language and content needed to be mostly consistent moving from the website to the app, but we wanted the app to feel native with its transitions, animations and UI. This meant designing from the ground up for each platform and would essentially double the work involved, but I thought it was a worthy cost for the best UX.
Competitor Analysis
After gaining a better understanding of the features, facets and scope of the project, it was time to do a competitor analysis. The feature that most interested me was the feed itself, so I turned to social media apps to see how they did it. This process gave me inspiration, but also confidence that we were going down the correct path.
Competitor analysis for the feed
Analysis was done for every feature of the app to ensure we hadn't missed anything, gain inspiration and enabled us to see patterns emerging.
User flow
To get a better understanding of the UX of installing the app and using it for the first time, including all the registration and sign-in options, I created the user flow below.
Registration flow chart
Opening the app for the first time could potentially be confusing, so I created a flow chart for how to navigate the app from the home screen.
Main navigation flow for the app
Sketches
Once I had a clear idea of the business goals, user needs, requirements and user flows, low-fidelity wireframes were created.
Wireframes for the 'communities' home screen
This part of the process is most useful for exploring ideas and concepts before committing to a particular path to follow - especially for different types of navigation.
Basic wireframes were produced for each 'feature' of the app, but not necessarily every screen. This was to give more of an overview of the app before more detailed digital wireframes.
Wireframes for the content editor and brainstorming the 'create a post' process
Wireframes
Once the team agreed on a set of wireframes, I used Balsamiq to produce a complete set of wireframes. Using my sketches, I created detailed wireframes with reusable symbols for the consistent UI elements and placeholders for content.
Wireframes and flow for the login and onboarding
Still exploring concepts at this stage, it was easier to refine them digitally than with a pencil and eraser. Below, I explored different types of navigation to change feeds and UI for opening posts.
Wireframes for feed navigation and a post UI
The wireframes gave the team a clear idea of the data and content that would be needed by the app. Once agreed upon, the development team started building the API for the apps.
Wireframes for profiles and settings
Concepts
This is everyone's favourite part of the design process - when all pieces of the puzzle come together and you get your first taste of what the app might look like.
The traditional top 'title bar' and bottom 'tab bar' didn't feel modern, so I explored different options for the main UI. Below, you can see the concepts and the refining process.
iOS 'Home' concepts
After a recommendation from a friend, I decided to learn and use Sketch instead of Photoshop to design the app. Sketch was a pleasure to use and a breath of fresh air compared to Photoshop and seems much more suited to tight UI design.
iOS 'Communities' concept
This was also my first foray into Material Design, Google's visual design language. Reading the guidelines, I was impressed at the depth and detail and it was a lot of fun to learn and experiment with it. Below, you can see the use of Material Design elements like the FAB (floating action button), tab bars and slide-out drawer navigation.
Android 'Home' concepts
Design
The concepts were eventually refined enough, tested and agreed upon by the team. Complete high-fidelity designs were then produced for every single screen.
iOS final designs
Android final designs
Prototype
Below is a prototype I built to enable myself and the team to see the final designs brought to life on a device. It allowed me to see how users would actually interact with the UI and adjust the placement of interactive elements.
Results
Working very closely with the developers, I oversaw the process and strived to ensure the UI and interaction design was implemented correctly.
iOS app store screenshots of the main features
The app received great reviews from launch, which isn't always an easy feat. Android had an extra four months in the app store to refine and iron out its bugs, so we learnt a lot for the iOS launch. As you can see below, the metrics speak for themselves - both apps have great ratings and plenty of downloads in a short amount of time.
Android and iOS app store reviews
