When I began working on Brivity, it was a transaction management tool with an address book, automatic updates sent to clients as emails, and a social media posting feature used primarily by large real estate teams—specifically by administrative assistants—to monitor and report agent activity and the status of individual real estate transactions to the clients of the real estate firm.
I started with Brivity as UX/UI designer for all of the Brivity products. Much of my initial work began with the Marketing team designing both print and web assets for events, as well as doing the bulk of the copywriting. In order to do that work well, I also became the primary User Researcher and did market research along with other stakeholders and teammates. When the past Product Owner left, I quickly assumed those responsibilities; negotiating with stake holders, making product decisions and prioritizing development of features, as well as continuing to communicate with both Sales and Support while providing materials and training for them.
1. Increase Market Share
Churn was high, and more than half of users left after an average 1.2 months of use if they received a free trial period and 2.6 months if they did not. We also wanted to increase organic signups, because over 90% of signups relied upon online demos or in-person sales at trade shows or other events, with little organically.
2. Update the existing, static visual style to be more dynamic
The prerogative of stakeholders was a complete re-design to update the visual style of the app. Real estate agents frequently suffer from shiny-object syndrome, so the assumption was that it would increase signups and reduce churn by introducing a snazzy new interface and new features for existing clients. We also felt that we could help users make more sense of such dense info with a design update.
3. Improve the process for feature requests
Initially, new requests from stakeholders or sales were sent directly to development and given top priority. This was disruptive to the development process and made it difficult to set or meet deadlines. We needed ideas, feedback and feature requests to go through a process of collection, research, design, and testing, before being written into user stories and prioritized for the developers to begin.
As the first and only designer on the team, the assumption that a sleek new skin would fix everything felt risky, and the huge undertaking of a complete redesign made me nervous. In my experience, B2B customers usually care more about functionality (i.e. new features) than how pretty the app is. There was very little documented research or explanations of design decisions from the past to get started with, so there wasn’t much evidence that a redesign was the right solution, especially considering the observed lack of adaptability of exhibited by many of our core clients. Clearly, we needed more information.
If you'd like to know more how I solve problems when I team doesn't have previous user research and design documentation, I've written extensively about that process here, but for now I'll keep it short.
With a general understanding of what the product did, I spent the majority of my research time observing how actual users worked within it. I also got involved in helping marketing and support create better surveys that didn't ask leading questions or force users to choose an option that might night apply to their situation. Contextual interviews and usability testing with prototypes were my methods of choice because of the aggressive deadlines and lack of analytics we had installed when I began.
Exit survey feedback supported the idea that the current interface was difficult to learn and was underperforming user expectations for functionality within existing features. Usability testing helped us identify problems early on so that a single design change could fix multiple problems for users.
From Support tickets we learned that we were often prioritizing features or fixes from very vocal but low-impact users while letting things that were important to everyone slip back into the icebox for weeks or more at a time. We also learned that overselling was causing disappointment as setup was time consuming, and users didn't realize expected features were missing until later.
Our suggestion was to focus on the marketing pages first, and then to work with sales to help them set expectations appropriately, and with support to improve the on-boarding process, in an effort to achieve the first goals while updating the design in smaller releases, but in the end, key stakeholders felt it was extremely important from a business perspective that Brivity showed the capacity for complete transformation, and it was decided that we would be focusing on a waterfall style refactor and redesign before transitioning to agile releases of improvements.
While we worked with support to improve their self-help articles and training strategy, we also worked with sales to figure out a way to balance incentives to oversell. Much was accomplished from simply improving development's communication with the two teams and introducing internal & external release notes.
Improve Navigation Usability and Flexibility
Knowing that we were going to need to make more room for the vision stakeholders had in mind, we needed to consider how we could expand options in the navigation while not increasing the existing perils of using it on smaller screens. Meanwhile, after attending a live agent training that a support agent gave to a local team, I was able to confirm that it wasn't just me that was struggling to follow the demos, let alone navigate on my own within the app. The current navigation was confusing and not meeting user needs.
First off, users had troubles understanding where they were within the site and how they got there—trainings were slow and tedious as users continually asked "but where am I now and how do I get back?". Users clarified that they saw Brivity as an application—not a website—and they expected the main navigation to highlight which component of Brivity (transaction management, task/to-do list, CRM, 1-click marketing, etc.) they were using.
The animation of the search feature was difficult to click when you wanted it, but always seemed to pop up when you didn't. The "+" icons next to the text links in the navigation—separate buttons from the text links themselves—were for creating new objects in the system (I never found a user who instinctively understood that), but the other icons only visually indicated that something had happened and needed a user's attention on the page (something that even advanced users never knew).
The secondary level of navigation was visually inconsistent between indexes, and though it did indicate which page you were on, indexes like "tasks" that did use color to help users navigate and prioritize, then confused them later by always using orange to highlight which page the user was on.
Finally, moving from one tertiary object to another without going back to a primary-level index was difficult because the secondary navigation disappeared to be replaced by tertiary navigation. This sub-navigation also made users uncomfortable because some pages had content above the navigation (like on an individual listing) which caused it to scroll away, and others didn't (so it would remain fixed to the side).
The footer worked well on the marketing pages, and was relatively fine (other than users expecting that "chat with us" meant instant messaging, not emailing) once logged in, but it took up valuable space at the bottom of the screen if you opened Brivity in the browser of a mobile device. It also re-inforced that Brivity was a website, not an application, which appeared to be a jarring realization for users.
Brivity's new navigation & Structure
After some competitive research, multiple wire frames, and A/B testing with the team next door, we realized we basically had the option of combining categories and using icons to attain the space we needed for new featurs, getting rid of the "add a new __" "+" buttons, or moving the navigation to the left.
In the end, switching to a side navigation solved several problems at once. First off, the transition from web to mobile was much more fluid because users already expected the secondary navigation to be nested within the primary navigation. Tertiary navigation could be added on the pages that required it.
It allowed for increased flexibility so that when we ultimately combined Listings & Pendings into Transactions and moved the second page for Leads under People, it only required a bit of new code to update. It also provided space for additional features like the Project management and Calendar view, as well as an extra link for users to reach their Settings on the left navigation, and space for in-app notifications at the top.
Testing showed us that users didn't know what to expect behind just a photo. Some thought it might go to their personal contact info, others to their account and login. Adding their name seemed to remove that ambiguity. Even after that, however, users (especially new ones) appeared startled in A/B testing when we sent them directly to a settings page when they clicked their name and photo. There’s a lot of functionality in the settings area and analytics showed us it was pretty evenly distributed, so choosing a default would be wrong more often than right. As a result, we tried a dropdown that gave users a category to choose from.
From there, we worked to maintain the content but shift the layout of the tertiary page—to work better for mobile while aligning with the user flows we observed in contextual interviews. We needed a framework that was flexible enough for all objects (regardless whether they were a transaction, project, or person's contact page) so that we could build quickly, but they also needed to appear different enough so as not to cause the user to feel lost. After interviews, sketches, and wireframes, this is the basic structure we came up with for tertiary (object) pages:
Improve written & visual Consistency and use industry standard vocabulary
Much of the confusion that new users experienced appeared to stem from confusion around naming conventions that weren't standard to the real estate industry. Our sales team was using real estate jargon to sell, and our support team was using a variety of terms they found in Brivity (based on which one made sense to them personally) to do trainings and help users. Admins (our main users) who were often new to the industry told us this made it difficult to translate real estate jargon from their boss into Brivity's standards when both were new or unfamiliar.
One of the first things I noticed when first using the app is that many fields had diverse names throughout the app. For Example, Who / Responsible / Assigned to / Agent / Name / nothing at all... all of these where titles that referred to the same field in the database and were scattered throughout the app. Together, the meaning is clear enough, separately however… a bit confusing. Other terms like Pendings that really referred to Buyer's Transations just weren't clear or specific enough. Because many admins (Brivity's primary users) don't start their job with a background in real estate, they found this very confusing.
Page layouts varied when content was similar in some cases, but for other content appeared very different despite similar content.
Text styles and use of text links vs buttons wasn't consistent either. In many places, there was little hierarchy in the text which gave users very little indication of where to focus their attention or how to move through the app. It was often difficult to tell if clicking something would open a modal over the information they were viewing, or if they would lose their spot when they were sent to a new screen.
Brivity's new Naming Conventions
We sought to improve consistency and ease on-boarding by standardising labels of fields, tweaking them to meet industry standards, and training our support, sales, and marketing teams to use the same terms in spoken and written brand assets and collaborated with them to create style guides for writing.
We researched by cross referencing terms used by our competitors with language we found in real estate blogs, training portals, and licensing training materials. From this, Listings and Pendings were merged to be Transactions, while Leads and People became just People after negotiation with stakeholders over the industry preferred Contacts.
Colleagues became Teammates (referring to your internal team and login users of Brivity) and after analytics showed us that users had no idea what to do with other professionals who were part of a transaction but not part of their team—we saw them in literally every category— we created the previously unnamed classification for Collaborators.
Some fields—like the field for the person who needed notifications—had a lot of overlap between Brivity's various functionalities (as Transaction Management vs. CRM vs. Project Management, vs. To-Do list), research came with mixed results, so we A/B tested different ideas to establish something that rang true with our users. "Who" came out on top as being the simplest, most intuitive and flexible word that could be used throughout the app regardless of what type of object it was associated with.
I mentioned a bit about improving the visual consistency in the section about re-designing the navigation, but where we really saw encouraging feedback from changes was in the design of the pages themselves. As Brivity has several very different functions resulting in objects that behave quite differently. Grouping like objects together in the navigation and varying the styles of the indexes helped users know to expect different interactions and functionality, and enabled them to easily pick up where they left off when their work-flow was interrupted (which is very common for admins).
Objects like People, Transactions, and Projects usually have tasks and multiple additional objects associated with them and are more or less equal to one another, but can also essentially exist without any connections which is why they have their own pages that show these connections. Tasks on the other hand, are always attached to one of those objects in a sort of secondary way, which is why an individual task can be deleted from an index, is seen as a modal, and doesn't have it's own page.
These same values are reflected in the layout of the tertiary (object) pages. All like objects follow the same wireframe just with different tabs in the workflow. In the original version, the "timeline"—which represented updates to an object appeared essentially the same as tasks, made users believe they could edit them the same way. Replicating the style of tasks from the index to this workflow set clearer expectations and helped users identify where they were in the app.
Adding Color to Direct user flow
Color didn’t have any imbued meaning in Brivity, but teal, orange, and spots of red could be found highlighting information through the app. Both quantitative and qualitative research told us that users found this use of color confusing. We knew it could instead help us organize and bring meaning and direction to so much dense information as color (or perceived tone) is the most identifiable visual differentiator when it comes to hierarchy.
Now, in every instance, color denotes Urgency
From the sub navigation, throughout the indexes, all the way to the details on the individual pages of the objects themselves, color is used to help users decide which object or information needs their attention first. Anything red needs immediate attention or is irreversible, yellow represents active things or those that should be addressed today (before they become red), the cool blue-green indicates they've been addressed recently and that you have time to get to those or as an acknowledgement of completion, while the deep teal is for objects that are settled and won't need attention for a week or more. Grey is used for objects that are completely inactive but being kept in the system in the hopes that external activity will bring them back to color.
Users told us that it didn't just help them prioritize their work more efficiently, but it made learning and understanding the entire system better.
** I am currently adding more information about the redesign & subsequent updates (please excuse any sudden transitions)**
After nearly 2 and a half years of work, the core Brivity product has expanded to become a full-fledged CRM and project management tool with an extended API that integrates with other products in the Brivity suite, as well as those from other select products. It has expanded its user base from mostly real estate admins and the customers of agents to include team leaders and managers of real estate teams, listing and buyer specialist agents, other real estate office staff, and collaborators outside of the real estate team like brokers, lenders, and appraisers.
During that time, the company experienced a 396% growth in revenue, reduced its churn rate and increased signups exponentially after releasing the new interface. The development team made the switch from Waterfall to Agile which made future work more predictable as well. Unfortunately due to the inaccessibility of customer data at the time that I started, I don’t have specific rates of change for churn reduction or organic signup expansion.
- Our goals weren’t specific enough in outcome, so it was difficult to measure progress and our level of success. We were reminded that it's necessary to set goals that are specific, that we know we can measure within a predetermined timeframe, that are also realistically achievable.
Early on, most deadlines were set strictly by marketing—without a clear understanding of the realistic velocity of development. On top of that, we heavily underestimated the amount of technical debt we were starting the project with. The Waterfall style of release was really difficult to predict, but the Agile process made room for learning the state of things before estimating delivery times, and the better our communication became, the better we got at setting our own targets; ones we knew we could hit.
In the early stages of the refactor & redesign, Brivity did not have a beta environment (at one point it didn’t even have a staging environment) to push to, so changes went directly to production with only internal testing. That occasionally forced us to drop part of a sprint to test and fix a big bug that popped up in production. Not having beta was a choice that was made to pinch pennies and save time, but we should have insisted upon a beta environment much sooner.
The most difficult challenge we faced was scope creep. Due to technical debt, getting the data that we needed to measure user behavior was time consuming, and thus costly. Installing additional user research and analysis tools in the app wasn’t a priority for stakeholders, and as a new hire, I didn't feel I had the leverage to push back, so at first I proceeded with mostly qualitative data from users and feedback I received from the support and sales teams. This mistake allowed new feature requests to get strong-armed into the backlog without enough data to support their development. It got a easier after I formally assumed the role of product owner, but if I could do it all over again, I would insist upon installing analytics software before doing any design work on new feature requests so that we could have had the quantitative data to back up our “no’s” with more security when it came to unvalidated ideas—before they affected the backlog.