Initially, the team focused on providing a broker with tools in the field via mobile without research or feedback. The problem was that the web product did not service the needs of our users as a productive desktop tool, because the bulk of the platform was built for mobile use cases. This meant that the web product was clunky, inefficient, and missing major features present in the mobile platform.
We had to understand the existing architechture of both products in order to identify areas for improvement. We mapped out each product by major user action.
We worked with 5 firms to observe and test both mobile and web products in their current state.
There were several issues with the web app search feature. First, the sliders for price and size would not scale to proper intervals and users had difficulty finding the exact size and price they were looking for. Second, our card styles did not display any key information besides the address, city, and brokerage firm. Map tags were hard to read and almost unusable when there were was a large group of listings in a particular area.
Our mobile app looked and felt a little more cohesive, but was completely different from our web app experience. For our mobile map view, listing card styles was different than web and displayed different listing information. On the map, tags were still unusable in large numbers and users had difficulty selecting their intended listing. The sliders for filters scaled, but were a little difficult to use and were different styles as our web app. Lastly our product type picker used an icons and had a horizontal carousel style container. Users did not know that there were more product type options beyond retail, because they were cut off by the carousel view.
After a user selects a lisitng they would be taken to the listing details page. Users had difficulty navigating the layout and finding price and size. Class, type, and size of the listing were not always displayed properly. Users could upload brochures, photos and floor plans, but the call to actions were not easily identifiable.
The mobile layout of listing details felt more scannable. Users were able to find information like price, size, and listng agets. However, styles were still inconsistent with the web app layout and some of the information was difficult to digest. Information in the details portion was not aligned properly, document names were not standardized, and agent information was not actionable. We had to also ask if this was the right entry point to upload documents.
The tourbook portion of the product was where users would put listings in a collection to show their clients. In this view there was a significant amount of whitespace between fields in the table and labels had low visiblity in both color and size. Users found the table difficult to read and use. On the web app brokers had no way of exporthing this collection to their clients.
If a user wanted to add information about a listing, they were prompted with a modal. It was clear that the team was still trying to identify functionality and a sound usecase for this view. Brokers had trouble navigating the layout and finding the CTA's. Brokers gave feedback that they didn't trust this view for uploading sensitive information like proposals and executed documents.
The tourbook view for mobile was more usable. There were organized divisions between sections of information and users were able to navigate through a tourbook. Brokers asked to hide size and price requirements, since those were confidential pieces of information.
We took a look at our analytics to find out where our products stood and what were reasonable goals to reach for launch. These were our active user numbers before the redesign.
Our goals were to unify the two products and to focus the redesign on high touch features. As a team we decided that the success of our redesign would be measured by increasing the number of active web users by 80% and active mobile users by 50%.
We had to sort through the clutter of both mobile and web products in order to move foward with simplicity and clarity. We asked our selves what features were useful to our users and cut the ones that were not. Ultimatley, we unified both products into one core architecture.
We decided that tourbooks was too specific of a feature and only catered toward tenant rep brokers. We grouped the feature in a reports section called mystax to broaden the usecases for all types of brokers.
Then the building phase began and we moved into wireframing and prototyping what this new structure could look like across web and mobile. The high touch features we focused on were search, listing details, and mystax.
I sketched out low-fidelity wireframes to explore as many possibilities as possible. I shared these sketches with the team and gained some internal feedback. We then jumped into sketch and started wireframing several of these explorations. Sharing low-fi mocks early on helped facilitate internal discussions and got the team on the same page.
We optimized this screen for functionality and speed. Instead of scrolling through a long drop down, we switched the product type section to a single row of icon buttons. We also stepped out our price and size sliders to be more accurate. Users in our feedback session were able find what product type they were looking for as well as exact price and size. We also hid filters to only show when the user needed it.
We displayed all the product types in a grid for faster selection and styled the sliders to be similar to web. For both mobile and web apps we introduced clustering on the map, which adjusted according to zoom level. Brokers were able to select their intended listing on the map.
We wanted to make the most important information to a broker easy to find so we placed address, for lease tags, size, price, style, and opex at the top of the page. Grouped sections were placed into card styles in order to break up the page and highlight the information. We also added added a sticky anchor points to ensure that important information and action items were present when the user needed it most.
Modularity was important for us when designing this view because we wanted the design to be flexible with different product types. We aligned the table data for quick scanning and CTA's were designed to be more prominent and actionable. We also added amenities and introduced apple's 3D street view to help broker's visualize a lisitng in real time.
We redsigned My Stax to be a gallery of searchable reports that a broker created. We moved the table view to be the main focus within a tourbook report so brokers could access listings in their collection quickly. We optimized for readability and space by reducing the whitespace between columns, aligning text according to each data type, and by adding shading to alternating rows. We also added a contextual action bar to allow the user to preview, download, or share a report.
We wanted to keep the focus of this view on the listing table especially for when brokers are in the field. Important information like address, size, and price was accessible in a minified view on the table. We combined sections that we automatically tracked and that were less frequently edited into the overview section.
After shipping our active users increased from only 832 active users to 3500 users on the web product. Overall our mobile active users also increased, however the number of android users was significantly lower. A possible reason for the dip could have been a bug we discovered in our android release. Our followup interviews revealed that brokers were satisfied with shipped redesign and that mobile and web products catered to their specific environment.
Realstax is a product with a vision of providing commercial real estate brokers with digital workflow tools. To achieve this, it faces one of the biggest challenges-changing a person’s behavior.
Commercial real estate brokers are creatures of habit, with a strict process and a resistance towards tech adoption. It’s crucial to make the product as frictionless as possible for a user to adopt those tools. Sometimes this means making large infrastructure changes might be invisible to a user, or making changes as small as having the same color palette or changing an icon.