Real estate Wizard
wireframes.

Real-estate market players are represented by different types of entities: from huge organisations to smaller agencies, teams of agents or individual agents. Org structures are usually very complicated with multiple levels of offices and sub-offices. And each entity can join the platform as part of bigger organisation or independently. This is what we had to consider while designing, as a rule simple, flow of the account registration. Flow was adjusted for different types of accounts and impacted by validation if account is a part of existing organisation.

A user’s property listings inventory feeds from many sources and is displayed on multiple websites. It is important for a real estate agent to track their performance across these different venues at glance.
We figured out how to keep the balance and display listing information completeness level, and performance information on a listing card while making sure it did not become over-cluttered.

Analytics is always a complex feature, but in Wizard’s case, the multi-level structure and flexibility of brokerage set-ups made it even more complex. We took into account that data feeds from multiple sources, what data and how it can be displayed and sliced, considered dependency with the access levels, different filtering, and view options.

A challenging task both from technical perspective and user experience was the flow of joining the organisation by an existing platform user. A pretty common case, when best-performing real-estate agents are hired by outstanding companies. Complication arises when an agent created website, managed a pool of listings and clients, joined the organisation that forced brand requirements to all members of the network.

We have considered the possible conflicting points on multiple levels: integration of databases, merging of website components as well as agent’s profile information. Thus joining the organisation consisted of multiple steps where user was asked to resolve conflicting areas or just preview changes made in his space depending on the level of flexibility allowed by Org Admin.

The discovery stage of the project began by exploring the functionality of the existing legacy system, and business requirements about the new capabilities of the product. Based on these discoveries, the team defined the scope in the form of information architecture, clarified types of users with their accesses, and produced user flows for main scenarios.

The competition of SaaS solution for real estate companies and agents is very intense. We believe that usability and simplicity combined with powerful automation logic can be a real edge on the market. So the team explored direct competitors to learn common patterns adopted by the industry and to benchmark feature set. Additionally, we analysed indirect competitors, especially website builder solutions to explore capabilities and features to simplify them.

Organisation structure of real estate companies are complex, more over there are different structures, how organisations operate. First of all, we wanted to make sure that system is flexible and can adapt to meet various set ups. We had to consider how accesses abd permissions impact visibility of content, access to the data and actions permitted.

In order to understand how to optimise and simplify user behaviour we create visualisation of business processes, that covers interaction between personas, as well as user flow diagrams to create a model of interaction of a user with a solution.

Although the scope of the project was mainly to create logic of the solution and designs were created as grey-scale wireframes, we still created the Design System following Atomic principles. One one hand, it allowed to re-use components, made iterations faster, but it also simplified and speed up handover to the UI and development teams.

We documented product requirements in user stories format to hand-over to the development team for estimation at early stages to start back-end preparation under tight deadlines. Also, Cieden provided supporting documentation in the form of a table of permissions, a high-level database structure (ERD diagram), a context diagram of a list of APIs that could be integrated, and other supporting documents.