rhubarb studios: redesign & CMS
OVERVIEW // ROLE
rhubarb studios is a new venture studio in Downtown Los Angeles and after about a year of business learned and refined their services. Their main site was built on the Squarespace platform, however as a tech services company, it was time to build their own and also to include their own CMS to publish to Medium.
I led the design for this project named 'nebula' and contributed through:
- USER RESEARCH & COMPETITIVE ANALYSIS
- INFORMATION ARCHITECTURE
- CONTENT STRATEGY & PRODUCTION (PHOTO/VIDEO)
- WIREFRAMES & USER FLOWS
- PROTOTYPING (Paper/InVision/FramerJS)
- VISUAL & INTERACTION DESIGN
- USER TESTING
PROBLEM & GOALS
There were many problems that the founders of rhubarb studios had with their current website built on Squarespace.
- Information Architecture - pages were unorganized and improperly associated and the navigation was challenging to understand of how to find information because of how they were nested within certain parent pages.
- The homepage messaging
This product and company was essentially started at the same time and so the project moved along quickly from a week and a half of research and ideation to immediately jumping into building out a minimum viable product (MVP). Designs were iterative from the start to test user experience and functionality of the app over the visuals since the company was on a short-term contract with the venture studio I was working for.
With a small team of two engineers, a product manager, and myself, we discussed on finding the balance between building quickly to validate the product's value for agents and visual fidelity. We ended up going with Materialize, a CSS responsive framework since the engineers had prior experience with it to have some basic styling for the app. The tech stack was initially in Ruby on Rails, but now refactored in ReactJS because of the familiarity of our new engineers with the plan to then implement React Native. Having a native mobile app is the end goal, but building a webapp was the fastest way to get up and running. This caused me to design with iOS in mind, despite the experience temporarily being in the mobile browser.
Where a decade ago agents were in control of sending properties to their clients, the problem agents face are that they lack the access to technology and tools to efficiently serve their clients requests. Realtors no longer feel that they're perceived as necessary and knowledgable to their clients since sites like Zillow, Redfin, and Realtor.com publicly offer property data.
We've discovered that the spectrum of problems realtors deal with today are vast in number and range, but we began targeting the core pain points of mobile MLS access, scheduling showings, and communication between agents.
DESIGN PROCESS // DISCOVERY
As a cross-functional team, we conducted user interviews with real estate agents, brokers, buyers, and sellers to understand their pain points and processes when dealing with buying and selling homes. From speaking with these 15 individuals, we distilled our learning into user personas, specifying each type of user's goals and needs were.
Some assumptions we wanted to validate with agents were:
- Scheduling showings for clients is tedious and time consuming for agents.
- Agents aren't able to access the MLS on their mobile devices, which holds critical information they need. For those that can have mobile access, the experience is difficult and considered unusable.
- Communication and messaging is chaotic for agents with other agents and their clients.
Solutions to these problems we considered were:
- Automated scheduling for agents, starting from a concierge service to fully automated on the backend.
- Provide MLS access on their mobile devices that is redesigned specifically for how agents utilize and search through listings.
- Organized and threaded messaging for agents so that each conversation has context to the property that is being discussed along with the client who is interested in buying or selling the property.
We prioritized our build and design in this order (scheduling first) because of the legalities of accessing and displaying MLS data, which we had to go through an application process. Also the threaded messaging needed more time to figure out how create the architecture with the Avenue app and the Twilio API.
DESIGN PROCESS // CONCEPTING: SKETCHES & WIREFRAMES
Above are some examples of sketches and wireframes for our two early core features: scheduling and clients.
The goal was to define the user flow and to see what elements on each page users would need to interact with. We revised how an agent would create showings multiple times because of the different situations of where agents would be coming from before the app and entering in properties. The other situation we ran into was whether agents would be showing properties they've shown before a second or third time to a client. Since then we've iterated on this challenge and I've explained it in the scheduling section below.
DESIGN PROCESS // CONCEPTING: UI & INTERACTION DESIGN
My decisions for the visual design was influenced by a branding exercise I held with the founders regarding "Who we are, Who we're trying to be, Who we're not". This gave me insight to choose the typography (Roboto family) and color palette (Slate blue, bluish grays) that was aligned with our brand styling of classy, modern, reliable, and accommodating.
Much of these designs came about 6 weeks after development as our team's priority was to ship functionality over stylized design and so UI was put on hold until we had validated the value with our users.
Since we knew that this was going to be a native mobile app, I utilized iOS' Human Interface Design Principles for the UI. I revised much of where the main action buttons are to follow iOS guidelines in the left and right corners of the Navigation Bar. I also started to iterate with using cards as part of the design patterns for Avenue for the purpose of giving users more visual separation between sections across all pages. The Messages, Clients, and Search pages have more white space between separate entities. I'm looking to implement this consistently on each of the different views.
DESIGN PROCESS // TESTING & ITERATION
We wanted to test the experience agents had when we had them create showing requests as quickly as possible and to give us feedback compared to their manual workflow as demonstrated in this flowchart.
We had 5 users making real requests through our app within three weeks of the start of the project, and though it was bare bones functional, it fulfilled their goals for scheduling properties and saving time. What usually took 1-2 hours for them to schedule, now only took them 3 minutes.
Even with good results, what I found when getting feedback with how they used the app was that there were a lot of usability problems. We built out as many necessary features as we could to get agents to schedule, however we didn't have proper deleting, editing, and canceling functions built in for their requests. These user stories were in our backlog to be built, but this is where business goals vs usability had tradeoffs to learn and validate quickly.
I iterated a few times on how agents would schedule showings for their clients as this was a complicated process that we wanted to streamline, yet maintain flexibility to different kind of agent preferences of their workflows.
Before committing to full-on development, I did some user testing with the InVision prototype to get feedback and validate my assumptions. Instead of one long form, in our team's design studio, I felt that utilizing a card based wizard system would be more simple and clear for agents who aren't as tech savvy to focus on one task per card.
The feedback for the revised scheduling flow and UI was positive especially since I included richer details when agents add in properties such as the showing type along with an agenda view for upcoming listings. The revision I had to make was on the empty state, in that users would tap the center image, thinking it was a button instead of tapping the + button in the upper right corner. I then added a CTA button to create a new tour in the center of the content area from this observation.
For the second core feature, we were able to get access to MLS data after a month into the project and my focus shifted from the scheduling showings user flow, to understanding the scope of the data in each property listing.
Property listings usually take a realtor 2-3 hours to complete because there's over 200 field inputs to list and describe a property. I took an inventory of all the contents in the listing and took several days to complete the information architecture for a property listing.
This is an example of a property listing agents look at everyday. Fields that do not have data are still in view.
The structure and hierarchy that I established in Avenue's listing page was derived from the user research of what agents interact with most frequently for each listing and also analyzing over 200 listings to discover patterns. I observed how agents input data in detail for some sections, and some where they do not complete at all. In the revised mobile design above, I had each section collapsible so that the property data was not overwhelming and cluttered upon opening the page.
The task surely felt like it was completing a 1000 piece jigsaw puzzle since every piece of information, no matter how infrequent agents fill out that field had to be displayed. At the same time, the design challenge was interesting in that though there are some required fields, each agent fills out property listings the uniquely, so the system I architected also had to be flexible.
- We tested the redesigned property listing view with our users and received overall positive feedback with the categorization and hierarchy of the data. They appreciated how my approach was agent-focused by including small details like displaying property status upfront, along with the days on market, and showing type for active properties.
- I asked them to find specific data fields (HOA fees, Pool, Remarks) that agents frequently visit to test the usability of collapsible containers as well as the reorganization of specific data fields that originally had no parent category in how the MLS form was designed.
- Aside from pulling and simply displaying property data from the MLS, we learned that agents heavily value richer functionality to integrate with their daily interactions with property listings. Specifically, having contact buttons to reach the listing agent quickly and getting comparables data of nearby properties. This amplifies the value of having mobile access to the MLS, where normally they'd need to be at the office in front of their desktop.
Searching for properties for buyers is not a revolutionary experience for agents, but we wanted to integrate their search needs with their frequent actions of scheduling and sharing properties with their clients.
I designed a property tray interaction with the intention that agents will be temporarily saving multiple properties they come across in their searches, almost like a cart system, and then eventually the 'checkout' action would be to either schedule these properties immediately or to send and save them to their client to review.
Knowing that agents are not as tech savvy and needed as much affordance as possible, I wanted to keep the tray fixed to the bottom of the screen so that it was always visible, giving additional guidance with the primary action color. In order to be as clear as possible how the interaction worked, I included in the empty states specific instructions as well as a 'Show Me' button when they opened the property tray with no properties added. Also on-long press, users would be prompted with how to drag and remove properties from the tray, with the number of properties changing whether opened or closed.
Through user testing, the feedback we received was that it was intuitive and easy. When they didn't know what to do, users were able to read the instructions of what actions to do. I asked them if they'd prefer if the interaction was a swipe from either left or right instead, but they said that the dragging was fine. Though the total interaction distance for finger travel would be more when dragging from the top property card to the tray, compared to a left or right swipe like Amazon's add to cart, I believe there's more cognitive connection when the user sees the property actually touches the tray to be added. Since the interaction is the same when adding and removing with actual targets, these micro interactions allow for greater satisfaction for task completion.
The most exciting parts of the project was always getting out of the building to conduct user testing with the prototypes. Interacting with the agents to listen about what else they'd like to see on top or in exchange of what they experience from the prototype gave invaluable insight to build the right tool for their needs and goals and I was glad to have done in person testing multiple times to witness it.
If I were to redo the project, I would have requested more time to think through different user flows for scheduling showing requests as we did not anticipate the different instances of how agents would come into the app looking to show a home. The core scheduling task was detailed out in the workflow diagram, however I needed to consider if agents are already in the middle of a showing tour, how that user experience be different.