Google Pixel (Really Blue).jpg

Placester Auto-Pilot App

Placester Auto-Pilot App

dfgh.jpg

Category
UX/UI

Role
Lead UX/UI Designer for Auto-Pilot

Duration of Project
3 Months

I had the opportunity to lead this new app project during my time at Placester. The concept is to allow real estate agents to view content on a dashboard, edit that content, and either save as draft or publish it directly to their website from this application. It gives agents a more convenient way to access and control content.
This content consists of blogposts, email blasts, newsletters, and pages that Placester provides monthly to real estate agents for them to publish to their websites for their clients to see.

I designed the app in two different platforms:
Jump to see iOS or Android


Screen Shot 2018-02-22 at 11.33.43 PM.png

iOS

For iOS, I designed the flows and UX for Auto-Pilot with all the potential features we wanted to implement. We wanted to designed the fully flushed out version so we know what we wanted the app to be at 100%

Features: filters, mad-lib editing, photo adding, hiding content, sending content to recipient groups.
**All bottom navigation is fixed**

 

Initial Brainstorming

I started off listing all the things a realtor/agent may need to do the tasks in the app. I brainstormed features, functions, sketched out some rough flows of publishing content and filtering out content in "settings."

 
IMG_1145.JPG
IMG_1144.JPG
 

Hiding Feature

I wanted to give this app a personal value to the user, so I designed a hiding functionality. The user should be able to hind content they don't want to see or is not relevant to them. That way, they aren't scrolling through hundreds of content posts trying to find one they like. This gives them a customizable dashboard and more of an incentive to use this app!

 
 If they want to view all posts they've hidden, there is a "hidden posts" tab in the bottom navigation bar where they can unhide it again.

If they want to view all posts they've hidden, there is a "hidden posts" tab in the bottom navigation bar where they can unhide it again.

 

Photo Adding Functionality

I designed a photo adding functionality so the user could add his/her own photos in the content as well. This also gives them some customization to their blog posts.

 
Screen Shot 2018-02-22 at 10.47.37 PM.png
 
Screen Shot 2018-02-23 at 12.22.32 AM.png

Mad-lib Editing

Our team had an idea of implementing a mad-lib function where the user can semi-customize the content by changing specific words.

 
Screen Shot 2018-02-23 at 12.34.43 AM.png

Settings and Filters

My UX team and I designed different icons to distinguish different types of content from each other in the content index. The user would be able to filter the index by newest, oldest, or content type!

 
Screen Shot 2018-02-23 at 1.21.14 AM.png

Log In Screen and Error States

 

Design Challenges

Of course, there were many design challenges that I encountered during the course of the iOS project. I originally thought of "viewing" and "editing" a piece of content as two steps: if you wanted to edit content, then it would reveal the mad-libs- this wasn't efficient because the user had to go through one more step to view mab-libs. There were also just too many actions (hide, edit, revert, save draft, and publish) that I tried to divide out into these two screens. After working with my UX team, I learned that the primary action of "publish" should be the only control in the bottom navigation because it's the most important function. Other actions actions like "hide content, save as draft, and revert," can be secondary options in a top right menu. Viewing and editing content did not have to be in two steps. Once a user clicks on a piece of content from the index, it should already be in edit mode with mad-libs visible. It takes away one more unnecessary step.

 
 Before Flow

Before Flow

 After Flow

After Flow

 

Final Main Flow

The experience of finding a piece of content, looking at "more" options, editing mad-lib, deciding to publish, and confirming publish.

 
Artboard.png

Android (Material Design)

Screen Shot 2018-02-23 at 1.35.31 AM.png

The idea of switching from iOS to Material Design was because the Engineers decided to use React Native to build the app. Because it was their first time using React Native, we decided to simplify Auto-Pilot into a feasible, simpler version that can be used on both iOS and Android platforms. We wanted to start with concepts and build on top of it. 
Instead of trying to build an app with all the fancy features from the iOS design, this version just allowed a user to save piece of content as a draft, go to drafts, and then publish it. No fancy picture adding or filters yet for the first release.
**This version is still in development phase and will be released in the next month or two!**

 

Flow Diagram

I created this flow diagram at the end of the project to help the engineers visualize the app better. This way, they didn't have to go through several inVision screens to understand the flows.

**CLICK IMAGE TO SEE FULL PDF**

 
 

Challenges

This was a really exciting challenge for me because it was my first time designing for Android. I had never learned about Material Design before, so this project was all about adapting and applying Material Guidelines to my work. I examined Material Design transitions, navigations, padding, margins, toast and error messages, and so much more. I worked with React Native Expo app to get familiar with React Navigation. This project also taught me a ton about designing for error states and multiple scenarios

 

Part 1: Saving Content as Draft

After clicking on a piece of content, the user is taken to the Content Detail screen where he/she can pick the site the content should be published to (Some agents have multiple Placester websites). Then they can save the content as a draft and it will automatically take them to their drafts tab with a toast at the bottom alerting them that the draft as been saved under the specific site the user chose.

 
Artboard 2.png
Artboard 3.png

Here is the scenario if the user only has one site. There is no right arrow to indicate that the user can tap.

 

Step 2: Publishing the Content Draft

The user can easily publish their draft to their site, and after a single confirmation, the screen will automatically transition to their "published" tab with the toast alerting them that it has been published

 
Artboard 3.png
Screen Shot 2018-02-23 at 2.45.44 AM.png

Partial list scenarios for published state:

 
Screen Shot 2018-02-23 at 2.48.02 AM.png

Error States

I chose to make the connection errors red and any content related errors yellow. I didn't want the user to feel too attacked by the harsh red if he/she tried to do something that resulted in an error. The connection errors were red because it needed to alert him/her to do something (check connection).

 
Screen Shot 2018-02-23 at 2.51.55 AM.png

Empty States

Scenario designs for when there was no content in any of the drafts. I chose to use "you" for empty drafts and publish because it implies that the user needs to do something for it to be filled. 
For the content index, I refrained from saying "you" because Placester is responsible for supplying content. If there is no content, it is not the user's fault.

 

Testing Progress on Android!

IMG_9241.PNG
IMG_9239.PNG