DCP

What is Deeded?

Deeded is both a real estate closing service and a SaaS company. If you need help with real estate legal matters, Deeded wants to be the answer.

They were two years old when I joined. They already had a Dashboard product for operations, clerks, and customers, which combined data on deals from a third party conveyancing program and tracked deal status and signing dates.

DCP

I was brought on to create a replacement for the third party conveyancing service, the Deeded Conveyancing Platform, or DCP. The initial, high-level vision was presented to me by the CTO: simplify and automate as much of the closing process as possible. This project would also reduce the number of clerking tools (and usage fees) from as many as 8 down to 3.

Frustrations

As this was primarily an internal tool, I started by interviewing clerks and the operations team, the key stakeholders. They walked me through their existing processes and the various software they used. The main areas of frustration were:

• Having to manually rewrite parts of documents, and fix incorrect templates on every deal

• An awkward, non-responsive layout with limited viewing space

• Manually calculating business-specific numbers and fees

• Manually merging documents

• Fighting with an unreliable file syncing service

• Having to switch between a dozen different tools

• Having to copy things into the Dashboard to maintain records

I laid out my initial ideas for the main input screen in Figma and presented it to Ops. They were elated. The layout was a breath of fresh air, and it was tailored to the way our clerks worked. But there was a long way to go.

Design System

I converted elements from the first mockups into components and started building out a design system. I used some colours and typography from the Dashboard, and roughly matched the buttons, but nothing else was worth keeping. As I worked on the layouts, I would continue expanding the component library, tweaking elements and states as needed.

Meet All Navigation Styles

The clerks were going to spend all of their time in DCP, so I wanted navigation to fit their preferred style, be it entirely by keyboard, pointing and clicking, or a mix of both. Beyond standard accessibility practices, every input had to have distinct states for selection, focus, hover, errors, as well as auto-filled or calculated results.

Custom Components

When necessary I created custom form components to better suit the data being input. These balanced usability with development feasibility, and were comprised of other standard input behaviours and existing React components. The Priority picker combined a dropdown with a drag-and-drop list, and would sync with all other Priority pickers. I gave input fields hover/focus actions, to expand functionality without taking up any extra screen real estate.

Text Inputs

Some of the possible states and variants of a text field.

Dropdown and Token Dropdown

States of the basic dropdown component, which can be built upon for more complex dropdowns, for instance a multi-select token input.

Pills

A variety of pills were used to efficiently convey statuses, counts, and types throughout DCP.

Priority Picker

Combines a dropdown UI with a drag-and-drop UI to create a more robust control.

Date Input

The calendar component in different states, and the month and year selectors.

Process and Progress

I presented designs to my dev team in workshops, making sure they understood both what we were building and why certain decisions were made. These workshops also served as feasibility sessions, to judge the scale and scope of the work from their perspective. When designs were validated, I created JIRA stories as Gherkin formatted scenarios, and included mockups and links to relevant documentation.

MVP

As development progressed, we remained vigilant to always be working toward a MVP capable of completing our most common type of deal. Once the MVP was ready, we could start using DCP on real world deals.

Modules

DCP was conceived and built as a series of modules that serve discrete functions, all building toward a closed deal.

• The Data Sheet contains all of the collected data for a deal.

• Docs contains all the collected and generated documents, and allows for producing bundled packages.

• Comms collects all communication between the parties involved, with viewing permissions based on role. This would replace email for clerks.

• Title Search, Title Instructions, and Mortgage Instructions are embedded API-driven access points to external database services.

• Log is a meticulous log of every change and action taken by any parties with access to the deal, a crucial tool for auditing.

• The floating widget toolbar contains three micro-modules:

  • Task List, an automatically updated list of task items to complete for a given step in the deal;

  • Notes, a stream of notes from stakeholders on the deal;

  • and Calendar, a way to access and schedule signings for the deal.

Notes Widget

Two streams of notes: the public one for all stakeholders of the deal to communicate on, and the private one for Deeded staff. This was to eventually expand to include task assignment as well.

Private Notes

The staff-only section of notes.

Hidden Notes

An early solution for both moderation and “task completion” was being able to hide notes.

The Data Sheet

The Data Sheet is the core of DCP’s intake system. There is a gigantic amount of information that goes into closing a real estate deal, and it needs to be laid out in a logical, legible, usable way.

I designed this system with a few key rules in mind:

Zero redundant input

While competitors used more of a digitized-paper-forms approach, which leads to lots of redundant inputs, we wanted to take the Simple Tax approach: input once, populate where needed. The required data input is informed by, but divorced from the necessary output documents.

The system should be self-checking

As the clerk fills out details, the form adapts. Toggling a boolean switch will add or remove fields. Missing or incorrect data will trigger an error, with a message describing the expected data.

Automate and OCR everything

If data is already available from another source, digital or physical, it should be ingested automatically, and populated into empty fields intelligently. When a user is filling out or reviewing fields, they can choose their source from the data retrieval process, and even inspect that source.

Modals and Data Management

While all the collected data for a deal lives in the Data Sheet, a lot of that data is linked to more complex objects, stored for reuse across deals. Those shared data objects are managed and manipulated through modals of varying size and complexity.

Modals help focus the user’s attention on a single task at a time, while keeping their place in the workflow. Much like the Data Sheet, modals can have multiple states, dynamically changing as information is added, to meet the needs of the object’s data model.

To reduce the burden of upkeep on clerks, I centralized all object data in an admin panel for administrative staff to manage. A permissions and override system determines what changes are synced to deals, and impacted clerks are alerted whenever an update is made on their deal.

Debt Modal States

The many states of the Debt modal, from new, to filled, to editing an existing debt, to varying payment methods, to deleting the debt entirely. This is a rare case where a modal on top of a modal is actually appropriate.

Conditions

Conditions are the primary driving force behind a deal. Every condition must be met to close a deal. Individual conditions are dealt with through modals.

Docs

Ultimately, DCP’s function is to output sets of documents in order to close a deal. This means having an extensive set of functionality around managing and producing those documents. The Docs module manages received and generated documents using a familiar folder structure. Depending on the deal type, a standard folder structure is set, but can be customized.

Docs

Documents can be uploaded, added, packaged, searched, and filtered.

Selecting Docs

Documents can be selected, multiple at a time, even within different levels of the folder structure.

Moving Docs

Documents can be dragged around to reorganize them within the folder structure.

Filtering

Documents can be filtered to more easily find documents of a certain type or for a certain step in the deal process.

Templates

Documents are produced using templates populated with the deal’s data. These are editable with a built-in editor, using a tag system to place any given data point, and a set of grammar logic to use correct titles, pronouns, pluralizations, etc.

Adding Docs

Docs can also be added using the Add Doc button, which gives a searchable list of all available templates. Once a document is selected, it may need to be paired with a contextual data object to populate properly.

Documents can be produced and exported to PDF. When a change is made to the contained data, the system will prompt the user to re-produce that document, keeping track of versioning for each document.

Intelligently Suggested Docs

When data is input but not captured in a document the Suggested Docs section will highlight documents the user should likely be including. Once selected, those suggestions can be added and populated with a single click.

Suggested Docs

Suggested documents can be selected then added to the appropriate folders.

Document Context

Some documents require a paired contextual data object to be filled in properly.

Upload States

An upload modal showing the different states of upload for a handful of files.

Merging Docs

Once documents are uploaded or produced, they can be merged into bundled documents for export to one party or another. This is how the final closing documents are produced. This process allows for rearranging or removing pages, and reordering between different documents, as required by the recipient.

For ease of use the most common bundles of documents are available to export in a click from the Packages button.

Closing

When I left Deeded the Data Sheet was nearly completed development, Docs was in progress, and the Admin Panel was ramping up. I had lain the ground work for the next several months of development, and the first version of DCP was released In February 2024.

I had a fantastic development team who were eager to learn, grow, and build the best software possible. The ops team were consistently impressed with the work we did and were always champing at the bit to get their hands on it. Our work sessions always resulted in greater understanding, on both sides, and another heap of work to do.